กฎสามข้อควบคุมการพัฒนาที่ขับเคลื่อนด้วยการทดสอบ (TDD) กฎข้อแรกยืนยันว่า 'เขียนโค้ดที่ใช้งานจริงเท่านั้นเพื่อให้การทดสอบหน่วยที่ล้มเหลวผ่านการทดสอบ '. ที่นี่เรามีหลักการสำคัญของ TDD — ที่เราระงับการเขียนโค้ดเชิงพฤติกรรม เรามีการทดสอบหน่วยที่เรียกร้องพฤติกรรม และการทดสอบนี้จะต้องล้มเหลว จากนั้นเราจะทำการทดสอบให้ผ่านโดยการสร้างพฤติกรรมที่เหมาะสมในโค้ดการใช้งาน
บ่อยครั้ง มันค่อนข้างตรงไปตรงมาที่จะสร้างการทดสอบหน่วยที่ล้มเหลวโดยกำหนดพฤติกรรมเฉพาะเมื่อเรามีคำจำกัดความของคลาสและเมธอดอยู่แล้ว
ในตัวอย่างด้านล่าง (เขียนด้วยภาษา C# โดยใช้ XUnit) อินสแตนซ์ SalesTaxSelector จะส่งข้อยกเว้นที่เหมาะสมเมื่อการทดสอบเรียกใช้เมธอด Select() บนตัวระบุประเทศที่ไม่ได้รับ SalesTax ที่สอดคล้องกัน:
ดี. แต่เหตุผลเดียวที่เราสามารถรันการทดสอบหน่วยนี้ได้ตั้งแต่แรกก็เพราะว่า
- เรามีคลาส
SalesTaxSelectorรวมถึงตัวสร้างเริ่มต้นและ SalesTaxSelectorมีเมธอดSelect()สาธารณะ
เยี่ยมมาก แต่เราจะได้รับสิ่งเหล่านี้ได้อย่างไร
การทดสอบนั่งร้าน
เริ่มจากด้านบนกันก่อน ข้อกำหนดพื้นฐานที่สุด — เราจะได้คลาส SalesTaxSelector ได้อย่างไร เราสามารถเขียน Unit Test อะไรที่เป็นไปได้ — และนี่คือจุดสำคัญ — เพื่อผลักดันเราให้นิยามSalesTaxSelector
การทดสอบนี้จะทำได้หรือไม่?
แค่นาทีเดียว นั่นจะไม่ทำงาน การทดสอบหน่วยจะไม่คอมไพล์ เราไม่มีคำจำกัดความสำหรับ SalesTaxSelector!
ความล้มเหลวในการคอมไพล์นี้ไม่สนับสนุนให้เราสร้างคลาส SalesTaxSelector หรือไม่
มันทำอย่างแน่นอน
ดังนั้น เมื่อเราเขียนคำจำกัดความของคลาสอย่างง่าย การทดสอบหน่วยที่ล้มเหลวจะผ่าน:
คุณจะสังเกตเห็นว่าเราสร้างเฉพาะการใช้งาน ซึ่งเป็นคำจำกัดความคลาสว่างสำหรับ SalesTaxSelector ตามที่ระบุไว้ในกฎข้อที่ 3 ของ "กฎสามข้อของ TDD"
ดังนั้น เพื่อให้เป็นไปตามกฎ TDD เราจำเป็นต้องมีการทดสอบหน่วยที่ผลักดันให้เราใช้ SalesTaxSelector คำจำกัดความ-a การทดสอบนั่งร้าน
อุตสาหกรรมการก่อสร้างใช้โครงที่เตรียมไว้เพื่อหล่อคอนกรีตที่เทจนแห้ง เมื่อคอนกรีตแข็งตัวแล้ว คนงานจะถอดนั่งร้านออก และโครงสร้างคอนกรีตก็จะมั่นคงแข็งแรง
ในทำนองเดียวกัน เราเพียงต้องการการทดสอบนั่งร้านเพื่อสร้างโครงสร้างพื้นฐานการเขียนโปรแกรมที่จำเป็น — คลาสหรือวิธีการ — หลังจากนั้น สิ่งเหล่านี้จะไม่มีประโยชน์สำหรับเราอีกต่อไป
ตกลง เราได้พบกับการทดสอบนั่งร้านสำหรับ . ลองใช้วิธีทดสอบหน่วยนั่งร้านเพื่อสร้าง SalesTaxSelector's Select() :
เป็นอีกครั้งที่การทดสอบหน่วยพบเราด้วยข้อผิดพลาดในการคอมไพล์สำหรับวิธี Select() ที่ไม่รู้จัก ซึ่งแก้ไขได้อย่างรวดเร็วโดยการนำเวอร์ชันพื้นฐานไปใช้กับ SalesTaxSelector ของเรา:
โปรดสังเกตว่าเรานำเสนอเมธอด Select() ในรูปแบบที่ง่ายที่สุดอย่างไร:
ข้อมูลเฉพาะการใช้งานที่จำเป็นของเมธอด Select() จะเป็นผลมาจากการทดสอบหน่วยเพิ่มเติม มีการทดสอบนั่งร้านเพื่อสร้างคำจำกัดความของคลาสและวิธีการสาธารณะ
นอกจากนี้ โปรดสังเกตว่าไม่มีการยืนยันในการทดสอบนั่งร้าน เราไม่ได้ทดสอบพฤติกรรมที่เป็นรูปธรรมเหมือนปกติกับการทดสอบหน่วย แต่ที่นี่เราต้องการเพียงสร้างคลาสและวิธีการโดยแก้ไขข้อผิดพลาดในการคอมไพล์ด้วยการใช้คลาสและเมธอด
สิ่งนี้จำเป็นหรือไม่?
เมื่อมองจากภายนอก การกำหนดการทดสอบ Scaffolding Tests จากนั้นทำให้พวกเขาผ่านด้วยคำจำกัดความของคลาสและวิธีเล็กๆ น้อยๆ ดูเหมือนจะเป็นการลงมือทำ ทำไมต้องกังวลกับการทดสอบนั่งร้านเมื่อเราเข้าใจคลาสหรือวิธีการที่เราต้องการกำหนด?
ฉันได้ยินคำคัดค้านเกี่ยวกับการทดสอบนั่งร้านตลอดเวลา นี่คือเหตุผลที่ฉันเก็บมันไว้:
หลีกเลี่ยงทางลาดลื่น
การเปลี่ยนจากการใช้ TDD ที่เข้มงวด ซึ่งเราปฏิบัติตามกฎสามข้ออย่างเคร่งครัด ดังนั้นการเขียนโค้ดการใช้งานทั้งหมดเฉพาะเมื่อเรามีการทดสอบที่ขาดเท่านั้น จึงเต็มไปด้วยปัญหา จากประสบการณ์ของผม ผู้ปฏิบัติงาน TDD ใหม่ๆ ที่ละทิ้งการทดสอบ Scaffolding มักจะกลับไปเขียนโค้ดมากเกินไปอย่างรวดเร็วโดยไม่มี Unit Test จนถึงจุดที่พวกเขาไม่ได้ฝึก TDD อีกต่อไป การใช้กฎสามข้ออย่างสม่ำเสมอและไว้วางใจกระบวนการ TDD มีแนวโน้มที่จะนำไปสู่ความสำเร็จของ TDD แทนที่จะมองหาทางลัด
บทสรุป
การทดสอบหน่วยที่ผลักดันให้เราสร้างคลาสภายใต้การทดสอบ และวิธีการสาธารณะเรียกว่าการทดสอบนั่งร้าน การทดสอบ TDD ประเภทเฉพาะนี้ช่วยให้เรายึดมั่นกับกฎที่เราไม่ควรเขียนโค้ด เว้นแต่ว่าเราจะมีการทดสอบที่ล้มเหลว การทดสอบนั่งร้านไม่ได้เข้ารหัสพฤติกรรมของโปรแกรมที่คาดหวัง ดังนั้นเราจึงสามารถลบออกได้เมื่อพวกเขาทำงานเสร็จแล้ว
หากคุณชอบบทความนี้ โปรดปรบมือให้ — และปรบมืออีกเยอะๆ หากคุณชอบ! :) ขอขอบคุณด้วยความกรุณา
เข้าร่วมรายชื่ออีเมลของฉันเพื่อเร่งรัดอาชีพวิศวกรซอฟต์แวร์ของคุณ
เมื่อลงชื่อสมัครใช้ คุณจะได้รับคำแนะนำของฉัน "เส้นทางสู่นักโปรแกรมเมอร์ระดับปรมาจารย์" ซึ่งมีแนวคิดอันทรงพลัง 3 ประการที่จะช่วยให้คุณย่นเส้นทางสู่การเป็นโปรแกรมเมอร์ผู้เชี่ยวชาญ
