คำถามติดแท็ก unit-testing

ในระหว่างการฝึกอบรม TDD ตามกรณีซอฟต์แวร์ทางการแพทย์เรากำลังใช้เรื่องต่อไปนี้: "เมื่อผู้ใช้กดปุ่มบันทึกระบบควรเพิ่มผู้ป่วยเพิ่มอุปกรณ์และเพิ่มบันทึกข้อมูลอุปกรณ์" การใช้งานขั้นสุดท้ายจะมีลักษณะดังนี้: if (_importDialog.Show() == ImportDialogResult.SaveButtonIsPressed) { AddPatient(); AddDevice(); AddDeviceDataRecords(); } เรามีสองวิธีในการติดตั้ง: การทดสอบสามครั้งที่แต่ละวิธีตรวจสอบหนึ่งวิธี (AddPatient, AddDevice, AddDeviceDataRecords) ถูกเรียก หนึ่งการทดสอบที่ตรวจสอบทั้งสามวิธีถูกเรียก ในกรณีแรกหากมีสิ่งผิดปกติเกิดขึ้นหากเงื่อนไขข้อการทดสอบทั้งสามจะล้มเหลว แต่ในกรณีที่สองหากการทดสอบล้มเหลวเราไม่แน่ใจว่ามีอะไรผิดปกติ คุณต้องการแบบไหน

18 unit-testing  tdd 

ฉันกำลังทำการทดสอบหน่วย ฉันพยายามทดสอบหนึ่งฟังก์ชัน ฉันเรียกมันจากองค์ประกอบการทดสอบของฉัน แต่ถ้าฟังก์ชั่นระยะไกลไม่สามารถจัดการกับข้อยกเว้นส่วนประกอบทดสอบของฉันจะได้รับการยกเว้นฉันเดา ดังนั้นฉันจึงควรกังวลเกี่ยวกับการได้รับการยกเว้นในองค์ประกอบทดสอบของฉัน? ขอบคุณ แก้ไข: PS: การโยนข้อผิดพลาดเป็นสิ่งที่ดี แต่สำหรับฟังก์ชั่นอื่น ๆ เท่านั้นไม่ให้ผู้ใช้ปลายทางจนกว่าจะเป็นตัวเลือกสุดท้าย! OMG ฉันเขียนใบเสนอราคาการเขียนโปรแกรม !!

18 testing  unit-testing  exceptions 

ตามที่เป็นอยู่ในปัจจุบันคำถามนี้ไม่เหมาะสำหรับรูปแบบคำถาม & คำตอบของเรา เราคาดหวังคำตอบที่จะได้รับการสนับสนุนจากข้อเท็จจริงการอ้างอิงหรือความเชี่ยวชาญ แต่คำถามนี้อาจเรียกร้องให้มีการถกเถียงอภิปรายโต้แย้งหรือการอภิปรายเพิ่มเติม หากคุณรู้สึกว่าคำถามนี้สามารถปรับปรุงและเปิดใหม่ได้โปรดไปที่ศูนย์ช่วยเหลือเพื่อขอคำแนะนำ ปิดให้บริการใน7 ปีที่ผ่านมา ฉันวางแผนที่จะศึกษาและใช้การทดสอบหน่วยกับโค้ดของฉัน แต่หลังจากพูดคุยกับเพื่อนร่วมงานบางคนแนะนำให้ฉันว่ามันไม่จำเป็นและมีประโยชน์น้อยมาก พวกเขายังอ้างว่ามีเพียงไม่กี่ บริษัท ที่ทำการทดสอบหน่วยด้วยซอฟต์แวร์การผลิตจริง ฉันสงสัยว่าผู้คนใช้การทดสอบหน่วยในที่ทำงานอย่างไรและประโยชน์ที่พวกเขาได้รับจากการใช้เช่นคุณภาพของโค้ดที่ดีขึ้นลดเวลาในการพัฒนาในระยะยาวเป็นต้น

18 unit-testing 

