มันเพียงพอแล้วหรือไม่ที่จะใช้การทดสอบการยอมรับและการรวมเข้าด้วยกันแทนที่จะเป็นการทดสอบหน่วย?

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

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

ที่ทำงานฉันมีรหัสดั้งเดิมมากมาย ที่นี่ฉันเขียนมากขึ้นและมากขึ้นการทดสอบการยอมรับและการทดสอบหน่วยน้อย สิ่งนี้ดูเหมือนจะไม่ใช่วิธีที่ไม่ดีเนื่องจากข้อบกพร่องส่วนใหญ่ถูกตรวจพบโดยการทดสอบการยอมรับและการรวม

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

หลังจากที่ผมถูกมองผ่านทางเว็บผมพบว่ามีความคิดที่คล้ายกันมากกับเหมืองกล่าวถึงที่นี่และมี คุณคิดอย่างไรกับความคิดนี้

แก้ไข

การตอบคำถามตัวอย่างหนึ่งที่การออกแบบนั้นดี แต่ฉันต้องการการรีแฟคเตอร์ขนาดใหญ่สำหรับข้อกำหนดต่อไป:

ตอนแรกมีข้อกำหนดบางประการในการดำเนินการคำสั่งบางอย่าง ฉันเขียนตัวแยกวิเคราะห์คำสั่งที่ขยายได้ - ซึ่งคำสั่งแยกวิเคราะห์จากพรอมต์คำสั่งบางชนิดและเรียกสิ่งที่ถูกต้องในรูปแบบ ผลลัพธ์ถูกแสดงในคลาสโมเดลมุมมอง:

ไม่มีอะไรผิดปกติที่นี่ ทุกคลาสมีความเป็นอิสระจากกันและฉันสามารถเพิ่มคำสั่งใหม่แสดงข้อมูลใหม่ได้อย่างง่ายดาย

ข้อกำหนดต่อไปคือทุกคำสั่งควรมีมุมมองเป็นของตนเอง - ตัวอย่างบางส่วนของผลลัพธ์ของคำสั่ง ฉันออกแบบโปรแกรมใหม่เพื่อให้ได้การออกแบบที่ดีขึ้นสำหรับข้อกำหนดใหม่:

สิ่งนี้ก็เป็นสิ่งที่ดีเพราะตอนนี้ทุกคำสั่งมีรูปแบบมุมมองของตัวเองและตัวอย่างของมันเอง

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

ทั้งหมดที่ฉันอยากรู้ ณ จุดนี้คือถ้าการออกแบบใหม่ไม่ทำลายข้อกำหนดที่มีอยู่ ฉันไม่ต้องเปลี่ยนการทดสอบตอบรับใด ๆ ฉันต้อง refactor หรือลบการทดสอบเกือบทุกหน่วยซึ่งเป็นกองงานขนาดใหญ่

สิ่งที่ฉันต้องการแสดงที่นี่เป็นสถานการณ์ทั่วไปที่เกิดขึ้นบ่อยครั้งในระหว่างการพัฒนา ไม่มีปัญหากับการออกแบบเก่าหรือใหม่พวกเขาเพียงแค่เปลี่ยนไปตามข้อกำหนด - ฉันเข้าใจได้อย่างไรนี่เป็นข้อดีอย่างหนึ่งของ TDD ที่การออกแบบวิวัฒนาการ

ข้อสรุป

ขอบคุณสำหรับคำตอบและการอภิปรายทั้งหมด ในบทสรุปของการสนทนานี้ฉันมีความคิดของวิธีการที่ฉันจะทดสอบกับโครงการต่อไปของฉัน

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

มันเปรียบเทียบส้มกับแอปเปิ้ล

การทดสอบการรวมการทดสอบการยอมรับการทดสอบหน่วยการทดสอบพฤติกรรม - เป็นการทดสอบทั้งหมดและพวกเขาทั้งหมดจะช่วยคุณในการปรับปรุงโค้ดของคุณ แต่มันก็ค่อนข้างแตกต่างกัน

ฉันจะไปดูการทดสอบที่แตกต่างกันในความคิดของฉันและหวังว่าจะอธิบายว่าทำไมคุณต้องมีการผสมผสานทั้งหมดของพวกเขา:

การทดสอบการรวม:

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

การทดสอบการยอมรับ:

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

การทดสอบหน่วย:

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

การทดสอบพฤติกรรม:

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

ทั้งหมดนี้อยู่ในความคิดของฉันผ่านประสบการณ์การเขียนแบบทดสอบมากมาย ฉันไม่ชอบที่จะให้ความสำคัญกับแนวทางของตำราเรียน แต่ให้ความสำคัญกับสิ่งที่ให้คุณค่ากับการทดสอบของคุณ

