การพัฒนาพฤติกรรมที่ขับเคลื่อน - คู่มือฉบับย่อ
Behavior Driven Development (BDD) เป็นกระบวนการพัฒนาซอฟต์แวร์ที่มาจาก Test Driven Development (TDD)
Dan North ผู้รับผิดชอบการวิวัฒนาการของ BDD กล่าวว่า“ BDD กำลังใช้ตัวอย่างในหลายระดับเพื่อสร้างความเข้าใจร่วมกันและสร้างความไม่แน่นอนในการนำเสนอซอฟต์แวร์ที่มีความสำคัญ”
BDD ใช้ตัวอย่างเพื่อแสดงพฤติกรรมของระบบที่เขียนด้วยภาษาที่อ่านได้และเข้าใจได้สำหรับทุกคนที่เกี่ยวข้องกับการพัฒนา ตัวอย่างเหล่านี้ ได้แก่ -
แปลงเป็นข้อกำหนดปฏิบัติการ
ใช้เป็นการทดสอบการยอมรับ
BDD - คุณสมบัติที่สำคัญ
การพัฒนาพฤติกรรมมุ่งเน้นไปที่ -
จัดหากระบวนการและเครื่องมือที่ใช้ร่วมกันเพื่อส่งเสริมการสื่อสารแก่นักพัฒนาซอฟต์แวร์นักวิเคราะห์ธุรกิจและผู้มีส่วนได้ส่วนเสียเพื่อร่วมมือกันในการพัฒนาซอฟต์แวร์โดยมีจุดมุ่งหมายเพื่อส่งมอบผลิตภัณฑ์ที่มีคุณค่าทางธุรกิจ
ระบบควรทำอย่างไรและไม่ควรนำไปใช้อย่างไร
ให้การอ่านและการมองเห็นที่ดีขึ้น
การตรวจสอบไม่เพียง แต่การทำงานของซอฟต์แวร์ แต่ยังตรวจสอบว่าเป็นไปตามความคาดหวังของลูกค้า
ที่มาของ BDD
ค่าใช้จ่ายในการแก้ไขข้อบกพร่องจะเพิ่มขึ้นหลายเท่าหากตรวจไม่พบข้อบกพร่องในเวลาที่เหมาะสมและแก้ไขเมื่อตรวจพบ ลองพิจารณาตัวอย่างต่อไปนี้
สิ่งนี้แสดงให้เห็นว่าหากไม่ได้รับข้อกำหนดอย่างถูกต้องการแก้ไขข้อบกพร่องที่เกิดจากการเข้าใจข้อกำหนดผิดในขั้นตอนต่อไปจะมีราคาแพง นอกจากนี้ผลิตภัณฑ์สุดท้ายอาจไม่ตรงตามความคาดหวังของลูกค้า
ความต้องการของชั่วโมงเป็นแนวทางการพัฒนาที่ -
เป็นไปตามข้อกำหนด
มุ่งเน้นไปที่ข้อกำหนดตลอดการพัฒนา
ตรวจสอบให้แน่ใจว่าเป็นไปตามข้อกำหนด
แนวทางการพัฒนาที่สามารถดูแลข้อกำหนดข้างต้นได้คือ BDD ดังนั้นพฤติกรรมที่ขับเคลื่อนการพัฒนา -
มาจากตัวอย่างของพฤติกรรมที่คาดหวังที่แตกต่างกันของระบบ
เปิดใช้งานการเขียนตัวอย่างเป็นภาษาโดยใช้เงื่อนไขโดเมนธุรกิจเพื่อให้ทุกคนที่เกี่ยวข้องกับการพัฒนาเข้าใจง่ายรวมถึงลูกค้า
รับตัวอย่างที่ให้สัตยาบันกับลูกค้าเป็นครั้งคราวโดยวิธีการสนทนา
มุ่งเน้นไปที่ความต้องการของลูกค้า (ตัวอย่าง) ตลอดการพัฒนา
ใช้ตัวอย่างเป็นการทดสอบการยอมรับ
แนวทางปฏิบัติของ BDD
แนวทางปฏิบัติหลักสองประการของ BDD คือ -
ข้อกำหนดตามตัวอย่าง (SbE)
ทดสอบขับเคลื่อนการพัฒนา (TDD)
คุณสมบัติตามตัวอย่าง
Specification by Example (SbE) ใช้ตัวอย่างในการสนทนาเพื่อแสดงกฎทางธุรกิจและลักษณะการทำงานของซอฟต์แวร์ที่จะสร้างขึ้น
ข้อมูลจำเพาะตามตัวอย่างช่วยให้เจ้าของผลิตภัณฑ์นักวิเคราะห์ธุรกิจผู้ทดสอบและนักพัฒนาสามารถขจัดความเข้าใจผิดทั่วไปเกี่ยวกับข้อกำหนดทางธุรกิจได้
ทดสอบขับเคลื่อนการพัฒนา
Test Driven Development ในบริบทของ BDD จะเปลี่ยนตัวอย่างให้เป็นข้อมูลจำเพาะที่มนุษย์อ่านได้และปฏิบัติการได้
นักพัฒนาใช้ข้อกำหนดเหล่านี้เป็นแนวทางในการใช้ฟังก์ชันใหม่ที่เพิ่มขึ้น สิ่งนี้ส่งผลให้เกิดโค้ดเบสแบบลีนและชุดการทดสอบการถดถอยอัตโนมัติที่ช่วยให้ค่าบำรุงรักษาต่ำตลอดอายุการใช้งานของซอฟต์แวร์
BDD ที่คล่องตัว
ในการพัฒนาซอฟต์แวร์ Agile จะใช้วิธี BDD เพื่อทำความเข้าใจร่วมกันเกี่ยวกับข้อกำหนดที่รอดำเนินการ
ขั้นตอนต่อไปนี้ดำเนินการใน Agile BDD -
นักพัฒนาและเจ้าของผลิตภัณฑ์ร่วมกันเขียนข้อกำหนดที่รอดำเนินการในโปรแกรมแก้ไขข้อความธรรมดา
เจ้าของผลิตภัณฑ์ระบุพฤติกรรมที่พวกเขาคาดหวังจากระบบ
นักพัฒนา
กรอกข้อมูลจำเพาะด้วยรายละเอียดพฤติกรรมเหล่านี้
ถามคำถามตามความเข้าใจในระบบ
พฤติกรรมของระบบในปัจจุบันจะพิจารณาเพื่อดูว่าคุณลักษณะใหม่จะทำลายคุณลักษณะที่มีอยู่หรือไม่
Agile Manifesto และ BDD
Agile Manifest เพื่อระบุสิ่งต่อไปนี้ -
เรากำลังเปิดเผยวิธีที่ดีกว่าในการพัฒนาซอฟต์แวร์โดยการทำและช่วยเหลือผู้อื่น ผ่านงานนี้เราได้มาถึงคุณค่า -
Individuals and interactions - ผ่านกระบวนการและเครื่องมือ
Working software - มากกว่าเอกสารที่ครอบคลุม
Customer collaboration - มากกว่าการเจรจาสัญญา
Responding to change - มากกว่าการทำตามแผน
นั่นคือในขณะที่มีค่าในรายการทางด้านขวาเราให้ความสำคัญกับรายการทางด้านซ้ายมากขึ้น
BDD จัดตัวเองให้เข้ากับ Agile manifesto ดังนี้ -
ประกาศ Agile | การจัดตำแหน่ง BDD |
---|---|
บุคคลและปฏิสัมพันธ์กับกระบวนการและเครื่องมือ | BDD เกี่ยวกับการสนทนา |
ซอฟต์แวร์ที่ใช้งานได้กับเอกสารที่ครอบคลุม | BDD มุ่งเน้นที่การทำให้ง่ายต่อการสร้างซอฟต์แวร์ที่มีคุณค่าทางธุรกิจ |
การทำงานร่วมกันของลูกค้าผ่านการเจรจาสัญญา | BDD มุ่งเน้นไปที่สถานการณ์ตามแนวคิดด้วยการสื่อสารอย่างต่อเนื่องกับลูกค้าเมื่อการพัฒนาดำเนินไป มันไม่ได้ขึ้นอยู่กับคำสัญญาใด ๆ |
การตอบสนองต่อการเปลี่ยนแปลงตามแผน | 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 ระบุว่าโดยปกติโปรแกรมเมอร์จะประสบปัญหาต่อไปนี้ขณะทำการทดสอบ Test Driven Development -
จะเริ่มต้นที่ไหน
สิ่งที่ต้องทดสอบและสิ่งที่ไม่ควรทดสอบ
ต้องทดสอบเท่าไหร่ในครั้งเดียว
สิ่งที่เรียกว่าการทดสอบของพวกเขา
จะเข้าใจได้อย่างไรว่าทำไมการทดสอบจึงล้มเหลว
วิธีแก้ปัญหาทั้งหมดนี้คือการพัฒนาพฤติกรรมที่ขับเคลื่อน มีการพัฒนาจากแนวทางปฏิบัติที่มีความคล่องตัวและได้รับการออกแบบมาเพื่อให้สามารถเข้าถึงได้และมีประสิทธิภาพมากขึ้นสำหรับทีมซึ่งเป็นซอฟต์แวร์ใหม่สำหรับการส่งมอบซอฟต์แวร์ที่คล่องตัว เมื่อเวลาผ่านไป BDD ได้เติบโตขึ้นเพื่อครอบคลุมภาพรวมที่กว้างขึ้นของการวิเคราะห์แบบ Agile และการทดสอบการยอมรับอัตโนมัติ
หลัก difference between TDD and BDD คือ -
TDD อธิบายวิธีการทำงานของซอฟต์แวร์
ในทางกลับกัน BDD -
อธิบายว่าผู้ใช้ปลายทางใช้ซอฟต์แวร์อย่างไร
ส่งเสริมการทำงานร่วมกันและการสื่อสาร
เน้นตัวอย่างพฤติกรรมของระบบ
มุ่งเป้าไปที่ข้อกำหนดการปฏิบัติการที่ได้มาจากตัวอย่าง
ใน TDD คำว่า“ การทดสอบการยอมรับ” ทำให้เข้าใจผิด การทดสอบการยอมรับเป็นตัวแทนของพฤติกรรมที่คาดหวังของระบบ ในการปฏิบัติแบบ Agile จะเน้นการทำงานร่วมกันของทั้งทีมและการมีปฏิสัมพันธ์กับลูกค้าและผู้มีส่วนได้ส่วนเสียอื่น ๆ สิ่งนี้ทำให้เกิดความจำเป็นในการใช้คำศัพท์ที่ทุกคนที่เกี่ยวข้องในโครงการเข้าใจได้ง่าย
TDD ทำให้คุณคิดถึงสิ่งที่จำเป็น Behavior และด้วยเหตุนี้คำว่า 'พฤติกรรม' จึงมีประโยชน์มากกว่าคำนี้ ‘Test’. BDD คือ Test Driven Development พร้อมคำศัพท์ที่เน้นพฤติกรรมไม่ใช่การทดสอบ
ในคำพูดของ Dan North“ ฉันพบว่าการเปลี่ยนจากการคิดในการทดสอบไปสู่การคิดในพฤติกรรมนั้นลึกซึ้งมากจนฉันเริ่มอ้างถึง TDD ว่า BDD หรือ Behavior Driven Development” TDD มุ่งเน้นไปที่การทำงานของบางสิ่ง BDD มุ่งเน้นไปที่สาเหตุที่เราสร้างมันขึ้นมา
BDD ตอบคำถามต่อไปนี้ที่นักพัฒนามักจะเผชิญ -
คำถาม | ตอบ |
---|---|
จะเริ่มต้นที่ไหน? | นอก - ใน |
จะทดสอบอะไร | เรื่องราวของผู้ใช้ |
สิ่งที่ไม่ต้องทดสอบ? | อย่างอื่น |
คำตอบเหล่านี้ทำให้เกิดกรอบเรื่องราวดังนี้ -
Story Framework
ในฐานะที่เป็น [Role]
ฉันต้องการ [Feature]
ดังนั้น [Benefit]
ซึ่งหมายความว่า 'เมื่อก Feature ถูกดำเนินการผลลัพธ์ที่ได้ Benefit คือผู้ที่เล่นไฟล์ Role.'
BDD ตอบคำถามต่อไปนี้เพิ่มเติม -
คำถาม | ตอบ |
---|---|
ต้องทดสอบเท่าไหร่ในครั้งเดียว? | เน้นน้อยมาก |
สิ่งที่เรียกว่าการทดสอบของพวกเขา? | เทมเพลตประโยค |
จะเข้าใจได้อย่างไรว่าทำไมการทดสอบจึงล้มเหลว | เอกสารประกอบ |
คำตอบเหล่านี้ทำให้เกิดกรอบตัวอย่างดังนี้ -
Example Framework
Given บริบทเริ่มต้นบางส่วน
When เหตุการณ์เกิดขึ้น
Then ตรวจสอบผลลัพธ์บางอย่าง
ซึ่งหมายความว่า 'เริ่มจากบริบทเริ่มต้นเมื่อมีเหตุการณ์ใดเหตุการณ์หนึ่งเกิดขึ้นเรารู้ว่าผลลัพธ์เป็นอย่างไร should be. '
ดังนั้นตัวอย่างจึงแสดงพฤติกรรมที่คาดหวังของระบบ ตัวอย่างนี้ใช้เพื่อแสดงสถานการณ์ต่างๆของระบบ
เรื่องราวและสถานการณ์
ขอให้เราพิจารณาภาพประกอบต่อไปนี้โดย Dan North เกี่ยวกับระบบ ATM
เรื่องราว
As a ลูกค้า,
I want ถอนเงินสดจากตู้เอทีเอ็ม
so that ฉันไม่ต้องรอเข้าแถวที่ธนาคาร
สถานการณ์
มีสองสถานการณ์ที่เป็นไปได้สำหรับเรื่องราวนี้
Scenario 1 - บัญชีเป็นเครดิต
Given บัญชีเป็นเครดิต
And บัตรถูกต้อง
And ตู้มีเงินสด
When ลูกค้าขอเงินสด
Then ตรวจสอบให้แน่ใจว่าบัญชีถูกหัก
And ตรวจสอบให้แน่ใจว่ามีการจ่ายเงินสด
And ตรวจสอบให้แน่ใจว่าบัตรถูกส่งคืน
Scenario 2 - บัญชีถูกถอนเกินขีด จำกัด เงินเบิกเกินบัญชี
Given บัญชีถูกถอนออกไป
And บัตรถูกต้อง
When ลูกค้าขอเงินสด
Then ตรวจสอบว่าข้อความปฏิเสธปรากฏขึ้น
And ตรวจสอบให้แน่ใจว่าไม่มีการจ่ายเงินสด
And ตรวจสอบให้แน่ใจว่าบัตรถูกส่งคืน
เหตุการณ์เหมือนกันในทั้งสองสถานการณ์ แต่บริบทแตกต่างกัน ดังนั้นผลลัพธ์จึงแตกต่างกัน
วงจรการพัฒนา
วัฏจักรการพัฒนาสำหรับ BDD คือไฟล์ outside-in แนวทาง
Step 1- เขียนตัวอย่างมูลค่าทางธุรกิจระดับสูง (ภายนอก) (โดยใช้ Cucumber หรือ RSpec / Capybara) ที่เป็นสีแดง (RSpec สร้างเฟรมเวิร์ก BDD ในภาษา Ruby)
Step 2 - เขียนตัวอย่าง RSpec ระดับล่าง (ด้านใน) สำหรับขั้นตอนแรกของการใช้งานที่เป็นสีแดง
Step 3 - ใช้โค้ดขั้นต่ำเพื่อส่งผ่านตัวอย่างระดับล่างนั้นดูเป็นสีเขียว
Step 4 - เขียนตัวอย่าง RSpec ระดับล่างถัดไปที่ผลักดันให้ผ่านขั้นตอนที่ 1 ซึ่งจะเป็นสีแดง
Step 5 - ทำซ้ำขั้นตอนที่ 3 และขั้นตอนที่ 4 จนกระทั่งตัวอย่างระดับสูงในขั้นตอนที่ 1 เป็นสีเขียว
Note - ควรคำนึงถึงประเด็นต่อไปนี้ -
Red/green state คือสถานะการอนุญาต
เมื่อการทดสอบระดับต่ำของคุณเป็นสีเขียวคุณจะมีสิทธิ์เขียนตัวอย่างใหม่หรือปรับเปลี่ยนการใช้งานที่มีอยู่ คุณต้องไม่เพิ่มฟังก์ชัน / ความยืดหยุ่นใหม่ในบริบทของการปรับโครงสร้างใหม่
เมื่อการทดสอบระดับต่ำของคุณเป็นสีแดงคุณจะมีสิทธิ์เขียนหรือเปลี่ยนโค้ดการใช้งานได้เฉพาะเมื่อทำให้การทดสอบที่มีอยู่กลายเป็นสีเขียว คุณต้องต่อต้านการกระตุ้นให้เขียนโค้ดเพื่อผ่านการทดสอบครั้งต่อไปซึ่งไม่มีอยู่หรือใช้คุณสมบัติที่คุณคิดว่าดี (ลูกค้าคงไม่ได้ถาม)
ตามที่ Gojko Adzic ผู้เขียน 'Specification by Example', Specification by Example คือชุดของรูปแบบกระบวนการที่อำนวยความสะดวกในการเปลี่ยนแปลงผลิตภัณฑ์ซอฟต์แวร์เพื่อให้แน่ใจว่าผลิตภัณฑ์ที่เหมาะสมจะถูกส่งมอบอย่างมีประสิทธิภาพ "
Specification by Example เป็นแนวทางการทำงานร่วมกันในการกำหนดข้อกำหนดและการทดสอบการทำงานเชิงธุรกิจสำหรับผลิตภัณฑ์ซอฟต์แวร์โดยยึดตามข้อกำหนดและการแสดงภาพประกอบโดยใช้ตัวอย่างที่เป็นจริงแทนข้อความนามธรรม
ข้อมูลจำเพาะตามตัวอย่าง - ภาพรวม
วัตถุประสงค์ของ Specification by Example คือการมุ่งเน้นไปที่การพัฒนาและการส่งมอบข้อกำหนดทางธุรกิจที่จัดลำดับความสำคัญและตรวจสอบได้ แม้ว่าแนวคิดของ Specification by Example จะค่อนข้างใหม่ แต่ก็เป็นเพียงการนำแนวทางปฏิบัติที่มีอยู่มาใช้ใหม่
สนับสนุนคำศัพท์ที่เฉพาะเจาะจงและกระชับซึ่งเรียกว่าภาษาที่แพร่หลายซึ่ง -
เปิดใช้งานข้อกำหนดปฏิบัติการ
ถูกใช้โดยทุกคนในทีม
ถูกสร้างขึ้นโดยทีมงานข้ามสายงาน
จับความเข้าใจของทุกคน
ข้อมูลจำเพาะตามตัวอย่างสามารถใช้เป็นข้อมูลโดยตรงในการสร้างการทดสอบอัตโนมัติที่สะท้อนถึงโดเมนธุรกิจ ดังนั้นจุดเน้นของข้อมูลจำเพาะตามตัวอย่างจึงอยู่ที่การสร้างผลิตภัณฑ์ที่เหมาะสมและการสร้างผลิตภัณฑ์ที่เหมาะสม
วัตถุประสงค์ของข้อกำหนดตามตัวอย่าง
จุดมุ่งหมายหลักของ Specification by Example คือการสร้างผลิตภัณฑ์ที่เหมาะสม มุ่งเน้นไปที่ความเข้าใจร่วมกันดังนั้นการสร้างแหล่งเดียวของความจริง เปิดใช้งานเกณฑ์การยอมรับโดยอัตโนมัติเพื่อให้มุ่งเน้นไปที่การป้องกันข้อบกพร่องมากกว่าการตรวจจับข้อบกพร่อง นอกจากนี้ยังส่งเสริมการทดสอบในช่วงต้นเพื่อค้นหาข้อบกพร่อง แต่เนิ่นๆ
การใช้ SbE
ข้อมูลจำเพาะตามตัวอย่างใช้เพื่อแสดงลักษณะการทำงานของระบบที่คาดหวังซึ่งอธิบายมูลค่าทางธุรกิจ ภาพประกอบเป็นตัวอย่างที่เป็นรูปธรรมและในชีวิตจริง ตัวอย่างเหล่านี้ใช้เพื่อสร้างข้อกำหนดที่สามารถปฏิบัติการได้นั่นคือ -
ทดสอบได้โดยไม่ต้องแปล
บันทึกในเอกสารถ่ายทอดสด
ต่อไปนี้เป็นเหตุผลที่เราใช้ตัวอย่างเพื่ออธิบายข้อกำหนดเฉพาะ -
พวกเขาเข้าใจง่ายกว่า
พวกเขาตีความผิดได้ยากกว่า
ข้อดีของ SbE
ข้อดีของการใช้ Specification by Example คือ -
คุณภาพที่เพิ่มขึ้น
ลดของเสีย
ลดความเสี่ยงของข้อบกพร่องในการผลิต
มุ่งเน้นความพยายาม
การเปลี่ยนแปลงสามารถทำได้อย่างปลอดภัยมากขึ้น
ปรับปรุงการมีส่วนร่วมทางธุรกิจ
การใช้งาน SbE
ข้อมูลจำเพาะตามตัวอย่างค้นหาแอปพลิเคชันใน -
ทั้งธุรกิจที่ซับซ้อนหรือองค์กรที่ซับซ้อน
ใช้งานได้ไม่ดีสำหรับปัญหาทางเทคนิคล้วนๆ
ทำงานได้ไม่ดีสำหรับผลิตภัณฑ์ซอฟต์แวร์ที่เน้น UI
สามารถนำไปใช้กับระบบเดิมได้เช่นกัน
SbE และการทดสอบการยอมรับ
ข้อดีของ Specification by Example ในแง่ของการทดสอบการยอมรับคือ -
ใช้ภาพประกอบเดียวสำหรับทั้งข้อกำหนดโดยละเอียดและการทดสอบ
ความคืบหน้าของโครงการอยู่ในแง่ของการทดสอบการยอมรับ -
การทดสอบแต่ละครั้งคือการทดสอบพฤติกรรม
การทดสอบอาจผ่านสำหรับพฤติกรรมหรือไม่ได้
การทดสอบที่ผ่านแสดงว่าพฤติกรรมเฉพาะเสร็จสมบูรณ์
หากโครงการที่ต้องดำเนินการ 100 พฤติกรรมมี 60 พฤติกรรมที่เสร็จสิ้นแสดงว่าเสร็จสิ้น 60%
ผู้ทดสอบเปลี่ยนจากการแก้ไขข้อบกพร่องเป็นการป้องกันข้อบกพร่องและมีส่วนช่วยในการออกแบบโซลูชัน
ระบบอัตโนมัติช่วยให้เข้าใจผลกระทบของการเปลี่ยนแปลงความต้องการในโซลูชันได้ทันที
ข้อกำหนดตามตัวอย่าง - ความหมายสำหรับบทบาทต่างๆ
วัตถุประสงค์ของ Specification by Example คือการส่งเสริมการทำงานร่วมกันของทุกคนในทีมรวมถึงลูกค้าตลอดทั้งโครงการเพื่อส่งมอบคุณค่าทางธุรกิจ ทุกคนเพื่อความเข้าใจที่ดีขึ้นใช้คำศัพท์เดียวกัน
บทบาท | การใช้ SbE |
---|---|
นักวิเคราะห์ธุรกิจ |
|
นักพัฒนา |
|
ผู้ทดสอบ |
|
ทุกคน |
|
SbE - ชุดรูปแบบกระบวนการ
ดังที่เราได้เห็นในตอนต้นของบทนี้ Specification by Example ถูกกำหนดให้เป็นชุดของรูปแบบกระบวนการที่อำนวยความสะดวกในการเปลี่ยนแปลงผลิตภัณฑ์ซอฟต์แวร์เพื่อให้แน่ใจว่าผลิตภัณฑ์ที่เหมาะสมจะถูกส่งมอบอย่างมีประสิทธิภาพ
รูปแบบกระบวนการคือ -
ข้อกำหนดการทำงานร่วมกัน
การแสดงข้อมูลจำเพาะโดยใช้ตัวอย่าง
การปรับแต่งข้อกำหนด
ตัวอย่างอัตโนมัติ
ตรวจสอบความถูกต้องบ่อยครั้ง
เอกสารประกอบการดำรงชีวิต
ข้อกำหนดการทำงานร่วมกัน
วัตถุประสงค์ของข้อกำหนดการทำงานร่วมกันคือ -
รับบทบาทต่างๆในทีมเพื่อให้มีความเข้าใจร่วมกันและใช้คำศัพท์ร่วมกัน
ให้ทุกคนมีส่วนร่วมในโครงการเพื่อให้พวกเขามีส่วนร่วมในมุมมองที่แตกต่างกันเกี่ยวกับคุณลักษณะ
ตรวจสอบให้แน่ใจว่ามีการสื่อสารร่วมกันและความเป็นเจ้าของคุณสมบัติ
วัตถุประสงค์เหล่านี้พบได้ในการประชุมเชิงปฏิบัติการด้านข้อกำหนดหรือที่เรียกว่าการประชุม Three Amigos สาม Amigos ได้แก่ BA, QA และผู้พัฒนา แม้ว่าจะมีบทบาทอื่น ๆ ในโครงการ แต่ทั้งสามคนจะต้องรับผิดชอบและรับผิดชอบตั้งแต่คำจำกัดความไปจนถึงการส่งมอบคุณสมบัติ
During the meeting −
นักวิเคราะห์ธุรกิจ (BA) นำเสนอข้อกำหนดและการทดสอบสำหรับคุณลักษณะใหม่
Amigos ทั้งสาม (BA, Developer และ QA) พูดคุยเกี่ยวกับคุณลักษณะใหม่และตรวจสอบข้อกำหนด
QA และผู้พัฒนายังระบุข้อกำหนดที่ขาดหายไป
อามิโกสทั้งสาม
ใช้โมเดลที่ใช้ร่วมกันโดยใช้ภาษาที่แพร่หลาย
ใช้คำศัพท์โดเมน (อภิธานศัพท์จะได้รับการดูแลหากจำเป็น)
มองหาความแตกต่างและความขัดแย้ง
อย่าข้ามไปที่รายละเอียดการใช้งานในจุดนี้
บรรลุฉันทามติว่ามีการระบุคุณลักษณะเพียงพอหรือไม่
ความรู้สึกร่วมกันของข้อกำหนดและการทดสอบความเป็นเจ้าของช่วยอำนวยความสะดวกในข้อกำหนดด้านคุณภาพ
ข้อกำหนดจะถูกนำเสนอเป็นสถานการณ์ซึ่งให้ข้อกำหนดที่ชัดเจนและไม่คลุมเครือ สถานการณ์เป็นตัวอย่างพฤติกรรมของระบบจากมุมมองของผู้ใช้
การแสดงข้อมูลจำเพาะโดยใช้ตัวอย่าง
สถานการณ์ถูกระบุโดยใช้โครงสร้าง Given-When-Then เพื่อสร้างข้อกำหนดที่ทดสอบได้ -
Given <เงื่อนไขเบื้องต้นบางประการ>
And <เงื่อนไขเบื้องต้นเพิ่มเติม> Optional
When <การกระทำ / ทริกเกอร์เกิดขึ้น>
Then <เงื่อนไขการโพสต์บางส่วน>
And <เงื่อนไขการโพสต์เพิ่มเติม> Optional
ข้อกำหนดนี้เป็นตัวอย่างของลักษณะการทำงานของระบบ นอกจากนี้ยังแสดงถึงเกณฑ์การยอมรับของระบบ
ทีมจะกล่าวถึงตัวอย่างและข้อเสนอแนะจะรวมเข้าด้วยกันจนกว่าจะมีข้อตกลงว่าตัวอย่างครอบคลุมพฤติกรรมที่คาดหวังของคุณลักษณะ สิ่งนี้ทำให้มั่นใจได้ถึงการครอบคลุมการทดสอบที่ดี
การปรับแต่งข้อกำหนด
ในการปรับแต่งข้อกำหนด
มีความแม่นยำในการเขียนตัวอย่าง หากตัวอย่างมีความซับซ้อนให้แบ่งออกเป็นตัวอย่างที่ง่ายกว่า
มุ่งเน้นไปที่มุมมองทางธุรกิจและหลีกเลี่ยงรายละเอียดทางเทคนิค
พิจารณาเงื่อนไขทั้งบวกและลบ
ปฏิบัติตามคำศัพท์เฉพาะโดเมน
พูดคุยเกี่ยวกับตัวอย่างกับลูกค้า
เลือกการสนทนาเพื่อบรรลุเป้าหมายนี้
พิจารณาเฉพาะตัวอย่างที่ลูกค้าสนใจซึ่งจะทำให้สามารถผลิตโค้ดที่ต้องการได้เท่านั้นและหลีกเลี่ยงการครอบคลุมทุกชุดค่าผสมที่เป็นไปได้ซึ่งอาจไม่จำเป็น
เพื่อให้แน่ใจว่าสถานการณ์ผ่านพ้นไปกรณีทดสอบทั้งหมดสำหรับสถานการณ์นั้นจะต้องผ่าน ดังนั้นปรับปรุงข้อกำหนดเพื่อให้สามารถทดสอบได้ กรณีทดสอบอาจรวมถึงช่วงและค่าข้อมูลต่างๆ (กรณีขอบเขตและมุม) ตลอดจนกฎทางธุรกิจที่แตกต่างกันซึ่งส่งผลให้ข้อมูลมีการเปลี่ยนแปลง
ระบุกฎเกณฑ์ทางธุรกิจเพิ่มเติมเช่นการคำนวณที่ซับซ้อนการจัดการ / การแปลงข้อมูลเป็นต้น
รวมสถานการณ์ที่ไม่สามารถใช้งานได้ (เช่นประสิทธิภาพการโหลดความสามารถในการใช้งาน ฯลฯ ) ตามข้อกำหนดตามตัวอย่าง
ตัวอย่างอัตโนมัติ
ชั้นระบบอัตโนมัติจะต้องถูกทำให้เรียบง่าย - เพียงแค่เดินสายข้อมูลจำเพาะเข้ากับระบบที่กำลังทดสอบ คุณสามารถใช้เครื่องมือสำหรับสิ่งเดียวกัน
ดำเนินการทดสอบอัตโนมัติโดยใช้ภาษาเฉพาะโดเมน (DSL) และแสดงการเชื่อมต่อที่ชัดเจนระหว่างอินพุตและเอาต์พุต มุ่งเน้นไปที่ข้อกำหนดไม่ใช่สคริปต์ ตรวจสอบให้แน่ใจว่าการทดสอบนั้นแม่นยำเข้าใจง่ายและทดสอบได้
ตรวจสอบความถูกต้องบ่อยครั้ง
รวมการตรวจสอบตัวอย่างในขั้นตอนการพัฒนาของคุณด้วยทุกการเปลี่ยนแปลง (เพิ่มเติม / แก้ไข) มีเทคนิคและเครื่องมือมากมายที่สามารถ (และควร) นำมาใช้เพื่อช่วยให้มั่นใจในคุณภาพของผลิตภัณฑ์ พวกเขาหมุนรอบหลักการสำคัญสามประการ -Test Early, Test Well และ Test Often.
ดำเนินการทดสอบบ่อยๆเพื่อให้คุณสามารถระบุลิงก์ที่อ่อนแอได้ ตัวอย่างที่แสดงถึงพฤติกรรมช่วยติดตามความคืบหน้าและกล่าวว่าพฤติกรรมจะเสร็จสมบูรณ์หลังจากผ่านการทดสอบที่เกี่ยวข้องเท่านั้น
เอกสารประกอบการดำรงชีวิต
รักษาข้อกำหนดให้เรียบง่ายและสั้นที่สุด จัดระเบียบข้อกำหนดและพัฒนาตามความคืบหน้าของงาน ทำให้เอกสารสามารถเข้าถึงได้สำหรับทุกคนในทีม
ข้อกำหนดตามขั้นตอนกระบวนการตัวอย่าง
ภาพประกอบแสดงขั้นตอนกระบวนการใน Specification by Example
ต่อต้านรูปแบบ
รูปแบบการต่อต้านเป็นรูปแบบบางอย่างในการพัฒนาซอฟต์แวร์ซึ่งถือเป็นการเขียนโปรแกรมที่ไม่ดี ในทางตรงกันข้ามกับรูปแบบการออกแบบซึ่งเป็นแนวทางทั่วไปในการแก้ไขปัญหาทั่วไปซึ่งได้รับการทำให้เป็นทางการและโดยทั่วไปถือว่าเป็นแนวทางปฏิบัติในการพัฒนาที่ดีรูปแบบการต่อต้านจะตรงกันข้ามและไม่เป็นที่พึงปรารถนา
รูปแบบการต่อต้านก่อให้เกิดปัญหาต่างๆ
ต่อต้านรูปแบบ | ปัญหา |
---|---|
ไม่มีการทำงานร่วมกัน |
|
ไม่ทราบเมื่อโค้ดเสร็จสิ้น |
|
ตัวอย่างที่เน้น UI ที่ละเอียดเกินไปหรือเกินไป |
|
ต้องใช้ความพยายามต่ำเกินไป |
|
แนวทางแก้ไขปัญหา - คุณภาพ
สามารถมั่นใจในคุณภาพได้ด้วยการเฝ้าดูรูปแบบการต่อต้าน เพื่อลดปัญหาที่เกิดจากรูปแบบการต่อต้านคุณควร -
ร่วมกันระบุโดยใช้ตัวอย่าง
ทำความสะอาดและปรับปรุงตัวอย่าง
เขียนโค้ดซึ่งตรงตามตัวอย่าง
ทำให้ตัวอย่างเป็นอัตโนมัติและปรับใช้
ทำซ้ำแนวทางสำหรับเรื่องราวของผู้ใช้ทุกคน
เพื่อแก้ปัญหาเนื่องจากรูปแบบการต่อต้านหมายถึงการยึดมั่น -
Collaboration.
มุ่งเน้นไปที่อะไร
มุ่งเน้นไปที่ธุรกิจ
เตรียมตัว.
ให้เราเข้าใจว่าแต่ละความหมายข้างต้นหมายถึงอะไร
การทำงานร่วมกัน
ในการทำงานร่วมกัน -
นักธุรกิจนักพัฒนาและผู้ทดสอบให้ข้อมูลจากมุมมองของตนเอง
ตัวอย่างอัตโนมัติพิสูจน์ว่าทีมได้สร้างสิ่งที่ถูกต้อง
กระบวนการนี้มีค่ามากกว่าการทดสอบด้วยตนเอง
มุ่งเน้นไปที่อะไร
คุณต้องมุ่งเน้นไปที่คำถาม - "อะไร" ในขณะที่มุ่งเน้นไปที่ 'อะไร' -
อย่าพยายามปกปิดทุกกรณีที่เป็นไปได้
อย่าลืมใช้การทดสอบประเภทต่างๆ
ยกตัวอย่างให้ง่ายที่สุด
ตัวอย่างควรเข้าใจได้ง่ายโดยผู้ใช้ระบบ
เครื่องมือไม่ควรมีส่วนสำคัญในการประชุมเชิงปฏิบัติการ
มุ่งเน้นไปที่ธุรกิจ
เพื่อมุ่งเน้นไปที่ธุรกิจ -
รักษาข้อกำหนดตามเจตนาทางธุรกิจ
รวมธุรกิจในการสร้างและตรวจสอบข้อกำหนด
ซ่อนรายละเอียดทั้งหมดในเลเยอร์การทำงานอัตโนมัติ
เตรียมตัว
เตรียมพร้อมสำหรับสิ่งต่อไปนี้ -
ผลประโยชน์จะไม่ปรากฏในทันทีแม้ว่าจะมีการเปลี่ยนแปลงแนวทางปฏิบัติของทีมก็ตาม
การแนะนำ SbE เป็นสิ่งที่ท้าทาย
ต้องใช้เวลาและเงินลงทุน
การทดสอบอัตโนมัติไม่ได้ฟรี
เครื่องมือ
การใช้เครื่องมือไม่บังคับสำหรับ Specification by Example แม้ว่าในทางปฏิบัติจะมีเครื่องมือหลายอย่าง มีหลายกรณีที่ทำตาม Specification by Example ได้สำเร็จแม้ว่าจะไม่ใช้เครื่องมือก็ตาม
เครื่องมือต่อไปนี้รองรับข้อมูลจำเพาะตามตัวอย่าง -
Cucumber
SpecFlow
Fitnesse
Jbehave
Concordion
Behat
Jasmine
Relish
Speclog
ทีมพัฒนามักมีความเข้าใจผิดว่า BDD เป็นกรอบเครื่องมือ ในความเป็นจริง BDD เป็นแนวทางการพัฒนามากกว่ากรอบเครื่องมือ อย่างไรก็ตามในกรณีของแนวทางการพัฒนาอื่น ๆ ก็มีเครื่องมือสำหรับ BDD เช่นกัน
มีการใช้เครื่องมือ BDD หลายตัวสำหรับแพลตฟอร์มและภาษาโปรแกรมต่างๆ พวกเขาคือ -
แตงกวา (ทับทิมกรอบ)
SpecFlow (.NET กรอบงาน)
Behave (กรอบ Python)
JBehave (กรอบ Java)
JBehave Web (เฟรมเวิร์ก Java พร้อมการรวมซีลีเนียม)
ผักกาดหอม (กรอบ Python)
Concordion (กรอบ Java)
Behat (กรอบ PHP)
Kahlan (กรอบ PHP)
DaSpec (กรอบ JavaScript)
จัสมิน (กรอบ JavaScript)
Cucumber-js (กรอบ JavaScript)
Squish GUI Tester (เครื่องมือทดสอบ BDD GUI สำหรับ JavaScript, Python, Perl, Ruby และ Tcl)
Spock (กรอบ Groovy)
Yadda (รองรับภาษา Gherkin สำหรับเฟรมเวิร์กเช่น Jasmine (JavaScript framework))
แตงกวา
แตงกวาเป็นเครื่องมือฟรีสำหรับข้อกำหนดปฏิบัติการที่ใช้กันทั่วโลก Cucumber ช่วยให้ทีมพัฒนาซอฟต์แวร์อธิบายว่าซอฟต์แวร์ควรทำงานอย่างไรเป็นข้อความธรรมดา ข้อความนี้เขียนด้วยภาษาสำหรับธุรกิจที่อ่านได้เฉพาะโดเมนและทำหน้าที่เป็นเอกสารประกอบการทดสอบอัตโนมัติและอุปกรณ์ช่วยในการพัฒนาทั้งหมดนี้รวมเป็นรูปแบบเดียว คุณสามารถใช้ภาษาพูดได้มากกว่าสี่สิบภาษา (อังกฤษจีน ฯลฯ ) กับแตงกวา
แตงกวา - คุณสมบัติหลัก
คุณสมบัติที่สำคัญของแตงกวามีดังนี้ -
แตงกวาสามารถใช้สำหรับข้อมูลจำเพาะปฏิบัติการทดสอบอัตโนมัติและเอกสารการดำรงชีวิต
แตงกวาทำงานร่วมกับ Ruby, Java, NET, Flex หรือเว็บแอปพลิเคชันที่เขียนด้วยภาษาใดก็ได้
แตงกวารองรับการทดสอบในตารางที่รวบรัดมากขึ้น - คล้ายกับที่ FIT ทำ
Cucumber ได้ปฏิวัติวงจรชีวิตของการพัฒนาซอฟต์แวร์ด้วยการหลอมรวมข้อกำหนดการทดสอบอัตโนมัติและการจัดทำเอกสารให้เป็นหนึ่งเดียว: ข้อกำหนดการปฏิบัติการข้อความธรรมดาที่ตรวจสอบความถูกต้องของซอฟต์แวร์
SpecFlow
SpecFlow เป็นเครื่องมือ BDD สำหรับ. NET Platform SpecFlow เป็นโครงการโอเพ่นซอร์ส ซอร์สโค้ดโฮสต์อยู่บน GitHub
SpecFlow ใช้ Gherkin Syntax สำหรับฟีเจอร์ Cucumber นำรูปแบบ Gherkin มาใช้และยังใช้โดยเครื่องมืออื่น ๆ ภาษา Gherkin ได้รับการดูแลเป็นโครงการบน GitHub -https://github.com/cucumber/gherkin
ประพฤติ
Behave ใช้สำหรับ Python framework
Behave ทำงานร่วมกับไฟล์สามประเภทที่เก็บไว้ในไดเร็กทอรีที่เรียกว่า "คุณสมบัติ" -
ไฟล์คุณลักษณะที่มีสถานการณ์พฤติกรรมของคุณอยู่ในนั้น
ไดเร็กทอรี“ steps” ที่มีการใช้งานขั้นตอน Python สำหรับสถานการณ์
อีกทางเลือกหนึ่งคือการควบคุมสภาพแวดล้อมบางอย่าง (รหัสเพื่อเรียกใช้ก่อนและหลังขั้นตอนสถานการณ์คุณสมบัติหรือการจับคู่การถ่ายทำทั้งหมด)
คุณลักษณะ Behave เขียนโดยใช้ Gherkin (มีการปรับเปลี่ยนบางอย่าง) และตั้งชื่อว่า "name.feature"
แท็กที่แนบมากับคุณลักษณะและสถานการณ์มีอยู่ในฟังก์ชันสภาพแวดล้อมผ่านทางออบเจ็กต์ "คุณลักษณะ" หรือ "สถานการณ์" ที่ส่งไปให้ บนวัตถุเหล่านั้นมีแอตทริบิวต์ที่เรียกว่า "แท็ก" ซึ่งเป็นรายการของชื่อแท็กที่แนบมาตามลำดับที่พบในไฟล์คุณลักษณะ
การปรับเปลี่ยนมาตรฐาน Gherkin -
Behave สามารถแยกวิเคราะห์ไฟล์ Gherkin มาตรฐานและขยาย Gherkin เพื่ออนุญาตให้ใช้คีย์เวิร์ดขั้นตอนที่เป็นตัวพิมพ์เล็กได้เนื่องจากบางครั้งอาจอนุญาตให้อ่านข้อกำหนดคุณลักษณะได้มากขึ้น
ผักกาดหอม
ผักกาดหอมเป็นเครื่องมือ BDD ที่ใช้แตงกวา สามารถดำเนินการคำอธิบายฟังก์ชันข้อความธรรมดาเป็นการทดสอบอัตโนมัติสำหรับโครงการ Python Lettuce มุ่งเป้าไปที่งานที่พบบ่อยที่สุดใน BDD
ความสามัคคี
Concordion เป็นเครื่องมือโอเพ่นซอร์สสำหรับการกำหนดคุณสมบัติโดยอัตโนมัติตามตัวอย่างสำหรับ Java Framework
แม้ว่าคุณสมบัติหลักจะเรียบง่าย แต่API เฟรมเวิร์กส่วนขยายที่มีประสิทธิภาพช่วยให้คุณสามารถเพิ่มฟังก์ชันการทำงานเช่นการใช้สเปรดชีต Excel เป็นข้อมูลจำเพาะการเพิ่มภาพหน้าจอไปยังเอาต์พุตการแสดงข้อมูลการบันทึกเป็นต้น
Concordion ช่วยให้คุณสามารถเขียนข้อกำหนดในภาษาปกติโดยใช้ย่อหน้าตารางและเครื่องหมายวรรคตอนที่เหมาะสมและภาษาที่มีโครงสร้างโดยใช้ Given / When / Then ไม่จำเป็น
Concordion ได้รับการแปลงเป็นภาษาอื่น ๆ ได้แก่ -
C # (Concordion.NET)
Python (PyConcordion)
ทับทิม (Ruby-Concordion)
Cucumber เป็นเครื่องมือที่รองรับข้อมูลจำเพาะของ Executable Test automation และ Living documentation
การพัฒนาพฤติกรรมที่ขับเคลื่อนขยายไปสู่ข้อกำหนดตามตัวอย่าง นอกจากนี้ยังกำหนดแนวทางปฏิบัติที่ดีที่สุดของ Test-Driven Development โดยเฉพาะอย่างยิ่งมุมมองของการทำงานจากภายนอกใน งานพัฒนาเป็นไปตามข้อกำหนดที่ปฏิบัติการได้
key features ของข้อกำหนดที่สามารถปฏิบัติการได้มีดังนี้ -
ข้อมูลจำเพาะที่ปฏิบัติการได้คือ -
มาจากตัวอย่างที่แสดงถึงพฤติกรรมของระบบ
เขียนด้วยความร่วมมือของทุกฝ่ายที่เกี่ยวข้องในการพัฒนารวมถึงธุรกิจและผู้มีส่วนได้ส่วนเสีย
ขึ้นอยู่กับเกณฑ์การยอมรับ
การทดสอบการยอมรับที่เป็นไปตามข้อกำหนดปฏิบัติการเป็นไปโดยอัตโนมัติ
ภาษาที่ใช้ร่วมกันและแพร่หลายถูกใช้เพื่อเขียนข้อกำหนดที่สามารถปฏิบัติการได้และการทดสอบอัตโนมัติดังกล่าว -
คำศัพท์เฉพาะโดเมนถูกใช้ตลอดการพัฒนา
ทุกคนรวมถึงลูกค้าและผู้มีส่วนได้ส่วนเสียพูดถึงระบบข้อกำหนดและการนำไปใช้ในลักษณะเดียวกัน
คำศัพท์เดียวกันนี้ใช้เพื่อหารือเกี่ยวกับระบบที่มีอยู่ในข้อกำหนดเอกสารการออกแบบรหัสการทดสอบ ฯลฯ
ทุกคนสามารถอ่านและทำความเข้าใจข้อกำหนดและวิธีสร้างข้อกำหนดเพิ่มเติมได้
การเปลี่ยนแปลงสามารถแก้ไขได้ง่าย
เก็บเอกสารสด
แตงกวาช่วยในกระบวนการนี้เนื่องจากเชื่อมโยงข้อมูลจำเพาะที่สามารถปฏิบัติการได้กับรหัสจริงของระบบและการทดสอบการยอมรับอัตโนมัติ
วิธีนี้ได้รับการออกแบบมาเพื่อให้ลูกค้าและนักพัฒนาทำงานร่วมกัน เมื่อการทดสอบการยอมรับผ่านไปหมายความว่าข้อกำหนดของลักษณะการทำงานของระบบที่แสดงนั้นได้ถูกนำไปใช้อย่างถูกต้อง
การทดสอบการยอมรับแตงกวาโดยทั่วไป
ลองพิจารณาตัวอย่างต่อไปนี้
Feature − Sign up
การลงทะเบียนควรรวดเร็วและเป็นมิตร
สถานการณ์ - ลงทะเบียนสำเร็จ
New ผู้ใช้ควรได้รับอีเมลยืนยันและได้รับการต้อนรับเป็นการส่วนตัว
Given ฉันได้เลือกที่จะลงทะเบียน
When ฉันลงทะเบียนด้วยรายละเอียดที่ถูกต้อง
Then ฉันควรได้รับอีเมลยืนยัน
And ฉันควรเห็นข้อความทักทายส่วนตัว
จากตัวอย่างนี้เราจะเห็นว่า -
การทดสอบการยอมรับอ้างถึง Features.
คุณสมบัติอธิบายโดย Scenarios.
สถานการณ์ประกอบด้วย Steps.
ข้อกำหนดนี้เขียนด้วยภาษาธรรมชาติในไฟล์ข้อความธรรมดา แต่สามารถเรียกใช้งานได้
การทำงานของแตงกวา
Cucumber เป็นเครื่องมือบรรทัดคำสั่งที่ประมวลผลไฟล์ข้อความที่มีคุณลักษณะที่กำลังมองหาสถานการณ์ที่สามารถดำเนินการกับระบบของคุณได้ ให้เราเข้าใจว่าแตงกวาทำงานอย่างไร
ใช้ประโยชน์จากข้อตกลงมากมายเกี่ยวกับวิธีการตั้งชื่อไฟล์และตำแหน่งที่อยู่ (โฟลเดอร์ตามลำดับ) เพื่อให้ง่ายต่อการเริ่มต้น
แตงกวาช่วยให้คุณเก็บข้อมูลจำเพาะการทดสอบอัตโนมัติและเอกสารไว้ในที่เดียวกัน
แต่ละสถานการณ์คือรายการของขั้นตอนที่อธิบายถึงเงื่อนไขก่อนการกระทำและหลังเงื่อนไขของสถานการณ์ หากแต่ละขั้นตอนดำเนินการโดยไม่มีข้อผิดพลาดสถานการณ์จะถูกทำเครื่องหมายว่าผ่าน
เมื่อสิ้นสุดการวิ่งแตงกวาจะรายงานจำนวนสถานการณ์ที่ผ่านไป
หากมีบางอย่างล้มเหลวจะให้ข้อมูลเกี่ยวกับสิ่งที่ล้มเหลวเพื่อให้นักพัฒนาสามารถดำเนินการต่อได้
ในแตงกวา Features, Scenariosและขั้นตอนจะเขียนด้วยภาษาที่เรียกว่า Gherkin.
Gherkin เป็นภาษาอังกฤษแบบข้อความธรรมดา (หรือหนึ่งในกว่า 60 ภาษาอื่น ๆ ) ที่มีโครงสร้าง Gherkin เรียนรู้ได้ง่ายและโครงสร้างของมันช่วยให้คุณเขียนตัวอย่างได้อย่างกระชับ
แตงกวาดำเนินการไฟล์ของคุณที่มีข้อกำหนดปฏิบัติการที่เขียนด้วย Gherkin
แตงกวาต้องการคำจำกัดความขั้นตอนเพื่อแปลข้อความธรรมดา Gherkin Steps เป็นการกระทำที่จะโต้ตอบกับระบบ
เมื่อแตงกวาดำเนินการขั้นตอนในสถานการณ์จำลองจะมองหาคำจำกัดความของขั้นตอนที่ตรงกันเพื่อดำเนินการ
Step Definition คือโค้ดชิ้นเล็ก ๆ ที่มีรูปแบบติดอยู่
รูปแบบนี้ใช้เพื่อเชื่อมโยง Step Definition กับขั้นตอนที่ตรงกันทั้งหมดและโค้ดคือสิ่งที่ Cucumber จะดำเนินการเมื่อเห็นขั้นตอน Gherkin
แต่ละขั้นตอนจะมาพร้อมกับคำจำกัดความของขั้นตอน
ขั้นตอนส่วนใหญ่จะรวบรวมข้อมูลเข้าจากนั้นมอบหมายให้กับกรอบงานที่เฉพาะเจาะจงสำหรับโดเมนแอปพลิเคชันของคุณเพื่อโทรออกในกรอบงานของคุณ
Cucumber รองรับแพลตฟอร์มซอฟต์แวร์ที่แตกต่างกันมากกว่าโหล คุณสามารถเลือกการใช้งานแตงกวาที่เหมาะกับคุณได้ การใช้งาน Cucumber ทุกครั้งมีฟังก์ชันการทำงานโดยรวมที่เหมือนกันและยังมีขั้นตอนการติดตั้งและฟังก์ชันเฉพาะแพลตฟอร์มของตัวเองอีกด้วย
ขั้นตอนการทำแผนที่และคำจำกัดความของขั้นตอน
กุญแจสำคัญของแตงกวาคือการจับคู่ระหว่างขั้นตอนและคำจำกัดความขั้นตอน
การใช้แตงกวา
ด้านล่างนี้คือการใช้แตงกวา
|
ทับทิม / JRuby |
|
JRuby (ใช้ Cucumber-JVM) |
|
Java |
|
Groovy |
|
.NET (ใช้ SpecFlow) |
|
JavaScript |
|
JavaScript (ใช้ Cucumber-JVM และ Rhino) |
|
Clojure |
|
โกซู |
|
ลัวะ |
|
PHP (ใช้ Behat) |
|
Jython |
|
C ++ |
|
Tcl |
การรวมกรอบ
ด้านล่างนี้คือการใช้งาน Framework
|
ทับทิมบนราง |
|
ซีลีเนียม |
|
PicoContainer |
|
กรอบสปริง |
|
Watir |
Gherkin เป็นภาษาที่ใช้ในการเขียน Features, Scenarios, and Steps. จุดประสงค์ของ Gherkin คือช่วยเราเขียนข้อกำหนดที่เป็นรูปธรรม
เพื่อทำความเข้าใจความหมายของข้อกำหนดที่เป็นรูปธรรมให้พิจารณาตัวอย่างต่อไปนี้ -
ควรป้องกันไม่ให้ลูกค้าป้อนรายละเอียดบัตรเครดิตที่ไม่ถูกต้อง
หากลูกค้าป้อนหมายเลขบัตรเครดิตที่มีความยาวไม่ตรง 16 หลักเมื่อพยายามส่งแบบฟอร์มควรแสดงข้อความแสดงข้อผิดพลาดอีกครั้งเพื่อแจ้งจำนวนหลักที่ถูกต้อง
หลังไม่มีความคลุมเครือและหลีกเลี่ยงข้อผิดพลาดและสามารถทดสอบได้มากขึ้น
Gherkin ออกแบบมาเพื่อสร้างข้อกำหนดที่เป็นรูปธรรมมากขึ้น ใน Gherkin ตัวอย่างข้างต้นมีลักษณะดังนี้ -
Feature
ข้อเสนอแนะเมื่อป้อนรายละเอียดบัตรเครดิตที่ไม่ถูกต้อง Feature Definition
ในการทดสอบผู้ใช้เราได้เห็นหลายคนที่ทำเอกสารผิดพลาด
Background True for all Scenarios Below
Given ฉันได้เลือกสินค้าที่จะซื้อ
And ฉันกำลังจะป้อนหมายเลขบัตรเครดิตของฉัน
Scenario - หมายเลขบัตรเครดิตสั้นเกินไปScenario Definition
When ฉันป้อนหมายเลขบัตรที่มีความยาวน้อยกว่า 16 หลัก
And รายละเอียดอื่น ๆ ทั้งหมดถูกต้อง
And ฉันส่งแบบฟอร์มSteps
Then ควรแสดงแบบฟอร์มอีกครั้ง
And ฉันควรเห็นข้อความแจ้งจำนวนหลักที่ถูกต้อง
รูปแบบและไวยากรณ์ของ Gherkin
ไฟล์ Gherkin เป็นไฟล์ข้อความธรรมดาและมีนามสกุล. คุณลักษณะ แต่ละบรรทัดที่ไม่ว่างจะต้องขึ้นต้นด้วยคีย์เวิร์ด Gherkin ตามด้วยข้อความที่คุณต้องการ คีย์เวิร์ดคือ -
Feature
Scenario
ให้เมื่อนั้นและ แต่ (ขั้นตอน)
Background
เค้าโครงสถานการณ์
Examples
"" "(สตริงเอกสาร)
| (ตารางข้อมูล)
@ (แท็ก)
# (ความคิดเห็น)
*
ลักษณะเฉพาะ
Featureคำสำคัญใช้เพื่ออธิบายคุณลักษณะของซอฟต์แวร์และเพื่อจัดกลุ่มสถานการณ์ที่เกี่ยวข้อง คุณลักษณะมีองค์ประกอบพื้นฐานสามประการ -
คำสำคัญ - คุณลักษณะ
ชื่อของสถานที่ซึ่งอยู่ในบรรทัดเดียวกับคำสำคัญของคุณลักษณะ
คำอธิบายที่ไม่บังคับ (แต่แนะนำอย่างยิ่ง) ที่สามารถขยายได้หลายบรรทัดเช่นข้อความทั้งหมดระหว่างบรรทัดที่มีคุณลักษณะคำหลักและบรรทัดที่ขึ้นต้นด้วย Scenario, Background หรือ Scenario Outline
นอกจากชื่อและคำอธิบายแล้วฟีเจอร์ยังมีรายการสถานการณ์หรือโครงร่างสถานการณ์และพื้นหลังเพิ่มเติม
เป็นเรื่องธรรมดาที่จะตั้งชื่อ a .featureโดยใช้ชื่อของฟีเจอร์แปลงเป็นตัวพิมพ์เล็กและแทนที่ช่องว่างด้วยขีดเส้นใต้ ตัวอย่างเช่น,
feedback_when_entering_invalid_credit_card_details.feature
ในการระบุคุณลักษณะในระบบของคุณคุณสามารถใช้สิ่งที่เรียกว่า "เทมเพลตการแทรกฟีเจอร์"
คำอธิบาย
เอกสารบางส่วนของ Gherkin ไม่ต้องขึ้นต้นด้วยคีย์เวิร์ด
ในบรรทัดต่อจากคุณลักษณะสถานการณ์โครงร่างสถานการณ์หรือตัวอย่างคุณสามารถเขียนอะไรก็ได้ที่คุณต้องการตราบเท่าที่ไม่มีบรรทัดใดขึ้นต้นด้วยคำสำคัญ นี่คือวิธีรวมคำอธิบาย
สถานการณ์
ในการแสดงลักษณะการทำงานของระบบของคุณคุณแนบสถานการณ์อย่างน้อยหนึ่งสถานการณ์กับแต่ละคุณสมบัติ เป็นเรื่องปกติที่จะเห็น 5 ถึง 20 สถานการณ์ต่อฟีเจอร์เพื่อระบุพฤติกรรมทั้งหมดที่อยู่รอบ ๆ ฟีเจอร์นั้นอย่างสมบูรณ์
สถานการณ์เป็นไปตามรูปแบบต่อไปนี้ -
อธิบายบริบทเริ่มต้น
อธิบายเหตุการณ์
อธิบายผลที่คาดว่าจะได้รับ
เราเริ่มต้นด้วยบริบทอธิบายการกระทำและตรวจสอบผลลัพธ์ นี้ทำตามขั้นตอน Gherkin มีคำหลักสามคำเพื่ออธิบายบริบทการกระทำและผลลัพธ์เป็นขั้นตอน
Given - สร้างบริบท
When - ดำเนินการ
Then - ตรวจสอบผลลัพธ์
คำหลักเหล่านี้ช่วยให้สามารถอ่านสถานการณ์ได้
Example
Scenario - ถอนเงินจากบัญชี
Given ฉันมีเงิน $ 100 ในบัญชีของฉัน
When ฉันขอ $ 20
Then ควรจ่าย $ 20
หากมีหลายตัว Given หรือ When ขั้นตอนข้างใต้คุณสามารถใช้ And หรือ But. ช่วยให้คุณระบุสถานการณ์โดยละเอียดได้
Example
Scenario - พยายามถอนโดยใช้บัตรที่ถูกขโมย
Given ฉันมีเงิน $ 100 ในบัญชีของฉัน
But บัตรของฉันไม่ถูกต้อง
When ฉันขอ $ 50
Then บัตรของฉันไม่ควรถูกส่งคืน
And ฉันควรจะบอกให้ติดต่อธนาคาร
ในขณะที่สร้างสถานการณ์โปรดจำไว้ว่า 'แต่ละสถานการณ์ต้องมีเหตุผลและสามารถดำเนินการได้โดยไม่ขึ้นกับสถานการณ์อื่น ๆ ' ' ซึ่งหมายความว่า -
คุณไม่สามารถมีเงื่อนไขความสำเร็จของสถานการณ์หนึ่งขึ้นอยู่กับข้อเท็จจริงที่ว่าสถานการณ์อื่น ๆ ถูกดำเนินการก่อนหน้านั้น
แต่ละสถานการณ์สร้างบริบทเฉพาะดำเนินการสิ่งหนึ่งและทดสอบผลลัพธ์
สถานการณ์ดังกล่าวให้ประโยชน์ดังต่อไปนี้ -
แบบทดสอบจะง่ายขึ้นและเข้าใจง่ายขึ้น
คุณสามารถเรียกใช้เพียงบางส่วนของสถานการณ์ของคุณและคุณไม่ต้องกังวลว่าชุดทดสอบของคุณจะพัง
ขึ้นอยู่กับระบบของคุณคุณอาจสามารถเรียกใช้การทดสอบควบคู่กันได้ซึ่งจะช่วยลดระยะเวลาในการดำเนินการทดสอบทั้งหมดของคุณ
เค้าโครงสถานการณ์
หากคุณต้องเขียนสถานการณ์ที่มีอินพุตหรือเอาต์พุตหลายรายการคุณอาจต้องสร้างสถานการณ์ต่างๆที่แตกต่างกันตามค่าของสถานการณ์เท่านั้น วิธีแก้ปัญหาคือการใช้โครงร่างสถานการณ์ ในการเขียนโครงร่างสถานการณ์
ตัวแปรในขั้นตอนเค้าร่างสถานการณ์จะถูกทำเครื่องหมายด้วย <และ>
ค่าต่างๆของตัวแปรจะแสดงเป็นตัวอย่างในตาราง
Example
สมมติว่าคุณกำลังเขียนคุณลักษณะสำหรับการเพิ่มตัวเลขสองตัวบนเครื่องคิดเลข
Feature - เพิ่ม
Scenario Outline: Add two numbers.
Given the input "<input>"
When the calculator is run
Then the output should be <output>"
Examples
| input | output |
| 2+2 | 4 |
| 98+1 | 99 |
| 255+390 | 645 |
ส่วนโครงร่างสถานการณ์จะตามมาด้วยตัวอย่างหนึ่งส่วนหรือมากกว่าเสมอซึ่งเป็นคอนเทนเนอร์สำหรับตาราง ตารางต้องมีแถวส่วนหัวที่สอดคล้องกับตัวแปรในขั้นตอนเค้าร่างสถานการณ์ แต่ละแถวด้านล่างจะสร้างสถานการณ์ใหม่โดยกรอกค่าตัวแปร
SpecFlow เป็นโครงการโอเพ่นซอร์ส ซอร์สโค้ดโฮสต์อยู่บน GitHub ไฟล์คุณลักษณะที่ SpecFlow ใช้เพื่อจัดเก็บเกณฑ์การยอมรับสำหรับคุณลักษณะ (กรณีการใช้งานเรื่องราวของผู้ใช้) ในแอปพลิเคชันของคุณถูกกำหนดโดยใช้ไวยากรณ์ของ Gherkin
Cucumber นำรูปแบบ Gherkin มาใช้และยังใช้โดยเครื่องมืออื่น ๆ ภาษา Gherkin ได้รับการดูแลเป็นโครงการบน GitHub -https://github.com/cucumber/gherkin
องค์ประกอบคุณลักษณะและ SpecFlow
คุณสมบัติที่สำคัญขององค์ประกอบคุณลักษณะคือ -
องค์ประกอบคุณลักษณะจัดเตรียมส่วนหัวสำหรับไฟล์คุณลักษณะ องค์ประกอบคุณลักษณะประกอบด้วยชื่อและคำอธิบายระดับสูงของคุณลักษณะที่เกี่ยวข้องในแอปพลิเคชันของคุณ
SpecFlow สร้างคลาสทดสอบหน่วยสำหรับองค์ประกอบคุณลักษณะโดยมีชื่อคลาสที่มาจากชื่อของคุณลักษณะ
SpecFlow สร้างการทดสอบหน่วยปฏิบัติการจากสถานการณ์ที่แสดงถึงเกณฑ์การยอมรับ
ไฟล์ฟีเจอร์อาจมีหลายสถานการณ์ที่ใช้อธิบายการทดสอบการยอมรับของฟีเจอร์
สถานการณ์มีชื่อและอาจประกอบด้วยขั้นตอนสถานการณ์จำลองหลายขั้นตอน
SpecFlow สร้างวิธีการทดสอบหน่วยสำหรับแต่ละสถานการณ์โดยมีชื่อวิธีการที่ได้มาจากชื่อของสถานการณ์จำลอง
ขั้นตอนหลายสถานการณ์
สถานการณ์อาจมีหลายขั้นตอนสถานการณ์ มีขั้นตอนสามประเภทที่กำหนดเงื่อนไขเบื้องต้นการดำเนินการหรือขั้นตอนการตรวจสอบซึ่งประกอบด้วยการทดสอบการยอมรับ
ขั้นตอนประเภทต่างๆเริ่มต้นด้วยไฟล์ Given, When หรือ Then คำหลักตามลำดับและขั้นตอนที่ตามมาของประเภทเดียวกันสามารถเชื่อมโยงโดยใช้ And และ But คำหลัก
ไวยากรณ์ของ Gherkin อนุญาตให้ใช้ขั้นตอนทั้งสามประเภทนี้ร่วมกันได้ แต่สถานการณ์มักจะมีบล็อกที่แตกต่างกัน Given, When และ Then งบ
ขั้นตอนสถานการณ์ถูกกำหนดโดยใช้ข้อความและสามารถมีตารางเพิ่มเติมที่เรียกว่า DataTable หรือข้อความหลายบรรทัดที่เรียกว่าอาร์กิวเมนต์ DocString
ขั้นตอนสถานการณ์เป็นวิธีหลักในการเรียกใช้โค้ดที่กำหนดเองเพื่อทำให้แอปพลิเคชันเป็นอัตโนมัติ
SpecFlow สร้างการโทรภายในวิธีการทดสอบหน่วยสำหรับแต่ละขั้นตอนสถานการณ์ การเรียกใช้ดำเนินการโดยรันไทม์ SpecFlow ที่จะดำเนินการกำหนดขั้นตอนที่ตรงกับขั้นตอนสถานการณ์
การจับคู่เสร็จสิ้นที่รันไทม์ดังนั้นการทดสอบที่สร้างขึ้นสามารถรวบรวมและดำเนินการได้แม้ว่าจะยังไม่ได้ใช้การเชื่อมโยงก็ตาม
คุณสามารถรวมตารางและอาร์กิวเมนต์แบบหลายบรรทัดในขั้นตอนสถานการณ์จำลอง สิ่งเหล่านี้ถูกใช้โดยข้อกำหนดขั้นตอนและส่งผ่านเป็นอาร์กิวเมนต์ตารางหรือสตริงเพิ่มเติม
แท็ก
แท็กคือเครื่องหมายที่สามารถกำหนดให้กับคุณลักษณะและสถานการณ์ต่างๆ การกำหนดแท็กให้กับคุณลักษณะจะเทียบเท่ากับการกำหนดแท็กให้กับสถานการณ์ทั้งหมดในไฟล์คุณลักษณะ ชื่อแท็กที่มีแท็ก @ นำหน้า
หากได้รับการสนับสนุนโดยกรอบการทดสอบหน่วย SpecFlow จะสร้างประเภทจากแท็ก
ชื่อหมวดหมู่ที่สร้างขึ้นจะเหมือนกับชื่อของแท็ก แต่ไม่มี @ นำหน้า
คุณสามารถกรองและจัดกลุ่มการทดสอบที่จะดำเนินการโดยใช้หมวดหมู่การทดสอบหน่วยเหล่านี้ ตัวอย่างเช่นคุณสามารถติดแท็กการทดสอบที่สำคัญด้วย @important จากนั้นดำเนินการทดสอบเหล่านี้บ่อยขึ้น
องค์ประกอบพื้นหลัง
อิลิเมนต์ภาษาพื้นหลังอนุญาตให้ระบุเงื่อนไขเบื้องต้นทั่วไปสำหรับสถานการณ์ทั้งหมดในไฟล์คุณลักษณะ
ส่วนพื้นหลังของไฟล์สามารถมีขั้นตอนสถานการณ์จำลองอย่างน้อยหนึ่งขั้นตอนที่ดำเนินการก่อนขั้นตอนอื่น ๆ ของสถานการณ์
SpecFlow สร้างวิธีการจากองค์ประกอบพื้นหลังที่เรียกใช้จากการทดสอบหน่วยทั้งหมดที่สร้างขึ้นสำหรับสถานการณ์จำลอง
เค้าโครงสถานการณ์
เค้าโครงสถานการณ์สามารถใช้เพื่อกำหนดการทดสอบการยอมรับจากข้อมูล เค้าร่างสถานการณ์จะประกอบด้วยข้อกำหนดเทมเพลตสถานการณ์ (สถานการณ์จำลองที่มีตัวยึดข้อมูลโดยใช้ไวยากรณ์ <placeholder>) และชุดตัวอย่างที่ระบุค่าสำหรับตัวยึดตำแหน่ง
หากเฟรมเวิร์กการทดสอบหน่วยรองรับ SpecFlow จะสร้างการทดสอบตามแถวจากโครงร่างสถานการณ์
มิฉะนั้นจะสร้างวิธีลอจิกทดสอบหน่วยพารามิเตอร์สำหรับโครงร่างสถานการณ์จำลองและวิธีการทดสอบแต่ละหน่วยสำหรับชุดตัวอย่างแต่ละชุด
เพื่อให้สามารถตรวจสอบย้อนกลับได้ดีขึ้นชื่อวิธีการทดสอบหน่วยที่สร้างขึ้นจะได้มาจากชื่อโครงร่างสถานการณ์และค่าแรกของตัวอย่าง (คอลัมน์แรกของตารางตัวอย่าง)
ดังนั้นจึงเป็นแนวทางปฏิบัติที่ดีในการเลือกพารามิเตอร์ที่ไม่ซ้ำกันและเป็นคำอธิบายเป็นคอลัมน์แรกในชุดตัวอย่าง
เนื่องจากไวยากรณ์ของ Gherkin ต้องการให้คอลัมน์ตัวอย่างทั้งหมดมีตัวยึดตำแหน่งที่ตรงกันในโครงร่างสถานการณ์คุณยังสามารถแนะนำคอลัมน์ตามอำเภอใจในชุดตัวอย่างที่ใช้เพื่อตั้งชื่อการทดสอบให้อ่านง่ายขึ้น
SpecFlow ทำการแทนที่ตัวยึดตำแหน่งเป็นเฟสแยกก่อนที่จะจับคู่การโยงขั้นตอน
การใช้งานและพารามิเตอร์ในการโยงขั้นตอนจึงไม่ขึ้นกับว่าจะดำเนินการผ่านสถานการณ์จำลองโดยตรงหรือโครงร่างสถานการณ์
ซึ่งช่วยให้คุณระบุตัวอย่างเพิ่มเติมในการทดสอบการยอมรับในภายหลังโดยไม่ต้องเปลี่ยนการเชื่อมโยงขั้นตอน
ความคิดเห็น
คุณสามารถเพิ่มบรรทัดความคิดเห็นลงในไฟล์ฟีเจอร์ได้ทุกที่โดยขึ้นต้นบรรทัดด้วย # อย่างไรก็ตามโปรดระวังเนื่องจากความคิดเห็นในข้อกำหนดของคุณอาจเป็นสัญญาณว่ามีการระบุเกณฑ์การยอมรับผิด SpecFlow ละเว้นบรรทัดข้อคิดเห็น