BDD - ทดสอบขับเคลื่อนการพัฒนา

เมื่อคุณดูข้อมูลอ้างอิงใด ๆ เกี่ยวกับ Behavior Driven Development คุณจะพบการใช้วลีต่างๆเช่น“ BDD มาจาก TDD”,“ BDD และ TDD” หากต้องการทราบว่า BDD เกิดขึ้นได้อย่างไรเหตุใดจึงกล่าวว่ามาจาก TDD และ BDD และ TDD คืออะไรคุณต้องมีความเข้าใจ TDD

ทำไมต้องทดสอบ

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

ดังนั้นจากประสบการณ์เราได้เรียนรู้ว่าการเปิดเผยข้อบกพร่องเมื่อมีการแนะนำและแก้ไขทันทีจะคุ้มค่า ดังนั้นจึงมีความจำเป็นในการเขียนกรณีทดสอบในทุกขั้นตอนของการพัฒนาและการทดสอบ นี่คือสิ่งที่การทดสอบแบบดั้งเดิมของเราได้สอนเราซึ่งมักเรียกว่า Test-early

แนวทางการทดสอบนี้เรียกว่าแนวทางการทดสอบล่าสุดเมื่อการทดสอบเสร็จสิ้นหลังจากเสร็จสิ้นขั้นตอน

ความท้าทายด้วยวิธีทดสอบล่าสุด

มีการปฏิบัติตามแนวทาง Test-Last ในโครงการพัฒนาซอฟต์แวร์มาระยะหนึ่งแล้ว อย่างไรก็ตามในความเป็นจริงด้วยวิธีนี้เนื่องจากการทดสอบต้องรอจนกว่าขั้นตอนเฉพาะจะเสร็จสิ้นมักจะถูกมองข้ามเนื่องจาก -

  • ความล่าช้าในการเสร็จสิ้นของเวที

  • ตารางเวลาที่แน่น

  • เน้นการส่งมอบตรงเวลาข้ามการทดสอบ

นอกจากนี้ในแนวทาง Test-Last การทดสอบหน่วยที่นักพัฒนาควรจะทำมักจะถูกข้ามไป เหตุผลต่างๆที่พบนั้นขึ้นอยู่กับความคิดของนักพัฒนา -

  • พวกเขาเป็นนักพัฒนาและไม่ใช่ผู้ทดสอบ

  • การทดสอบเป็นความรับผิดชอบของผู้ทดสอบ

  • มีประสิทธิภาพในการเข้ารหัสและรหัสของพวกเขาจะไม่มีข้อบกพร่อง

สิ่งนี้ส่งผลให้ -

  • การประนีประนอมกับคุณภาพของผลิตภัณฑ์ที่จัดส่ง

  • มีความรับผิดชอบต่อคุณภาพของผู้ทดสอบเท่านั้น

  • ค่าใช้จ่ายสูงในการแก้ไขข้อบกพร่องหลังการจัดส่ง

  • ไม่สามารถได้รับความพึงพอใจของลูกค้าซึ่งจะหมายถึงการสูญเสียธุรกิจซ้ำซึ่งส่งผลต่อความน่าเชื่อถือ

ปัจจัยเหล่านี้เรียกร้องให้เปลี่ยนกระบวนทัศน์เพื่อมุ่งเน้นไปที่การทดสอบ ผลที่ได้คือวิธีทดสอบครั้งแรก

แนวทางการทดสอบครั้งแรก

แนวทาง Test-First จะแทนที่วิธีการพัฒนา inside-out (เขียนโค้ดแล้วทดสอบ) เป็นวิธีการพัฒนาภายนอก (เขียนแบบทดสอบแล้วเขียนโค้ด)

แนวทางนี้รวมอยู่ในวิธีการพัฒนาซอฟต์แวร์ต่อไปนี้ (ซึ่งเป็น Agile ด้วย) -

  • XTreme Programming (XP).

  • Test Driven Dการพัฒนา (TDD)

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

