การพัฒนาแบบทดสอบขับเคลื่อน (TDD) คืออะไร? ตัวอย่าง

การพัฒนาแบบทดสอบขับเคลื่อน (TDD) คืออะไร?

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

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

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

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

วิธีดำเนินการทดสอบ TDD

ขั้นตอนต่อไปนี้จะกำหนดวิธีการดำเนินการทดสอบ TDD

1. เพิ่มการทดสอบ
2. รันการทดสอบทั้งหมดและดูว่าการทดสอบใหม่ล้มเหลวหรือไม่
3. เขียนรหัสบางอย่าง
4. รันการทดสอบและโค้ด Refactor
5. ทำซ้ำ

วงจร TDD กำหนด

1. เขียนแบบทดสอบ
2. ทำให้มันทำงาน
3. เปลี่ยนโค้ดให้ถูกต้อง เช่น Refactor
4. ทำซ้ำกระบวนการ

คำชี้แจงบางประการเกี่ยวกับ TDD:

• แนวทาง TDD ไม่ได้เกี่ยวกับ "การทดสอบ" หรือ "การออกแบบ"
• TDD ไม่ได้หมายความว่า “เขียนการทดสอบบางส่วน แล้วสร้างระบบที่ผ่านการทดสอบ”
• TDD ไม่ได้หมายความว่า “ทำการทดสอบมากมาย”

TDD กับ การทดสอบแบบดั้งเดิม

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

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

• ด้วยการทดสอบแบบดั้งเดิม การทดสอบที่ประสบความสำเร็จจะพบข้อบกพร่องอย่างน้อยหนึ่งข้อ มันเหมือนกับ TDD เมื่อการทดสอบล้มเหลว แสดงว่าคุณก้าวหน้าไปเพราะคุณรู้ว่าคุณต้องแก้ไขปัญหา
• TDD ทำให้แน่ใจว่าระบบของคุณตรงตามข้อกำหนดที่กำหนดไว้จริงๆ ช่วยสร้างความมั่นใจเกี่ยวกับระบบของคุณ
• ใน TDD สิ่งสำคัญเพิ่มเติมคือรหัสการผลิตที่ตรวจสอบว่าการทดสอบทำงานอย่างถูกต้องหรือไม่ ในการทดสอบแบบดั้งเดิม การเน้นไปที่การออกแบบกรณีทดสอบมากขึ้น การทดสอบจะแสดงการดำเนินการแอปพลิเคชันที่เหมาะสม/ไม่เหมาะสมเพื่อให้เป็นไปตามข้อกำหนดหรือไม่
• ใน TDD คุณจะผ่านการทดสอบความครอบคลุม 100% โค้ดทุกบรรทัดได้รับการทดสอบ ไม่เหมือนการทดสอบแบบเดิมๆ
• การผสมผสานระหว่างการทดสอบแบบดั้งเดิมและ TDD นำไปสู่ความสำคัญของการทดสอบระบบมากกว่าความสมบูรณ์แบบของระบบ
• In การสร้างแบบจำลองเปรียว (AM)คุณควร “ทดสอบอย่างมีเป้าหมาย” คุณควรรู้ว่าเหตุใดคุณจึงทดสอบบางสิ่งบางอย่าง และจำเป็นต้องทดสอบในระดับใด

TDD การยอมรับและ TDD ของนักพัฒนาคืออะไร

TDD มีสองระดับ

1. การยอมรับ TDD (ATDD): ด้วย ATDD คุณจะเขียนการทดสอบการยอมรับเพียงครั้งเดียว การทดสอบนี้เป็นไปตามข้อกำหนดของข้อกำหนดเฉพาะหรือตอบสนองพฤติกรรมของระบบ หลังจากนั้นให้เขียนรหัสการผลิต/ฟังก์ชันการทำงานที่เพียงพอเพื่อทำการทดสอบการยอมรับนั้น การทดสอบการยอมรับมุ่งเน้นไปที่พฤติกรรมโดยรวมของระบบ ATDD ยังเป็นที่รู้จักกันในนาม การพัฒนาที่ขับเคลื่อนด้วยพฤติกรรม (BDD).
2. นักพัฒนา TDD: ด้วย Developer TDD คุณจะเขียนการทดสอบสำหรับนักพัฒนารายเดียว เช่น การทดสอบหน่วย จากนั้นจึงสร้างโค้ดการผลิตที่เพียงพอสำหรับการทดสอบนั้น การทดสอบหน่วยจะเน้นที่ฟังก์ชันการทำงานเล็กๆ น้อยๆ ทั้งหมดของระบบ Developer TDD เรียกง่ายๆ ว่า as ทีดีดี.เป้าหมายหลักของ ATDD และ TDD คือการระบุข้อกำหนดโดยละเอียดที่สามารถดำเนินการได้สำหรับโซลูชันของคุณแบบทันเวลา (JIT) JIT หมายถึงการพิจารณาเฉพาะข้อกำหนดเหล่านั้นที่จำเป็นในระบบ จึงเพิ่มประสิทธิภาพ

