การพัฒนาพฤติกรรมที่ขับเคลื่อน - คู่มือฉบับย่อ

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

ในการระบุคุณลักษณะในระบบของคุณคุณสามารถใช้สิ่งที่เรียกว่า "เทมเพลตการแทรกฟีเจอร์"

เพื่อที่จะ <บรรลุเป้าหมาย> ในฐานะ <ประเภทผู้ใช้> ฉันต้องการ <a 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 ละเว้นบรรทัดข้อคิดเห็น