ประเด็นพื้นฐานที่ควรทราบว่าเป้าหมายคือการพัฒนาโดยอาศัยการทดสอบ

วงจร Red-Green-Refactor

Test Driven Development ใช้ในการพัฒนาโค้ดที่นำโดยการทดสอบหน่วย

Step 1 - พิจารณาโมดูลโค้ดที่จะเขียน

Step 2 - เขียนแบบทดสอบ

Step 3 - ทำการทดสอบ

การทดสอบล้มเหลวเนื่องจากยังเขียนโค้ดไม่เสร็จ ดังนั้นขั้นตอนที่ 2 มักเรียกว่าเขียนการทดสอบเพื่อล้มเหลว

Step 4 - เขียนรหัสขั้นต่ำที่เป็นไปได้เพื่อผ่านการทดสอบ

Step 5- ทำการทดสอบทั้งหมดเพื่อให้แน่ใจว่าทุกอย่างยังคงผ่าน การทดสอบหน่วยเป็นไปโดยอัตโนมัติเพื่ออำนวยความสะดวกในขั้นตอนนี้

Step 6 - Refactor.

Step 7 - ทำซ้ำขั้นตอนที่ 1 ถึงขั้นตอนที่ 6 สำหรับโมดูลรหัสถัดไป

แต่ละรอบควรสั้นมากและชั่วโมงโดยทั่วไปควรมีหลายรอบ

สิ่งนี้เรียกอีกอย่างหนึ่งว่า Red-Green-Refactor วงจรโดยที่ -

  • Red - การเขียนแบบทดสอบที่ล้มเหลว

  • Green - การเขียนโค้ดเพื่อผ่านการทดสอบ

  • Refactor - ลบการทำซ้ำและปรับปรุงรหัสให้เป็นมาตรฐานที่ยอมรับได้

ขั้นตอนกระบวนการ TDD

ขั้นตอนของกระบวนการ TDD แสดงอยู่ด้านล่าง

ข้อดีของ TDD

ประโยชน์หรือข้อดีของ Test Driven Development คือ -

  • นักพัฒนาต้องทำความเข้าใจก่อนว่าผลลัพธ์ที่ต้องการควรเป็นอย่างไรและจะทดสอบอย่างไรก่อนสร้างโค้ด

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

  • เมื่อชุดการทดสอบหน่วยทำงานหลังจากการปรับโครงสร้างใหม่แต่ละครั้งข้อเสนอแนะที่ส่วนประกอบแต่ละส่วนยังคงทำงานอยู่จะคงที่

  • การทดสอบหน่วยทำหน้าที่เป็นเอกสารประกอบการใช้ชีวิตที่ขึ้นอยู่กับข้อมูลเสมอ

  • หากพบข้อบกพร่องนักพัฒนาจะสร้างการทดสอบเพื่อเปิดเผยข้อบกพร่องนั้นจากนั้นแก้ไขโค้ดเพื่อให้การทดสอบผ่านไปและข้อบกพร่องได้รับการแก้ไข ซึ่งจะช่วยลดเวลาในการดีบัก การทดสอบอื่น ๆ ทั้งหมดจะถูกเรียกใช้ด้วยและเมื่อผ่านการทดสอบจะทำให้แน่ใจได้ว่าฟังก์ชันการทำงานที่มีอยู่จะไม่เสีย

  • นักพัฒนาสามารถตัดสินใจในการออกแบบและปรับโครงสร้างได้ตลอดเวลาและการดำเนินการทดสอบจะช่วยให้มั่นใจได้ว่าระบบยังคงทำงานอยู่ ทำให้ซอฟต์แวร์บำรุงรักษาได้

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

  • ในการทดสอบแต่ละครั้งต่อเนื่องการแก้ไขข้อบกพร่องก่อนหน้านี้ทั้งหมดจะได้รับการตรวจสอบเช่นกันและการทำซ้ำของข้อบกพร่องเดียวกันจะลดลง

  • เนื่องจากการทดสอบส่วนใหญ่เกิดขึ้นระหว่างการพัฒนาตัวเองการทดสอบก่อนส่งมอบจึงสั้นลง