ปิด คำถามนี้จะต้องมีมากขึ้นมุ่งเน้น ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้มุ่งเน้นที่ปัญหาเดียวโดยแก้ไขโพสต์นี้ ปิดให้บริการใน4 เดือนที่ผ่านมา หากคุณรักการทดสอบหน่วยเสมอดีสำหรับคุณ! แต่สำหรับผู้โชคร้ายที่ไม่ได้เกิดมาด้วยความชอบคุณมีวิธีจัดการให้งานนี้สนุกยิ่งขึ้นได้อย่างไร นี่ไม่ใช่คำถาม "อะไรคือวิธีที่ถูกต้องในการทดสอบหน่วย" ฉันเพียงต้องการทราบถึงเทคนิคส่วนตัวเล็ก ๆ น้อย ๆ ที่ช่วยลดความเบื่อหน่ายในการเขียนแบบทดสอบหน่วย

18 productivity  unit-testing 

ตกลงหรือไม่ที่จะเพิ่มการยืนยันที่ถูกเลื่อนออกไปเช่นนี้ var actualKittens = actualKittens.Select(kitten => { Assert.IsСute(kitten); return kitten }); ทำไม? ดังนั้นฉันสามารถทำซ้ำได้เพียงครั้งเดียวแม้จะมีข้อความที่คาดว่าจะเกิดการรวบรวมที่เป็นรูปธรรมเช่น: CollectionAssert.AreEquivalent(expectedKittens, actualKittens.ToList()); และมันอาจจะไม่ใช่แค่เลือก แต่เป็นวิธีที่กำหนดตัววนซ้ำและมีการตรวจสอบและตรรกะจำนวนมาก (เช่นการนับและการกรอง) สิ่งที่สงสัยคือความซับซ้อนของการอ่านและการดีบักรหัสดังกล่าวในกรณีที่การทดสอบล้มเหลว

18 c#  unit-testing  linq  iterator  assertions 

ฉันกำลังทำงานกับเครื่องมือเปรียบเทียบรายการเพื่อช่วยในการจัดเรียงรายการผลการค้นหาที่ไม่เรียงลำดับตามข้อกำหนดเฉพาะจากลูกค้าของเรา ข้อกำหนดเรียกร้องให้อัลกอริทึมความเกี่ยวข้องจัดอันดับด้วยกฎต่อไปนี้ตามลำดับความสำคัญ: ตรงกับชื่อ คำค้นหาทั้งหมดในชื่อหรือคำพ้องความหมายของผลลัพธ์ คำค้นหาบางคำในชื่อหรือคำพ้องความหมายของผลลัพธ์ (% จากมากไปหาน้อย) คำทั้งหมดของคำค้นหาในคำอธิบาย คำบางส่วนของคำค้นหาในคำอธิบาย (% มากไปหาน้อย) วันที่แก้ไขล่าสุดจากมากไปน้อย ตัวเลือกการออกแบบตามธรรมชาติสำหรับตัวเปรียบเทียบนี้ดูเหมือนจะเป็นอันดับที่จัดอันดับขึ้นอยู่กับพลังของ 2 ผลรวมของกฎที่สำคัญน้อยกว่านั้นไม่สามารถเป็นได้มากกว่าการจับคู่เชิงบวกกับกฎที่มีความสำคัญสูงกว่า นี่คือความสำเร็จโดยคะแนนต่อไปนี้: 32 16 8 (คะแนน tie-breaker รองตาม% จากมากไปน้อย) 4 2 (คะแนน tie-breaker รองตาม% จากมากไปน้อย) 1 ในจิตวิญญาณ TDD ฉันตัดสินใจเริ่มต้นด้วยการทดสอบหน่วยของฉันก่อน ในการมีกรณีทดสอบสำหรับแต่ละสถานการณ์ที่ไม่ซ้ำกันจะต้องมีอย่างน้อย 63 กรณีทดสอบที่ไม่ซ้ำกันโดยไม่พิจารณากรณีทดสอบเพิ่มเติมสำหรับตรรกะตัวแบ่งลำดับที่สองในกฎข้อที่ 3 และ 5 ซึ่งดูเหมือนจะเป็นเรื่องที่น่ากลัว การทดสอบจริงจะน้อยลง ตามกฎจริงเองกฎบางอย่างทำให้มั่นใจได้ว่ากฎที่ต่ำกว่าจะเป็นจริงเสมอ (เช่นเมื่อ 'คำค้นหาทั้งหมดปรากฏในคำอธิบาย' จากนั้นกฎ 'คำค้นหาคำบางคำที่ปรากฏในคำอธิบาย' จะเป็นจริงเสมอ) ยังคงมีระดับความพยายามในการเขียนแต่ละกรณีทดสอบเหล่านี้คุ้มค่าหรือไม่ นี่เป็นระดับของการทดสอบที่มักจะถูกเรียกเมื่อพูดถึงการครอบคลุมการทดสอบ 100% …

