การทดสอบพัฒนาขับเคลื่อนอย่างไร

15

ฉันมีประสบการณ์มากกว่า 2 ปีในการพัฒนาแอพพลิเคชั่น ในสองปีที่ผ่านมาแนวทางการพัฒนาของฉันมีดังต่อไปนี้

วิเคราะห์ข้อกำหนด
Identity Core องค์ประกอบ / วัตถุฟังก์ชันที่จำเป็น, พฤติกรรม, กระบวนการและข้อ จำกัด
สร้างคลาสความสัมพันธ์ระหว่างพวกเขาข้อ จำกัด เกี่ยวกับพฤติกรรมของวัตถุ & รัฐ
สร้างฟังก์ชั่นการประมวลผลด้วยข้อ จำกัด พฤติกรรมตามความต้องการ
ทดสอบแอปพลิเคชันด้วยตนเอง
หากความต้องการเปลี่ยนแปลงแก้ไของค์ประกอบ / ฟังก์ชั่นให้ทดสอบโปรแกรมด้วยตนเอง

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

แต่ปัญหาของฉันคือฉันไม่สามารถสร้างการทดสอบก่อนได้ แต่ฉันจะระบุส่วนประกอบและเพียงแค่เขียนการทดสอบสำหรับพวกเขาก่อนที่ฉันจะเขียนส่วนประกอบจริง ๆ คำถามของฉันคือ

ฉันทำถูกไหม? ถ้าไม่ใช่สิ่งที่ฉันต้องเปลี่ยนแน่นอน
มีวิธีใดที่คุณสามารถระบุได้ว่าแบบทดสอบที่คุณเขียนนั้นเพียงพอหรือไม่
เป็นการดีหรือไม่ที่จะทดสอบการเขียนสำหรับฟังก์ชั่นที่ง่ายมากซึ่งอาจเทียบเท่ากับ 1 + 1 = 2 หรือเป็นเพียงภาพซ้อนทับ?
มันเป็นการดีที่จะเปลี่ยนฟังก์ชั่นและตามการทดสอบว่ามีการเปลี่ยนแปลงข้อกำหนด?

— Yogesh
แหล่งที่มา

2

"ฉันกำลังระบุส่วนประกอบและเพียงแค่เขียนการทดสอบสำหรับพวกเขาก่อนที่ฉันจะเขียนส่วนประกอบจริง ๆ ": ฉันพบสิ่งที่ถูกต้อง: คุณต้องระบุสถาปัตยกรรมที่หยาบของระบบของคุณก่อนแล้วจึงเริ่มเขียนโปรแกรม ในระหว่างการเขียนโค้ด (TDD) คุณจะศึกษารายละเอียดของแต่ละองค์ประกอบและอาจพบปัญหาเกี่ยวกับสถาปัตยกรรมของคุณที่คุณสามารถแก้ไขได้ตลอดทาง แต่ฉันคิดว่ามันโอเคที่คุณจะไม่เริ่มการเข้ารหัสโดยไม่ต้องทำการวิเคราะห์ล่วงหน้า

— Giorgio

คุณสามารถดูการทดสอบหน่วย / การรวมอัตโนมัติโดยไม่ต้องทำการทดสอบTDD ทั้งสองมักสับสน แต่ก็ไม่เหมือนกัน

— Andres F.

19

ฉันทำถูกไหม? ถ้าไม่ใช่สิ่งที่ฉันต้องเปลี่ยนแน่นอน

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

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

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

ให้ไปของนิสัยที่เป็นเรื่องยาก ยากมากจริงๆ ดูเหมือนจะยากเป็นพิเศษสำหรับโปรแกรมเมอร์ที่มีประสบการณ์

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

กฎคือ:

เขียนการทดสอบใหม่หนึ่งการทดสอบที่เล็กที่สุดที่คุณสามารถชี้ไปในทิศทางของโซลูชันได้

เห็นมันล้มเหลว การรวบรวมความล้มเหลวนับเป็นความล้มเหลว