ข้อเสียของ TDD

จุดเริ่มต้นคือ User Stories เป็นการอธิบายพฤติกรรมของระบบ ดังนั้นนักพัฒนามักจะเผชิญกับคำถามต่อไปนี้ -

  • ทดสอบเมื่อไหร่?

  • จะทดสอบอะไร

  • จะรู้ได้อย่างไรว่าตรงตามข้อกำหนด?

  • รหัสส่งมอบคุณค่าทางธุรกิจหรือไม่?

ความเข้าใจผิดเกี่ยวกับ TDD

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

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

TDD เป็นวิธีการในการพัฒนาและหลังจากการทดสอบหน่วยใหม่ทุกครั้งผ่านไประบบจะเพิ่มเข้าไปใน Automation Test Suite เนื่องจากการทดสอบทั้งหมดจะต้องดำเนินการเมื่อใดก็ตามที่มีการเพิ่มโค้ดใหม่หรือมีการแก้ไขโค้ดที่มีอยู่และหลังจากการปรับโครงสร้างใหม่ทุกครั้ง

ดังนั้นเครื่องมือทดสอบอัตโนมัติที่รองรับ TDD จึงช่วยอำนวยความสะดวกในกระบวนการนี้

TDD หมายถึงการส่งการทดสอบการยอมรับให้กับนักพัฒนา TDD ไม่ได้หมายถึงการมอบการทดสอบการยอมรับให้กับนักพัฒนา

การยอมรับ TDD

Acceptance Test Driven Development (ATDD) กำหนดเกณฑ์การยอมรับและการทดสอบการยอมรับในระหว่างการสร้างเรื่องราวของผู้ใช้ในช่วงแรกของการพัฒนา ATDD มุ่งเน้นไปที่การสื่อสารและความเข้าใจร่วมกันระหว่างลูกค้านักพัฒนาและผู้ทดสอบ

แนวทางปฏิบัติที่สำคัญใน ATDD มีดังนี้ -

  • หารือเกี่ยวกับสถานการณ์ในโลกแห่งความจริงเพื่อสร้างความเข้าใจร่วมกันเกี่ยวกับโดเมน

  • ใช้สถานการณ์เหล่านั้นเพื่อให้ได้เกณฑ์การยอมรับ

  • ทำการทดสอบการยอมรับโดยอัตโนมัติ

  • เน้นการพัฒนาในการทดสอบเหล่านั้น

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

ประโยชน์ของการใช้ ATDD มีดังนี้ -

  • ข้อกำหนดไม่คลุมเครือและไม่มีช่องว่างในการทำงาน

  • คนอื่นเข้าใจกรณีพิเศษที่นักพัฒนาคาดการณ์ไว้

  • การทดสอบการยอมรับเป็นแนวทางในการพัฒนา

TDD กับ BDD

ตามที่ Dan North ระบุว่าโดยปกติโปรแกรมเมอร์จะประสบปัญหาต่อไปนี้ขณะดำเนินการทดสอบขับเคลื่อนการพัฒนา -

  • จะเริ่มต้นที่ไหน

  • สิ่งที่ต้องทดสอบและสิ่งที่ไม่ควรทดสอบ

  • ต้องทดสอบเท่าไหร่ในครั้งเดียว

  • สิ่งที่เรียกว่าการทดสอบของพวกเขา

  • จะเข้าใจได้อย่างไรว่าทำไมการทดสอบจึงล้มเหลว

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

หลัก difference between TDD and BDD คือ -

  • TDD อธิบายวิธีการทำงานของซอฟต์แวร์

  • ในทางกลับกัน BDD -

    • อธิบายว่าผู้ใช้ปลายทางใช้ซอฟต์แวร์อย่างไร

    • ส่งเสริมการทำงานร่วมกันและการสื่อสาร

    • เน้นตัวอย่างพฤติกรรมของระบบ

    • มุ่งเป้าไปที่ข้อกำหนดการปฏิบัติการที่ได้มาจากตัวอย่าง