18 algorithms  unit-testing  tdd 

“ ทำไมแค่คิดว่าการทดสอบของคุณดีเมื่อคุณรู้แน่? บางครั้งเจสเตอร์บอกการทดสอบของฉันว่าเป็นสุญญากาศ แต่บางครั้งการเปลี่ยนแปลงที่พบก็เกิดขึ้นราวกับสายฟ้าออกจากสีน้ำเงิน แนะนำเป็นอย่างยิ่ง” - Kent Beck แต่ฉันเห็นว่าไม่มีแม้แต่แท็กที่ชื่อว่า " Jester " ใน stackoverflow ดังนั้นสิ่งที่ทดแทนที่ทันสมัยสำหรับเจสเตอร์ถ้ามี? เราจะแน่ใจได้อย่างไรว่าการทดสอบหน่วยที่เขียนไว้นั้นมั่นคงกว่าการค้นหาสถิติจากการครอบคลุมโค้ดจากเครื่องมือเช่นCoberturaและClover ?

18 java  unit-testing  code-quality  tdd 

บริบท: ฉันกำลังทำงานในโครงการขนาดเล็กใน Python ฉันมักจะจัดโครงสร้างชั้นเรียนของฉันด้วยวิธีสาธารณะบางอย่างที่มีการจัดทำเป็นเอกสาร แต่ส่วนใหญ่จะจัดการกับแนวคิดระดับสูง (สิ่งที่ผู้ใช้ของชั้นเรียนควรรู้และใช้) และวิธีซ่อนเร้น (เริ่มต้นด้วยขีดเส้นใต้) ซึ่งรับผิดชอบ การประมวลผลที่ซับซ้อนหรือระดับต่ำ ฉันรู้ว่าการทดสอบมีความสำคัญต่อความมั่นใจในโค้ดและเพื่อให้แน่ใจว่าการดัดแปลงใด ๆ ในภายหลังจะไม่ทำให้พฤติกรรมก่อนหน้านี้เสียหาย ปัญหา: เพื่อสร้างวิธีสาธารณะในระดับที่สูงขึ้นบนฐานที่เชื่อถือได้ฉันมักจะทดสอบวิธีส่วนตัว ฉันพบว่าการแก้ไขรหัสได้แนะนำการถดถอยและตำแหน่งที่ง่ายขึ้นหรือไม่ หมายความว่าการทดสอบภายในเหล่านั้นสามารถทำลายการแก้ไขเล็กน้อยและจะต้องแก้ไข / แทนที่ แต่ฉันก็รู้ด้วยเช่นกันว่าการทดสอบหน่วยวิธีส่วนตัวนั้นเป็นแนวคิดที่ขัดแย้งกันหรืออย่างน้อยก็ถือว่าเป็นแนวปฏิบัติที่ไม่ดี เหตุผล: เป็นเพียงพฤติกรรมสาธารณะเท่านั้นที่ควรได้รับการทดสอบ ( อ้างอิง ) คำถาม: ฉันสนใจเกี่ยวกับการปฏิบัติตามแนวทางปฏิบัติที่ดีที่สุดและต้องการที่จะเข้าใจ: เหตุใดการใช้การทดสอบหน่วยในวิธีส่วนตัว / ซ่อนเร้นจึงไม่ดี (ความเสี่ยงคืออะไร) แนวปฏิบัติที่ดีที่สุดคืออะไรเมื่อวิธีสาธารณะสามารถใช้ระดับต่ำและ / หรือการประมวลผลที่ซับซ้อน ความแม่นยำ: มันไม่ได้เป็นวิธีการที่จะคำถาม Python ไม่มีแนวคิดเรื่องความเป็นส่วนตัวที่แท้จริงและวิธีการซ่อนเร้นไม่ได้อยู่ในรายการ แต่สามารถใช้เมื่อคุณทราบชื่อ ฉันไม่เคยได้รับการสอนกฎและรูปแบบการเขียนโปรแกรม: ชั้นเรียนสุดท้ายของฉันมาจากยุค 80 ... ฉันได้เรียนรู้ภาษาเป็นหลักด้วยการลองผิดลองถูกและการอ้างอิงบนอินเทอร์เน็ต