TL; DR:ตราบใดที่มันตอบสนองความต้องการของคุณได้

ฉันทำการพัฒนาแบบทดสอบตอบรับการยอมรับ (ATDD) มาหลายปีแล้ว มันสามารถประสบความสำเร็จมาก มีบางสิ่งที่ต้องระวัง

• การทดสอบหน่วยจะช่วยบังคับใช้ IOC อย่างแท้จริง หากไม่มีการทดสอบหน่วย onus จะอยู่ในกลุ่มผู้พัฒนาเพื่อให้แน่ใจว่าตรงตามข้อกำหนดของโค้ดที่เขียนได้ดี
• พวกเขาสามารถช้าลงและมีความล้มเหลวที่ผิดพลาดหากคุณใช้ทรัพยากรที่มักจะล้อเลียน
• การทดสอบไม่ได้ระบุปัญหาเฉพาะตามที่หน่วยทดสอบต้องการ คุณต้องทำการตรวจสอบเพิ่มเติมเพื่อแก้ไขความล้มเหลวในการทดสอบ

ตอนนี้ผลประโยชน์

• ครอบคลุมการทดสอบที่ดีขึ้นมากครอบคลุมคะแนนการรวม
• มั่นใจว่าระบบโดยรวมเป็นไปตามเกณฑ์การยอมรับซึ่งเป็นจุดรวมของการพัฒนาซอฟต์แวร์
• ทำให้ refactors ขนาดใหญ่ง่ายขึ้นเร็วขึ้นและถูกลง

ขึ้นอยู่กับคุณที่จะทำการวิเคราะห์และพิจารณาว่าการฝึกฝนนี้เหมาะสมกับสถานการณ์ของคุณหรือไม่ ฉันไม่คิดว่าจะมีคำตอบที่ถูกต้อง มันจะขึ้นอยู่กับความต้องการและความต้องการของคุณ

ฉันใช้วิธี TDD เหมือนวิธีการเพื่อให้การทดสอบ / ความต้องการพัฒนาการออกแบบของโปรแกรม ปัญหาคือกว่าครึ่งหนึ่งของเวลาในการพัฒนาสำหรับการทดสอบการเขียน / การรีแฟคเตอร์

การทดสอบหน่วยทำงานได้ดีที่สุดเมื่อส่วนต่อประสานสาธารณะของส่วนประกอบที่ใช้ไม่เปลี่ยนแปลงบ่อยเกินไป ซึ่งหมายความว่าเมื่อส่วนประกอบได้รับการออกแบบมาอย่างดีแล้ว (เช่นปฏิบัติตามหลักการของ SOLID)

ดังนั้นการเชื่อว่าการออกแบบที่ดีเพียง "วิวัฒนาการ" จาก "การขว้าง" การทดสอบหน่วยจำนวนมากที่องค์ประกอบนั้นเป็นความเข้าใจผิด TDD ไม่ใช่ "อาจารย์" สำหรับการออกแบบที่ดีมันสามารถช่วยได้เพียงเล็กน้อยในการตรวจสอบว่าการออกแบบบางอย่างนั้นดี (โดยเฉพาะอย่างยิ่งการทดสอบ)

เมื่อความต้องการของคุณเปลี่ยนไปและคุณต้องเปลี่ยน internals ของส่วนประกอบและสิ่งนี้จะทำลาย 90% ของการทดสอบหน่วยของคุณดังนั้นคุณต้องปรับโครงสร้างบ่อยครั้งมากจากนั้นการออกแบบส่วนใหญ่อาจไม่ดีนัก

ดังนั้นคำแนะนำของฉันคือ: คิดถึงการออกแบบส่วนประกอบที่คุณสร้างขึ้นและวิธีที่คุณสามารถทำให้พวกเขาทำตามหลักการเปิด / ปิดได้มากขึ้น แนวคิดหลังคือเพื่อให้แน่ใจว่าการทำงานของส่วนประกอบของคุณสามารถขยายได้ในภายหลังโดยไม่ต้องเปลี่ยนพวกเขา (และไม่ทำลายส่วนประกอบ API ที่ใช้โดยการทดสอบหน่วยของคุณ) ส่วนประกอบดังกล่าวสามารถ (และควร) ครอบคลุมโดยการทดสอบการทดสอบหน่วยและประสบการณ์ไม่ควรเจ็บปวดอย่างที่คุณอธิบาย

เมื่อคุณไม่สามารถออกแบบได้ทันทีการทดสอบการยอมรับและการรวมเข้าด้วยกันอาจเป็นการเริ่มต้นที่ดีกว่า