ทำให้การทดสอบจาก (1) การส่งผ่านโดยการเขียนรหัสการดำเนินการอย่างน้อยคุณสามารถในวิธีการทดสอบ

Refactor เพื่อลบการทำซ้ำและอื่น ๆ ตามที่จำเป็นในการปรับปรุงการออกแบบ เข้มงวดเกี่ยวกับการใช้การเคลื่อนไหวเหล่านี้:

คุณต้องการวิธีการใหม่ - รอจนกว่าจะถึงเวลาการทำให้ใหม่แล้ว ...สร้างวิธีการใหม่ (ไม่ใช่การทดสอบ) โดยทำอย่างใดอย่างหนึ่งต่อไปนี้และไม่ใช้วิธีอื่น:

ที่ต้องการ: ทำวิธีการแยกในรหัสการใช้งานที่สร้างขึ้นตาม (3) เพื่อสร้างวิธีการใหม่ในชั้นเรียนทดสอบหรือ

หากคุณต้อง: ย้ายรหัสการใช้งานตาม (3) ไปยังวิธีการใช้งานที่มีอยู่

คุณต้องการคลาสใหม่ - รอจนกว่าจะถึงเวลารีแฟคเจอริ่งแล้ว ...สร้างคลาสที่ไม่ได้ทดสอบเพื่อระบุปลายทางสำหรับวิธีการย้ายและไม่มีเหตุผลอื่น

เติมคลาสการใช้งานด้วยวิธีการโดยใช้วิธีการย้ายและไม่มีวิธีอื่น

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

เมื่อกลุ่มคนที่ดำเนินการบางอย่างเช่นแทคเกมนิ้วเท้า Tic ใช้หลอก TDD พวกเขามักจะจบลงด้วยการออกแบบที่คล้ายกันมากที่เกี่ยวข้องกับชนิดของบางBoardชั้นมี 3 × 3 อาร์เรย์ของIntegers และอย่างน้อยส่วนหนึ่งของโปรแกรมเมอร์จะได้เขียนคลาสนี้โดยไม่ต้องทำการทดสอบเพราะพวกเขา "รู้ว่าพวกเขาต้องการมัน" หรือ "ต้องการบางสิ่งบางอย่างในการเขียนการทดสอบ" แต่เมื่อคุณบังคับว่ากลุ่มเดียวกันจะใช้ TDD Boardเช่นถ้าคุณหมายความว่ามันพวกเขามักจะจบลงด้วยความหลากหลายของการออกแบบที่แตกต่างกันมากมักจะไม่จ้างอะไรได้จากระยะไกลคล้ายกับ

มีวิธีใดที่คุณสามารถระบุได้ว่าแบบทดสอบที่คุณเขียนนั้นเพียงพอหรือไม่

เมื่อพวกเขาครอบคลุมความต้องการทางธุรกิจทั้งหมด การทดสอบเป็นการเข้ารหัสข้อกำหนดของระบบ

เป็นการดีหรือไม่ที่จะทดสอบการเขียนสำหรับฟังก์ชั่นที่ง่ายมากซึ่งอาจเทียบเท่ากับ 1 + 1 = 2 หรือเป็นเพียงภาพซ้อนทับ?

คุณมีแบบย้อนกลับ: คุณไม่ได้เขียนการทดสอบสำหรับการใช้งาน คุณเขียนฟังก์ชันการทำงานสำหรับการทดสอบ หากฟังก์ชั่นที่จะได้รับการทดสอบผ่านจะกลายเป็นเรื่องไม่สำคัญมันเยี่ยมมาก! คุณเพียงแค่ทำตามข้อกำหนดของระบบและไม่ต้องทำงานหนักสำหรับมัน!

มันเป็นการดีที่จะเปลี่ยนฟังก์ชั่นและตามการทดสอบว่ามีการเปลี่ยนแปลงข้อกำหนด?

เลขที่วิธีอื่น ๆ รอบ หากความต้องการเปลี่ยนแปลงคุณเปลี่ยนการทดสอบที่สอดคล้องกับข้อกำหนดนั้นดูมันล้มเหลวจากนั้นเปลี่ยนรหัสเพื่อให้ผ่าน การทดสอบเสมอมาก่อน

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