18 python  unit-testing  methods 

ฉันต้องการส่งรหัสทดสอบพร้อมกับผลิตภัณฑ์ โดยเฉพาะให้ตัวเลือกเพื่อให้ทุกคนที่มีสำเนาของโปรแกรมของเราสามารถกดปุ่ม "ทดสอบตัวเอง" หรือผ่าน - ทดสอบตัวเองในบรรทัดคำสั่งและเรียกใช้ผ่านชุดที่สมบูรณ์ของหน่วย | การทดสอบแบบรวม ฉันต้องการทำสิ่งนี้เป็นส่วนใหญ่เพื่อช่วยแก้ไขปัญหาที่พบในเขตข้อมูลดังนั้นเมื่อรายงานข้อผิดพลาดได้รับจากผู้ใช้ปลายทางมีโอกาสที่จะได้รับการสนับสนุนจาก "และการทดสอบทั้งสามนี้ล้มเหลวในเครื่องของฉัน" ฉันต้องการให้ผู้ทดสอบด้วยตนเองสามารถเรียกใช้หน่วย | รวมการทดสอบเช่นกัน อย่างไรก็ตามการทดสอบของทีมเชื่อว่ารหัสทดสอบไม่ใช่รหัสการผลิตและดังนั้นจะไม่ถูกจัดส่ง ฉันไม่ได้รับเรื่องนี้จริง ๆ เนื่องจากโครงการโอเพ่นซอร์สส่วนใหญ่จะจัดส่งชุดทดสอบ มันดูเหมือนจะผิดปกติในซอฟต์แวร์ปิด ฉันต้องการหลักฐานสนับสนุนหรือเกร็ดเล็กเกร็ดน้อยทั้งสองด้านของการโต้แย้ง ฉันคาดเดาได้ดีที่สุดว่าไซต์แลกเปลี่ยนสแต็คใดที่เหมาะสมที่สุด แต่โปรดแจ้งให้เราทราบว่าสิ่งนี้อยู่นอกสถานที่หรือไม่

17 c++  unit-testing  testing 

ฉันมีวิธีการทางตรรกะทางธุรกิจจำนวนมากที่เก็บและดึงข้อมูล (พร้อมการกรอง) วัตถุและรายการวัตถุจากแคช พิจารณา IList<TObject> AllFromCache() { ... } TObject FetchById(guid id) { ... } IList<TObject> FilterByPropertry(int property) { ... } Fetch..และFilter..จะเรียกAllFromCacheซึ่งจะเติมแคชและส่งคืนถ้ามันไม่ได้มีและเพียงแค่กลับมาจากมันถ้ามันเป็น ฉันมักจะอายห่างจากการทดสอบหน่วยเหล่านี้ แนวปฏิบัติที่ดีที่สุดสำหรับการทดสอบหน่วยกับโครงสร้างประเภทนี้คืออะไร ฉันถือว่าการเติมแคชใน TestInitialize และลบบน TestCleanup แต่นั่นไม่รู้สึกว่าถูกต้องสำหรับฉัน (อาจเป็นได้)

