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 -

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

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

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

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