อะไรคือ Test Driven Development (TDD)?

TDD สามารถอธิบายได้ว่า เป็นการฝึกโปรแกรมเพื่อให้นักพัฒนาทราบถึงว่าโค้ดใหม่ที่เขียนขึ้นมาเมื่อได้รับการทดสอบแล้วมันผิดพลาดไหม  แถมยังหลีกเลี่ยงโค้ดที่ซ้ำกันได้อีกด้วย โดย TDD ย่อมาจาก Test Driven Development เป้าหมายหลักของ TDD คือการทำให้โค้ดสะอาด เรียบง่าย  และปราศจากบัค

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

ในกระบวนการทดสอบ software ปกตินั้น  เราต้องทำการประมวลโค้ดก่อนแล้วจึงจะทดสอบได้  การทดสอบอาจจะล้มเหลวตั้งแต่ตอนทดสอบเลยก็ได้ เนื่องจากการทดสอบนั้นเป็นการทดสอบก่อนการเขียนโค้ดขึ้นมานั่นเอง ในการทดสอบนั้นถ้าเกิดผ่าน ทีมนักพัฒนาก็จะพัฒนาส่วนอื่นๆ และการ Refactor โค้ด ส่วนการ Refactor หมายถึง การเปลี่ยนโค้ดบางตัวโดยปราศจากการส่งผลใด ๆ ต่อโปรแกรม

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

TDD เป็นกระบวนการในการพัฒนา  และการทำการทดสอบระบบอัตโนมัติ  ก่อนจะมีการพัฒนาโปรแกรมจริง ๆ ด้วยเหตุนี้บางทีแล้ว TDD จะถูกเรียกว่า การทดสอบก่อนพัฒนา

ในบทความนี้จะให้คุณรู้จัก

• อะไรคือ TDD
• การทดสอบ TDD ทำได้อย่างไร
• TDD และการทดสอบแบบดั่งเดิม
• อะไรคือการยอมรับ TDD และผู้พัฒนา TDD
• การปรับเปลี่ยนขนาดของ TDD ผ่าน Agile Model Drive Developer (AMDD)
• การทดสอบก่อนการพัฒนา (TDD) กับ การทดสอบก่อนการพัฒนาโดยใช้ Agile Model (AMDD)
• ตัวอย่างของ TDD
• ได้อะไรกับ TDD

ทดสอบ TDD ได้อย่างไร

เราสามารถทำการทดสอบ TDD ได้ดังนี้

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

วงจร TDD

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

บางทีก็อธิบายเกี่ยว TDD ได้อีกแบบนึง

• TDD ไม่ใช่ทั้ง การทดสอบ หรือ การออกแบบ
• TDD ไม่ได้หมายถึง เขียนบางอย่างเพื่อทดสอบ  และทำให้ระบบมันผ่านการทดสอบ
• TDD ไม่ได้หมายถึง ทำให้เยอะ เพื่อทดสอบนะ

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

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

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

อะไรคือ acceptance TDD และ Developer TDD

TDD มี 2 ระดับ

1. Acceptance TDD (ATDD): คุณสามารถเขียนการทดสอบสำหรับ acceptance มาหนึ่งการทดสอบ  นี้เป็นการทดสอบหาความต้องการของระบบ จากนั้นเขียนโค้ดต่าง ๆ เพื่อเติมให้กับการทดสอบที่ยอมรับได้นี้  การทดสอบนี้จะมุ่งเป้าไปที่พฤติกรรมของระบบทั้งหมด ATDD ยังรู้จักในอีกชื่อ Behavioral Driven Development (BDD)
2. Developer TDD: Developer TDD คุณเขียนการทดสอบแบบ developer มาเพียงตัวนึง เช่น หน่วยการทดสอบ  และจากนั้นก็ทำการเขียนโค้ดเพื่อเติมเต็มในส่วนของการทดสอบนั้น หน่วยการทดสอบจะทำการเน้นไปที่ฟังชันก์การทำงานเล็ก ๆ น้อย ๆ ทั้งหมดของระบบ  โดย Developer TDD เรียนง่าย ๆ ว่า TDD

เป้าหมายหลักของ ATDD และ TDD นั่นเป็นอะไรที่เฉพาะทาง  ความต้องการในการทำงานสำหรับการแก้ปัญหาของคุณโดยใช้หลักพื้นฐาน JIT  

โดย JIT นั่นหมายถึงการเติมเต็มความต้องการที่เกิดขึ้นในระบบ  ทำให้มันมีประสิทธิภาพนั่นเอง

Scaling TDD ผ่าน Agile Model Driven Development (AMDD)

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

ดังนั้น AMDD จึงถูกใช้ในปัญหาที่ใหญ่กว่า