17 unit-testing  caching 

ฉันกำลังเขียนเกมและเอ็นจิ้นกราฟิคประกอบบน OpenGL ใน C ++ ฉันยังเป็นแฟนของกระบวนการเข้ารหัสที่ดีและการทดสอบอัตโนมัติ การทดสอบรหัสกราฟฟิก + นั้นดูเหมือนจะไม่สามารถเปลี่ยนแปลงได้เนื่องจากผลลัพธ์มักจะเป็นเพียงการแสดงผลเท่านั้น ตัวอย่างเช่นลองนึกภาพการวิเคราะห์สตรีมรูปภาพดิบที่เรนเดอร์ไปที่หน้าจอไบต์ต่อไบต์ - คุณต้องทดสอบข้อมูลเพื่อเปรียบเทียบกับซึ่งยากที่จะสร้าง / รับและบ่อยครั้งที่รูปภาพที่แสดงไม่เหมือนกันใน ระดับไบต์เมื่อทำงานในเวลาที่ต่างกัน - การเปลี่ยนแปลงเล็กน้อยในอัลกอริทึมจะทำลายวิธีการนี้อย่างสมบูรณ์ ฉันกำลังคิดที่จะสร้างชุดทดสอบแบบเห็นภาพซึ่งโดยทั่วไปฉันสามารถสร้างฉากทดสอบที่แตกต่างกันแสดงสิ่งต่าง ๆ เช่นการทำแผนที่เงาภาพเคลื่อนไหว ฯลฯ ฯลฯ โดยเป็นส่วนหนึ่งของ CI ฉากเหล่านี้จะถูกแสดงเป็นวิดีโอ ไฟล์ (หรืออาจปล่อยไว้เป็นไฟล์ที่เรียกทำงานได้) ที่มีเมทริกต่างกัน สิ่งนี้จะยังคงต้องการการตรวจสอบไฟล์วิดีโอด้วยตนเอง แต่อย่างน้อยที่สุดมันก็ค่อนข้างอัตโนมัติและเป็นมาตรฐาน คุณคิดอย่างไร? ฉันหวังว่าจะมีวิธีที่ดีกว่า

17 c++  unit-testing  graphics  opengl  test-automation 

ปิด. คำถามนี้เป็นคำถามปิดหัวข้อ ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัพเดตคำถามเพื่อให้เป็นหัวข้อสำหรับ Software Engineering Stack Exchange ปิดให้บริการใน6 ปีที่ผ่านมา มีแอพพลิเคชั่นโอเพนซอร์ซที่พัฒนาขึ้นโดยใช้การพัฒนาแบบทดสอบที่ทำหน้าที่เป็นตัวอย่างของการทดสอบหน่วยที่ดี ฉันต้องการดูตัวอย่างใน C # และ. NET (โปรดทราบว่าฉันพูดถึงแอปพลิเคชันไม่ใช่เฉพาะห้องสมุด) ฉันเป็นโปรแกรมเมอร์ระดับกลางที่ต้องการเชื่อและฝึกฝน TDD จริงๆ แอพที่ฉันทำงานในงานประจำวันนั้นค่อนข้างซับซ้อน - มีโค้ดประมาณ 1 ล้านบรรทัดและฉันชอบที่จะแนะนำการทดสอบหน่วยเพิ่มเติม เรามีการทดสอบหน่วยในสถานที่ แต่ความพยายามของฉันที่ TDD และการทำงานกับรหัสที่อยู่ภายใต้การทดสอบยังไม่ได้รับการสนับสนุน จากประสบการณ์ที่ จำกัด ของฉันดูเหมือนว่า TDD จะส่งเสริมความซับซ้อนมากมายในนามของการแยก บิตของแอปที่ยากต่อการทดสอบ - และที่บังเอิญมีแนวโน้มจะสำคัญ - ถูกผลักออกไปที่ขอบนอกสู่ขอบเขตของการทดสอบการรวมที่อาจหรือไม่อาจถูกเขียนขึ้นมา (ฉันกำลังคิดถึงผู้ต้องสงสัยตามปกติที่นี่การเข้าถึงระบบไฟล์การให้ความชุ่มชื้นวัตถุจากฐานข้อมูลการโทรทางเว็บแบบอะซิงโครนัส ฯลฯ ) รหัสที่อยู่ภายใต้การทดสอบมีแนวโน้มที่จะเกี่ยวข้องกับการทำงานร่วมกันระหว่างวัตถุและอาจมีตรรกะการไหลอย่างง่าย ๆ ซึ่งทั้งหมดเกิดขึ้นในหน่วยความจำและสามารถเขียนได้ในวิธีที่ง่ายกว่าและเข้าใจได้มากกว่า สำหรับการทดสอบ ฉันเข้าใจเทคนิคในการล้อเลียนการอ้างอิงและเช่นนี้ แต่ในประสบการณ์ของฉันการใช้การเยาะเย้ยอย่างหนักนำไปสู่การทดสอบที่เปราะบางมาก ถ้าสัญชาตญาณแรกของฉันเมื่อเห็นการทดสอบเป็นสีแดงก็คือ …