— Jörg W Mittag
แหล่งที่มา

1

คำตอบที่ชัดเจนมากแน่นอน! จากมุมมองของภาคปฏิบัติกรอบการทดสอบที่ยืดหยุ่นและทรงพลังนั้นสนุกมากเมื่อฝึกซ้อม TDD ในขณะที่เป็นอิสระจาก TDD ความสามารถในการเรียกใช้การทดสอบโดยอัตโนมัติมีค่ามากในการดีบักแอปพลิเคชัน ในการเริ่มต้นกับ TDD โปรแกรมที่ไม่ใช่ interarctive (UNIX-style) อาจเป็นวิธีที่ง่ายที่สุดเนื่องจากสามารถใช้ case-case ทดสอบได้โดยเปรียบเทียบกับสถานะทางออกและผลลัพธ์ของโปรแกรมกับสิ่งที่คาดหวัง ตัวอย่างที่เป็นรูปธรรมของวิธีการนี้สามารถพบได้ในคลังน้ำมันของฉันสำหรับ OCaml

— Michael Le Barbier Grünewald

4

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

— Jim Clay

3

+1 คำตอบนั้นดีที่อธิบาย TDD ได้อย่างถูกต้อง อย่างไรก็ตามมันยังแสดงให้เห็นว่าทำไม TDD เป็นวิธีการที่มีข้อบกพร่อง: ต้องใช้ความคิดอย่างระมัดระวังและการออกแบบที่ชัดเจนโดยเฉพาะอย่างยิ่งเมื่อต้องเผชิญกับปัญหาอัลกอริทึม การทำ TDD "ในคนตาบอด" (ตามที่ TDD กำหนด) โดยแสร้งว่าไม่มีความรู้เกี่ยวกับโดเมนใด ๆ ที่จะนำไปสู่ความยากลำบากโดยไม่จำเป็นและสิ้นตาย ดูdebacle solver ที่น่าอับอายของSudoku (เวอร์ชั่นย่อ: TDD ไม่สามารถเอาชนะความรู้ในโดเมน)

— Andres F.

1

@AndresF .: ที่จริงแล้วโพสต์บล็อกที่คุณเชื่อมโยงกับดูเหมือนจะสะท้อนประสบการณ์ Keith ทำเมื่อทำ TDD ราวกับว่าคุณหมายถึงมัน: เมื่อทำ "หลอก -DDD" สำหรับ Tic-Tac-Toe พวกเขาเริ่มต้นด้วยการสร้างBoardชั้นเรียนด้วย อาร์เรย์ 3x3 ของints (หรืออะไรทำนองนั้น) ในขณะที่ถ้าคุณบังคับให้พวกเขาทำ TDDAIYMI พวกเขามักจะสร้าง mini-DSL เพื่อรวบรวมความรู้เกี่ยวกับโดเมน นั่นเป็นเพียงแค่เรื่องเล็ก ๆ น้อย ๆ แน่นอน การศึกษาทางสถิติและทางวิทยาศาสตร์น่าจะดี แต่ตามปกติแล้วการศึกษาเช่นนี้พวกเขามีขนาดเล็กเกินไปหรือแพงเกินไป

— Jörg W Mittag

@ JörgWMittagถูกต้องฉันถ้าฉันเข้าใจผิดคุณ แต่คุณกำลังบอกว่ารอนเจฟฟรีส์กำลังทำ "หลอก -DDD"? นั่นไม่ใช่รูปแบบของการเข้าใจผิดที่ "ไม่มีตัวตนที่แท้จริง" (ฉันเห็นด้วยกับคุณเกี่ยวกับความจำเป็นในการศึกษาทางวิทยาศาสตร์มากขึ้นบล็อกที่ฉันเชื่อมโยงกับเป็นเพียงเรื่องเล็ก ๆ ที่มีสีสันเกี่ยวกับความล้มเหลวอันน่าทึ่งของการใช้ TDD ที่เฉพาะเจาะจงโชคไม่ดีมันดูเหมือนว่าผู้เผยแพร่ศาสนา TDD ดังเกินไป ของเราจะมีการวิเคราะห์จริงของ metholody นี้และผลประโยชน์ที่ถูกกล่าวหา)