แก้ไข: บางครั้งการออกแบบส่วนของคุณสามารถปรับ แต่การออกแบบของการทดสอบหน่วยของคุณอาจทำให้เกิดปัญหา ตัวอย่างง่าย ๆ : คุณต้องการทดสอบวิธีการ "MyMethod" ของคลาส X และเขียน

    var x= new X();
    Assert.AreEqual("expected value 1" x.MyMethod("value 1"));
    Assert.AreEqual("expected value 2" x.MyMethod("value 2"));
    // ...
    Assert.AreEqual("expected value 500" x.MyMethod("value 500"));

(ถือว่าค่ามีความหมายบางอย่าง)

สมมติเพิ่มเติมว่าในรหัสการผลิตมีเพียงการโทรX.MyMethodเดียว ตอนนี้สำหรับข้อกำหนดใหม่เมธอด "MyMethod" ต้องการพารามิเตอร์เพิ่มเติม (ตัวอย่างเช่นบางอย่างcontext) ซึ่งไม่สามารถข้ามได้ หากไม่มีการทดสอบหน่วยเราจะต้องสร้างรหัสการโทรซ้ำในที่เดียว ด้วยการทดสอบหน่วยหนึ่งต้อง refactor 500 แห่ง

แต่สาเหตุที่นี่ไม่ใช่หน่วยทดสอบเองมันเป็นความจริงที่ว่าการเรียกซ้ำ "X.MyMethod" ซ้ำแล้วซ้ำอีกไม่ได้ปฏิบัติตามหลักการ "อย่าทำซ้ำตัวเอง (DRY) อย่างเคร่งครัดดังนั้นวิธีการแก้ไข นี่คือการใส่ข้อมูลการทดสอบและค่าที่คาดหวังที่เกี่ยวข้องในรายการและเรียกการเรียกไปที่ "MyMethod" ในลูป (หรือหากเครื่องมือทดสอบสนับสนุนที่เรียกว่า "การทดสอบไดรฟ์ข้อมูล" เพื่อใช้คุณสมบัตินั้น) จำนวนสถานที่ที่จะเปลี่ยนในการทดสอบหน่วยเมื่อวิธีการเปลี่ยนลายเซ็นเป็น 1 (ตรงข้ามกับ 500)

ในกรณีจริงของคุณสถานการณ์อาจซับซ้อนกว่านี้ แต่ฉันหวังว่าคุณจะได้รับแนวคิด - เมื่อหน่วยทดสอบของคุณใช้ส่วนประกอบ API ที่คุณไม่ทราบว่าอาจมีการเปลี่ยนแปลงหรือไม่ให้แน่ใจว่าคุณลดจำนวนลง การโทรไปยัง API นั้นให้น้อยที่สุด

ใช่แน่นอนมันคือ

พิจารณาสิ่งนี้:

• การทดสอบหน่วยเป็นการทดสอบชิ้นเล็ก ๆ ที่มีเป้าหมายซึ่งจะฝึกรหัสขนาดเล็ก คุณเขียนจำนวนมากเพื่อให้ได้รหัสครอบคลุมที่เหมาะสมเพื่อให้ทุกคน (หรือบิตส่วนใหญ่อึดอัดใจ) ได้รับการทดสอบ
• การทดสอบการรวมเป็นชิ้นใหญ่ของการทดสอบที่กว้างที่ออกกำลังกายรหัสของคุณ คุณเขียนบางส่วนของพวกเขาเพื่อให้ได้รหัสครอบคลุมที่เหมาะสมเพื่อให้ทดสอบทั้งหมด (หรือบิตส่วนใหญ่ที่น่าอึดอัดใจ)

ดูความแตกต่างโดยรวม ....

ปัญหานี้เป็นหนึ่งในการครอบคลุมโค้ดหากคุณสามารถทำการทดสอบทั้งหมดของรหัสของคุณโดยใช้การทดสอบการรวม / การยอมรับแล้วก็ไม่มีปัญหา รหัสของคุณผ่านการทดสอบแล้ว นั่นคือเป้าหมาย

ฉันคิดว่าคุณอาจจำเป็นต้องรวมมันเป็นทุกโครงการที่ใช้ TDD จะต้องมีการทดสอบบูรณาการเพียงเพื่อให้แน่ใจว่าทุกหน่วยทำงานร่วมกันได้ดีจริง ๆ (ฉันรู้จากประสบการณ์ว่า 100% ผ่านการทดสอบ codebase หน่วยไม่จำเป็นต้องทำงาน เมื่อคุณรวมทั้งหมดเข้าด้วยกัน!)

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