17 unit-testing  tdd 

ข้อมูลประกอบ: ฉันคิดว่าจะพยายามนำเสนอแนวคิดของการทดสอบหน่วยกับเพื่อนร่วมงานของฉันโดยสร้างบางอย่างสำหรับโมดูลที่ฉันทำงานอยู่ ข้อกำหนดของมันเพิ่งเปลี่ยนไปและต้องการ abstractions / interactions เพิ่มเติมดังนั้นจึงเป็นวิธีที่ดีในการพัฒนาชุดการทดสอบที่จะ "พิสูจน์" ว่าใช้งานได้โดยไม่ต้องใช้แอปพลิเคชันด้วยตนเอง อย่างไรก็ตามปัญหาคือโมดูลนั้นขึ้นอยู่กับปัจจัยภายนอกที่ไม่สามารถยกเลิกได้เช่น PDF และ XSL โดยทั่วไปฉันอ่าน XML จากฐานข้อมูลและใช้การแปลง XSL กับมันจากนั้นแปลงเป็น PDF โดยใช้ไลบรารีที่เรียกว่า ABCPDF PDF นี้จะถูกรวมเข้ากับ PDF อื่นตามแม่แบบคงที่ ฉันรู้ว่าฉันสามารถทดสอบ XML และตรวจสอบให้แน่ใจว่าค่านั้นถูกต้อง แต่ข้อบกพร่องที่เป็นไปได้จำนวนมากและปัญหาที่เกี่ยวข้องกับการแสดงผลที่แท้จริงของเอกสารที่เสร็จแล้ว - เช่น minutiae เช่นสตริงข้อความยาวแค่ไหน ตั้งอยู่ในความสัมพันธ์กับเอกสาร ฯลฯ เป็นไปได้หรือไม่ที่จะทดสอบสิ่งเหล่านี้ (ฉันรู้ว่าสิ่งเหล่านี้อาจเป็นการทดสอบการรวมหรือการทดสอบประเภทที่สามที่ชื่อฉันลืม [ไม่ใช่แบบทดสอบการยอมรับประเภทอื่น] และไม่ใช่หน่วย การทดสอบ) เนื่องจากฉันไม่สามารถรู้ได้ว่าจะลอกแบบ PDF สั้น ๆ ง่ายๆจากการสร้างจากนั้นอ่านกลับหรือสร้างสตริง HTML (เช่นแปลง XML) และแยกวิเคราะห์ด้วยมือเพื่อตรวจสอบว่ามีเซลล์ตารางบางตัวใน ความสัมพันธ์กับเซลล์ตารางอื่น …

