บทความ

Test Driven Development คืออะไร แนวทางและข้อดี

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

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

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

Test Driven Development (TDD) ถือกำเนิดขึ้นโดยเป็นส่วนหนึ่งของกระบวนทัศน์การออกแบบซอฟต์แวร์ขนาดใหญ่ที่เรียกว่า Extreme Programming (XP) ซึ่งเป็นส่วนหนึ่งของวิธีการพัฒนาซอฟต์แวร์แบบ Agile

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

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

ขั้นตอนของแนวทาง TDD

ก่อนที่จะเขียนโค้ดใหม่ โปรแกรมเมอร์ต้องสร้างการทดสอบหน่วยที่ล้มเหลวก่อน จากนั้นโปรแกรมเมอร์หรือคู่สามีภรรยาหรือม็อบจะสร้างโค้ดที่เพียงพอเพื่อตอบสนองความต้องการนั้น เมื่อการทดสอบผ่าน โปรแกรมเมอร์สามารถ refactor โครงการ ทำการปรับปรุงโดยไม่ต้องเปลี่ยนลักษณะการทำงาน

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


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

ข้อดีของ TDD

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

จดหมายข่าวนวัตกรรม
อย่าพลาดข่าวสารที่สำคัญที่สุดเกี่ยวกับนวัตกรรม ลงทะเบียนเพื่อรับพวกเขาทางอีเมล

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

ประโยชน์ที่คาดว่าจะได้รับ:

  • การลดอัตราข้อบกพร่องลงอย่างมาก ในราคาต้นทุนของความพยายามในการพัฒนาขั้นต้นที่เพิ่มขึ้นในระดับปานกลาง
  • ต้นทุนค่าโสหุ้ยได้รับการชดเชยมากกว่าการลดความพยายามในขั้นตอนสุดท้ายของโครงการ
  • TDD นำไปสู่คุณภาพการออกแบบที่ดีขึ้นในโค้ด และโดยทั่วไปแล้ว ระดับคุณภาพ "ภายใน" หรือทางเทคนิคที่สูงขึ้น ตัวอย่างเช่น โดยการปรับปรุงเมตริกการเกาะกันและการมีเพศสัมพันธ์

ข้อเสียของ TDD

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

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

สุดท้าย เช่นเดียวกับวิธีการอื่นๆ ผลลัพธ์สุดท้ายของ TDD จะดีเท่ากับการทดสอบที่ใช้ ความแม่นยำที่ดำเนินการ และขอบเขตที่เลียนแบบเงื่อนไขที่ผู้ใช้ผลิตภัณฑ์ขั้นสุดท้ายพบ

ข้อผิดพลาดทั่วไป:

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

ปรัชญาของทีดีดี

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

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

Ercole Palmeri

จดหมายข่าวนวัตกรรม
อย่าพลาดข่าวสารที่สำคัญที่สุดเกี่ยวกับนวัตกรรม ลงทะเบียนเพื่อรับพวกเขาทางอีเมล

บทความล่าสุด

อนาคตอยู่ที่นี่: อุตสาหกรรมการขนส่งกำลังปฏิวัติเศรษฐกิจโลกอย่างไร

ภาคกองทัพเรือเป็นมหาอำนาจทางเศรษฐกิจระดับโลกอย่างแท้จริง ซึ่งได้มุ่งหน้าสู่ตลาดมูลค่า 150 พันล้าน...

1 2024 พ.ค.

ผู้จัดพิมพ์และ OpenAI ลงนามข้อตกลงเพื่อควบคุมการไหลของข้อมูลที่ประมวลผลโดยปัญญาประดิษฐ์

เมื่อวันจันทร์ที่แล้ว Financial Times ได้ประกาศข้อตกลงกับ OpenAI FT อนุญาติให้ทำข่าวระดับโลก...

30 2024 เมษายน

การชำระเงินออนไลน์: นี่คือวิธีที่บริการสตรีมมิ่งทำให้คุณชำระเงินตลอดไป

ผู้คนนับล้านชำระค่าบริการสตรีมมิ่ง โดยจ่ายค่าธรรมเนียมการสมัครสมาชิกรายเดือน เป็นความเห็นทั่วไปที่คุณ...

29 2024 เมษายน

Veeam มีการสนับสนุนแรนซัมแวร์ที่ครอบคลุมที่สุด ตั้งแต่การป้องกันไปจนถึงการตอบสนองและการกู้คืน

Coveware by Veeam จะยังคงให้บริการตอบสนองต่อเหตุการณ์การขู่กรรโชกทางไซเบอร์ต่อไป Coveware จะนำเสนอความสามารถในการนิติเวชและการแก้ไข...

23 2024 เมษายน

อ่านนวัตกรรมในภาษาของคุณ

จดหมายข่าวนวัตกรรม
อย่าพลาดข่าวสารที่สำคัญที่สุดเกี่ยวกับนวัตกรรม ลงทะเบียนเพื่อรับพวกเขาทางอีเมล

ติดตามเรา