การปรับขนาด TDD ด้วย Agile Model Driven Development (AMDD)

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

ดังนั้น AMDD จึงใช้สำหรับปัญหาที่ใหญ่กว่า

วงจรชีวิตของ AMDD

ใน Model-driven Development (MDD) โมเดลที่ครอบคลุมจะถูกสร้างขึ้นก่อนที่จะเขียนซอร์สโค้ด ซึ่งจะมีแนวทางที่คล่องตัว?

ในรูปด้านบน กล่องแต่ละกล่องแสดงถึงกิจกรรมการพัฒนา

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

เป็นกระบวนการที่ไม่ได้จัดทำข้อกำหนดโดยละเอียดของซอฟต์แวร์/ระบบ แต่เป็นการสำรวจความต้องการของซอฟต์แวร์/ระบบซึ่งกำหนดกลยุทธ์โดยรวมของโครงการ

ทำซ้ำ 0: จินตนาการ

มีการเปิดใช้งานย่อยหลักสองรายการ

1. การกำหนดความต้องการเบื้องต้นอาจใช้เวลาหลายวันในการระบุข้อกำหนดระดับสูงและขอบเขตของระบบ จุดสนใจหลักคือการสำรวจโมเดลการใช้งาน โมเดลโดเมนเริ่มต้น และโมเดลส่วนต่อประสานกับผู้ใช้ (UI)
2. แรกเริ่ม Archiการมองเห็นเชิงโครงสร้าง นอกจากนี้ ยังต้องใช้เวลาหลายวันในการระบุสถาปัตยกรรมของระบบ ซึ่งช่วยให้สามารถกำหนดทิศทางทางเทคนิคสำหรับโครงการได้ จุดเน้นหลักอยู่ที่การสำรวจไดอะแกรมเทคโนโลยี การไหลของอินเทอร์เฟซผู้ใช้ (UI) โมเดลโดเมน และกรณีการเปลี่ยนแปลง

การสร้างแบบจำลองการวนซ้ำ

ทีมงานจะต้องวางแผนงานที่จะทำในแต่ละรอบซ้ำ

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

การบุกโจมตีแบบจำลอง

สิ่งนี้เรียกว่าการสร้างแบบจำลองทันเวลาพอดี

• เซสชั่นการสร้างแบบจำลองในที่นี้เกี่ยวข้องกับทีมงาน 2/3 คนที่หารือเกี่ยวกับปัญหาต่างๆ บนกระดาษหรือไวท์บอร์ด
• สมาชิกในทีมคนหนึ่งจะขอให้อีกคนสร้างโมเดลร่วมกับพวกเขา เซสชันการสร้างแบบจำลองนี้จะใช้เวลาประมาณ 5 ถึง 10 นาที ที่ซึ่งสมาชิกในทีมรวมตัวกันเพื่อแบ่งปันไวท์บอร์ด/กระดาษ
• พวกเขาสำรวจปัญหาต่างๆ จนกระทั่งไม่พบสาเหตุหลักของปัญหา ทันเวลาพอดี หากสมาชิกในทีมคนหนึ่งระบุปัญหาที่เขา/เธอต้องการแก้ไข เขา/เธอก็จะได้รับความช่วยเหลืออย่างรวดเร็วจากสมาชิกในทีมคนอื่นๆ
• สมาชิกกลุ่มคนอื่นๆ สำรวจปัญหา จากนั้นทุกคนก็ดำเนินเรื่องต่อไปเหมือนเมื่อก่อน เรียกอีกอย่างว่าการสร้างแบบจำลองแบบสแตนด์อโลนหรือเซสชัน QA ของลูกค้า

การพัฒนาที่ขับเคลื่อนด้วยการทดสอบ (TDD)

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

รีวิว

• นี่เป็นทางเลือก รวมถึงการตรวจสอบโค้ดและการตรวจสอบโมเดล
• ซึ่งสามารถทำได้สำหรับการวนซ้ำแต่ละครั้งหรือสำหรับทั้งโปรเจ็กต์
• นี่เป็นตัวเลือกที่ดีในการแสดงความคิดเห็นสำหรับโปรเจ็กต์

การพัฒนาแบบทดสอบขับเคลื่อน (TDD) กับ การพัฒนาที่ขับเคลื่อนด้วยแบบจำลอง Agile (AMDD)

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

กรอบงาน TDD

นี่คือรายการกรอบงานการพัฒนาที่ขับเคลื่อนด้วยการทดสอบ (TDD) ที่ดีที่สุด