ไม่ว่าจะด้วยวิธีใดคุณยังคงได้รับรหัสทดสอบคุณเพียงแค่ต้องตัดสินใจว่ากลไกใดที่เหมาะกับคุณดีกว่า (ฉันจะไปกับการผสมผสานหน่วยทดสอบอัลกอริทึมที่ซับซ้อนและรวมทดสอบส่วนที่เหลือ)

ฉันคิดว่ามันเป็นความคิดที่น่ากลัว

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

ไม่คุณมักจะเขียนการทดสอบหน่วยเพิ่มเติมเว้นแต่ว่าคุณจะมีแอพแปลก ๆ ที่เป็น 90% UI หรืออย่างอื่นที่ทดสอบการทดสอบหน่วยได้อย่างไม่น่าเชื่อ ความเจ็บปวดที่คุณพบไม่ใช่จากการทดสอบหน่วย แต่ทำการทดสอบก่อนพัฒนา โดยทั่วไปคุณควรใช้เวลาเพียง 1/3 ในการทดสอบการเขียนส่วนใหญ่ ท้ายที่สุดพวกเขาอยู่ตรงนั้นเพื่อรับใช้คุณไม่ใช่กลับกัน

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

นี่คือที่มา BDD เป็นพฤติกรรมที่สามารถรวมอยู่ในการทดสอบหน่วยเพื่อให้กระบวนการโดยนิยามที่เป็นนามธรรมน้อยลงและเป็นรูปธรรมมากขึ้น

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

ทั้งหมดนี้นำไปสู่ข้อสรุปว่าการทดสอบที่ให้คุณค่ามากที่สุดควรอยู่ที่ด้านหน้าของกระบวนการ ในตัวมันเองไม่ชอบการทดสอบประเภทหนึ่งโดยอัตโนมัติมากกว่า - แต่ละกรณีจะต้องได้รับประโยชน์

หากคุณกำลังเขียนวิดเจ็ตบรรทัดคำสั่งสำหรับการใช้งานส่วนตัวคุณจะสนใจการทดสอบหน่วยเป็นหลัก ในขณะที่บริการเว็บกล่าวว่าจะต้องมีการทดสอบบูรณาการ / พฤติกรรมจำนวนมาก

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

ข้อได้เปรียบสุดท้ายของการทดสอบหน่วยคือพวกมันเร็วกว่า ฉันได้เขียนการทดสอบการรวมเข้าด้วยกันพอที่จะรู้ว่าพวกเขาสามารถทำได้เร็วเท่ากับการทดสอบหน่วย

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

แน่นอนการทดสอบหน่วยกำลังช้าลงเช่นกัน แต่ก็ยังมีขนาดที่ใหญ่กว่าเร็วกว่า ตัวอย่างเช่นในโครงการก่อนหน้าของฉัน (c ++ บางการทดสอบ 600 kLOC, 4000 หน่วยและการทดสอบการรวม 200 ครั้ง) ใช้เวลาประมาณหนึ่งนาทีในการดำเนินการทั้งหมดและมากกว่า 15 รายการเพื่อดำเนินการทดสอบการรวม ในการสร้างและดำเนินการทดสอบหน่วยสำหรับชิ้นส่วนที่ถูกเปลี่ยนจะใช้เวลาโดยเฉลี่ยน้อยกว่า 30 วินาที เมื่อคุณทำได้เร็วคุณจะต้องทำตลอดเวลา

เพียงเพื่อให้ชัดเจน: ฉันไม่ได้บอกว่าจะไม่เพิ่มการทดสอบการรวมและการยอมรับ แต่ดูเหมือนว่าคุณทำ TDD / BDD ในทางที่ผิด

การทดสอบหน่วยก็ดีสำหรับการออกแบบเช่นกัน

ใช่การออกแบบที่คำนึงถึงการทดสอบจะทำให้การออกแบบดีขึ้น

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

เมื่อความต้องการเปลี่ยนแปลงคุณต้องเปลี่ยนรหัส ฉันจะบอกคุณว่างานของคุณไม่เสร็จถ้าคุณไม่ได้เขียนบททดสอบ แต่นั่นไม่ได้หมายความว่าคุณควรมีความคุ้มครอง 100% ด้วยการทดสอบหน่วย - นั่นไม่ใช่เป้าหมาย บางสิ่ง (เช่น GUI หรือการเข้าถึงไฟล์, ... ) ไม่ได้มีไว้สำหรับทดสอบหน่วย

ผลลัพธ์ที่ได้คือคุณภาพของรหัสที่ดีขึ้นและการทดสอบอีกชั้นหนึ่ง ฉันจะบอกว่ามันคุ้มค่า

เรามีการทดสอบการยอมรับหลายพันครั้งและใช้เวลาตลอดทั้งสัปดาห์ในการดำเนินการทั้งหมด