วงจรของ AMDD.

Model-driven Development (MDD) โมเดลที่ได้ทำการเพิ่มเข้ามาได้ถูกสร้างก่อนที่โค้ดจะถูกเขียนอีก  โดย Agile จะทำการใช้งาน

ในภาพข้างบน  จะเห็นได้ว่ากล่องบอกถึงกิจกรรมต่าง ๆ ที่เกิดขึ้น

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

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

1. ทบทวน 0: Envisioning

มีสองหัวข้อย่อยหลัก

• 1. ความต้องเริ่มต้นของ Envisioning
• บางทีอาจจะต้องใช้ความต้องในระดับสูงในการระบุตัวตน และมุมมองของระบบ  โดยการมุ่งเน้นหลักไปที่การสำรวจการใช้งานโมเดลต่าง ๆ , โมเดลเริ่มต้น, และโมเดล UI
  2. สถาปัตยกรรมของ envisioning ตอนเริ่มต้น
• ระบบนี้จำเป็นต้องใช้เวลาหลายที่จะระบุสถาปัตยกรรมระบบ  มันสามารถปรับแต่ทิศทางและเทคนิคต่าง ๆ ให้สอดคล้องกับโครงการได้  โดยหลักการนี้จะมุ่งเน้นไปที่ไดอะแกรมในเรื่องเทคโนโลยีการสำรวจ, การไหลของ UI, โมเดลโดเมน, และการเปลี่ยนแปลงเคสต่าง ๆ

2. ทบทวน modeling:

ทีมนี้จะต้องวางแผนการทำงานเพื่อให้จะเสร็จในแต่ละหัวข้อ

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

3. การยำ Model

นี้อาจะทำให้รู้จัก JIT Model

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

4. Test Driven Development (TDD).

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

5. ตรวจทาน

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

Test Driven Development (TDD) กับ Agile Model Driven Development (AMDD)

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

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

นี้เป็นเพียงตัวอย่าง  พวกเราจะอธิบายรหัสผ่านของคลาสต่าง ๆ สำหรับคลาสนี้พวกพยายามที่ให้ตามความพอใจ

 

สภาพวะสำหรับรหัสผ่านที่ยอมรับได้

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

อันดับแรก พวกเราเขียนโค้ดเพื่อให้เติมกับความต้องการข้างต้น

สถานการณ์ 1: เพื่อที่จะทำการทดสอบ  พวกเราได้สร้างคลาส PasswordValidator ();

พวกเราจะให้คลาส TestPassword (); ทำงาน

ผลเป็น PASSED ตามที่แสดงด้านล่าง

แสดงผล

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

พวกเราจะลบคลาส PasswordValidator pv = new PasswordValidator () จากโค้ด พวกเราก็สามารถเรียก isValid () โดย PasswordValidator. IsValid ("Abc123"). ตามภาพด้านล่าง

ดังนั้นเราจะ Refactor (เปลี่ยนโค้ด) ตามภาพ

สถานการณ์ 3: หลักจากได้ทำการ refactor ทำให้สถานะล้อเหลวตามที่แสดงมา (จากภาพข้างล่าง) นี้เพราะว่าพวกเราได้ลบค่าคงที่ดังกล่าว  นั่นทำให้ไม่มีแหล่งอ้างอิงถึง วิธีการ ไม่คงที่ isValid ().

ดังนั้นพวกเราต้องการที่เปลี่ยนแปลงวิธีการนี้  โดยการเพิ่มคำว่า static ก่อน และประกาศให้เป็นค่า Boolean โดยประกาศว่า public static boolean isValid (รหัสผ่านเป็นค่าสตริง)  refactor ที่คลาส PasswordValidator() เพื่อที่จะลบข้อผิดพลาดรูปบนเพื่อที่ผ่านการทดสอบนี้ไปได้

ผลลัพธ์

หลักจากได้เปลี่ยนคลาส PassValidator() ถ้าพวกเราทำการใช้งานผลทดสอบนี้  ก็จะแสดงว่า PASSED ตามรูปด้านล่าง

ข้อดีของ TDD

• พบ Bug ตั้งแต่แรก

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

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

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

• ดีต่อใจ ใช่ต่อ dev

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

สรุป:

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

เตรียมพบกับหลักสูตร FULL TIME COURSE (JAVA)) เรียนกัน 3 เดือน

1. คอร์สเรียนเข้มข้นจันทร์ – ศุกร์ เต็มวัน
2. ฝึกงานด้วย Agile/Scrum ได้ทำงานจริงกับบริษัทจริง
3. Speed Dating Day เลือกบริษัทที่ใช่กว่า 30 บริษัท

รายละเอียดเพิ่มเติม คลิกที่นี่