— Andres F.

5

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

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

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

— หมอบราวน์
แหล่งที่มา

3

ฉันทำถูกไหม? ถ้าไม่ใช่สิ่งที่ฉันต้องเปลี่ยนแน่นอน

คุณทำได้ดี

มีวิธีใดที่คุณสามารถระบุได้ว่าแบบทดสอบที่คุณเขียนนั้นเพียงพอหรือไม่

ใช่ใช้การทดสอบ / เครื่องมือที่ครอบคลุมรหัส Martin Fowler ให้คำแนะนำที่ดีเกี่ยวกับการครอบคลุมการทดสอบ

เป็นการดีหรือไม่ที่จะทดสอบการเขียนสำหรับฟังก์ชั่นที่ง่ายมากซึ่งอาจเทียบเท่ากับ 1 + 1 = 2 หรือเป็นเพียงภาพซ้อนทับ?

โดยทั่วไปแล้วฟังก์ชั่นวิธีการส่วนประกอบอื่น ๆ ที่คุณคาดหวังว่าจะได้ผลลัพธ์บางอย่างเนื่องจากอินพุตบางตัวเป็นตัวเลือกที่ดีสำหรับการทดสอบหน่วย อย่างไรก็ตามเช่นเดียวกับสิ่งส่วนใหญ่ในชีวิต (วิศวกรรม) คุณต้องพิจารณาการแลกเปลี่ยนของคุณ: ความพยายามชดเชยด้วยการเขียนการทดสอบหน่วยส่งผลให้รหัสฐานมีเสถียรภาพมากขึ้นในระยะยาว? โดยทั่วไปเลือกที่จะเขียนรหัสทดสอบสำหรับฟังก์ชั่นที่สำคัญ / สำคัญก่อน ในภายหลังหากคุณพบว่ามีข้อบกพร่องที่เกี่ยวข้องกับส่วนที่ไม่ได้ทดสอบของรหัสเพิ่มการทดสอบเพิ่มเติม

มันเป็นการดีที่จะเปลี่ยนฟังก์ชั่นและตามการทดสอบว่ามีการเปลี่ยนแปลงข้อกำหนด?

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

— miraculixx
แหล่งที่มา

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

— พอล

3

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

หากคุณมีปัญหาในการทดสอบการเขียนก่อนอื่นฉันขอแนะนำให้ทำเซสชั่นการเขียนโปรแกรมคู่กับคนที่มีประสบการณ์ใน TDD เพื่อให้คุณได้สัมผัสกับ "วิธีคิด" เกี่ยวกับวิธีการทั้งหมด

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

มีวิธีใดที่คุณสามารถระบุได้ว่าแบบทดสอบที่คุณเขียนนั้นเพียงพอหรือไม่

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

เป็นการดีหรือไม่ที่จะทดสอบการเขียนสำหรับฟังก์ชั่นที่ง่ายมากซึ่งอาจเทียบเท่ากับ 1 + 1 = 2 หรือเป็นเพียงภาพซ้อนทับ?

เห็นได้ชัดว่ามันขึ้นอยู่กับการตัดสินใจของคุณ ฉันไม่ต้องการเขียนการทดสอบเกี่ยวกับพารามิเตอร์การตรวจสอบ null หากวิธีการไม่ได้เป็นส่วนหนึ่งของ API สาธารณะ แต่ไม่เช่นนั้นทำไมคุณถึงไม่ยืนยันวิธีการที่ Add (a, b) ส่งคืน a + b แน่นอน?

มันเป็นการดีที่จะเปลี่ยนฟังก์ชั่นและตามการทดสอบว่ามีการเปลี่ยนแปลงข้อกำหนด?

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

— พอล
แหล่งที่มา