17 unit-testing 

เราเพิ่งค้นพบปัญหาเฉพาะสถานที่เกิดเหตุในแอปพลิเคชันของเราและในขณะที่แก้ไขได้ง่าย (เมื่อเราทราบว่าเกิดอะไรขึ้น) ก็มีทีมที่ฉันคิดเกี่ยวกับการทดสอบหน่วยในเรื่องนี้ เราต้องการที่จะจับปัญหาเหล่านี้ในไม่ช้าโดยเฉพาะอย่างยิ่งก่อนที่พวกเขาจะถูกค้นพบโดยลูกค้าและเราต้องการที่จะปกป้องตัวเองจากการแนะนำข้อผิดพลาดเฉพาะสถานที่เกิดเหตุในอนาคต แต่การทำซ้ำทุกการทดสอบหน่วย เหนือศีรษะ คุณจะทำอย่างไรหรือวิธีการทดสอบหน่วยหลายสถานที่?

17 unit-testing  localization 

สมมติว่าเรามีแอปพลิเคชันระดับองค์กรขนาดใหญ่โดยไม่มีการทดสอบหน่วย / การทำงานใด ๆ ไม่มีกระบวนการพัฒนาที่ขับเคลื่อนด้วยการทดสอบในระหว่างการพัฒนาอันเนื่องมาจากกำหนดเวลาที่เข้มงวดมาก (ฉันรู้ว่าเราไม่ควรสัญญาวันครบกำหนดที่แน่นเมื่อเราไม่แน่ใจ แต่สิ่งที่ทำเสร็จแล้ว!) ตอนนี้ทุกอย่างผ่านไปและทุกอย่างสงบลงทุกคนตกลงที่จะเปลี่ยนเราให้เป็นทีมงานที่มีประสิทธิผลของ TDD / BDD ... ตอนนี้คำถามเกี่ยวกับรหัสที่เรามีอยู่แล้ว: (1) มันยังไม่เป็นไรหรือเป็นความคิดที่ดีที่จะหยุดการพัฒนาส่วนใหญ่และเริ่มเขียนกรณีทดสอบที่เป็นไปได้ทั้งหมดตั้งแต่เริ่มต้นถึงแม้ว่าทุกอย่างจะทำงานได้อย่างสมบูรณ์ ? หรือ (2) เป็นการดีกว่าที่จะรอสิ่งที่ไม่ดีเกิดขึ้นจากนั้นในระหว่างการแก้ไขการทดสอบหน่วยการทดสอบใหม่หรือ (3) แม้กระทั่งลืมรหัสก่อนหน้าและเพียงแค่เขียนการทดสอบหน่วยสำหรับรหัสใหม่เท่านั้นและเลื่อนทุกอย่าง มีไม่กี่ที่ดีและบทความที่เกี่ยวข้องเช่นนี้ ฉันยังไม่แน่ใจว่ามันคุ้มค่าหรือไม่ที่จะพิจารณาเรื่องนี้เพราะเรามีเวลา จำกัด และโครงการ / งานอื่น ๆ อีกมากมายกำลังรอเราอยู่ หมายเหตุ : คำถามนี้อธิบาย / จินตนาการถึงสถานการณ์ที่น่าอึดอัดใจในทีมพัฒนา นี่ไม่เกี่ยวกับฉันหรือเพื่อนร่วมงานของฉัน มันเป็นเพียงสถานการณ์ในจินตนาการ คุณอาจคิดว่าสิ่งนี้ไม่ควรเกิดขึ้นหรือผู้จัดการฝ่ายพัฒนารับผิดชอบต่อความยุ่งเหยิง! แต่อย่างไรก็ตามสิ่งที่ทำเสร็จแล้ว หากเป็นไปได้โปรดอย่าโหวตเพราะคุณคิดว่าสิ่งนี้จะไม่เกิดขึ้น

17 unit-testing  testing  tdd  bdd  acceptance-testing