1. จูนิต
2. TestNG
3. csUnit และ NUnit
4. ข้อมูลจำเพาะ

ตอนนี้เรามาเรียนรู้ Test Driven Development ตามตัวอย่างกัน

ตัวอย่างของ TDD

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

เงื่อนไขในการรับรหัสผ่าน:

• รหัสผ่านควรอยู่ระหว่าง 5 ถึง 10 ตัวอักษร

อันดับแรกในตัวอย่าง TDD นี้ เราเขียนโค้ดที่ตรงตามข้อกำหนดข้างต้นทั้งหมด

สถานการณ์สมมติ 1: เพื่อรันการทดสอบ เราสร้างคลาส PasswordValidator ();

เราจะทำงานเหนือคลาส TestPassword ();

เอาต์พุตจะผ่านตามที่แสดงด้านล่าง

เอาท์พุต:

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

เราจะลบคลาส PasswordValidator pv = new PasswordValidator () ออกจากโค้ด เราเรียก. ถูกต้อง () วิธีการโดยตรงโดย เครื่องมือตรวจสอบรหัสผ่าน ถูกต้อง (“Abc123”)- (ดูภาพด้านล่าง)

ดังนั้นเราจึง Refactor (เปลี่ยนโค้ด) ดังนี้:

สถานการณ์สมมติ 3:หลังจากทำการรีแฟกเตอร์แล้ว ผลลัพธ์จะแสดงสถานะล้มเหลว (ดูภาพด้านล่าง) เนื่องจากเราได้ลบอินสแตนซ์ออกไปแล้ว ดังนั้นจึงไม่มีการอ้างอิงถึงวิธีการแบบไม่คงที่ ถูกต้อง ()

ดังนั้นเราจึงจำเป็นต้องเปลี่ยนวิธีการนี้โดยเพิ่มคำ "คงที่" หน้าบูลีนเป็นบูลีนคงที่สาธารณะ isValid (รหัสผ่านสตริง) Refactoring Class PasswordValidator () เพื่อลบข้อผิดพลาดด้านบนเพื่อให้ผ่านการทดสอบ

Output:

หลังจากทำการเปลี่ยนแปลงคลาส PassValidator () หากเรารันการทดสอบ ผลลัพธ์จะผ่านตามที่แสดงด้านล่าง

ข้อดีของ TDD

ต่อไปนี้เป็นข้อได้เปรียบหลักของการพัฒนาที่ขับเคลื่อนด้วยการทดสอบในวิศวกรรมซอฟต์แวร์:

การแจ้งเตือนข้อผิดพลาดล่วงหน้า

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

ออกแบบดีขึ้น โค้ดสะอาดขึ้น และขยายได้มากขึ้น

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

ความมั่นใจในการรีแฟคเตอร์

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

ดีสำหรับการทำงานเป็นทีม

• ในกรณีที่ไม่มีสมาชิกในทีม สมาชิกในทีมคนอื่นๆ สามารถรับและทำงานกับโค้ดได้อย่างง่ายดาย อีกทั้งยังช่วยแบ่งปันความรู้ทำให้ทีมโดยรวมมีประสิทธิภาพมากขึ้น

เหมาะสำหรับนักพัฒนา

• แม้ว่านักพัฒนาจะใช้เวลามากขึ้นในการเขียนกรณีทดสอบ TDD แต่ก็ใช้เวลาน้อยลงมากในการดีบักและพัฒนาคุณสมบัติใหม่ คุณจะเขียนโค้ดที่สะอาดขึ้นและซับซ้อนน้อยลง

สรุป

• TDD ย่อมาจาก Test-driven development
• TDD ความหมาย: เป็นกระบวนการแก้ไขโค้ดเพื่อผ่านการทดสอบที่ออกแบบไว้ก่อนหน้านี้
• เน้นที่รหัสการผลิตมากกว่าการออกแบบกรณีทดสอบ
• การพัฒนาที่ขับเคลื่อนด้วยการทดสอบเป็นกระบวนการแก้ไขโค้ดเพื่อที่จะผ่านการทดสอบที่ออกแบบไว้ก่อนหน้านี้
• In วิศวกรรมซอฟต์แวร์,บางครั้งก็เรียกว่า “ทดสอบการพัฒนาครั้งแรก”
• การทดสอบ TDD รวมถึงการรีแฟคเตอร์โค้ด เช่น การเปลี่ยน/เพิ่มโค้ดจำนวนหนึ่งให้กับโค้ดที่มีอยู่ โดยไม่กระทบต่อพฤติกรรมของโค้ด
• เมื่อใช้การเขียนโปรแกรม TDD โค้ดจะชัดเจนและเข้าใจง่ายยิ่งขึ้น