การทดสอบหน่วยหรือการพัฒนาขับเคลื่อนทดสอบนั้นคุ้มค่าหรือไม่?

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

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

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

นอกจากนี้มีอะไรที่ทำให้ TDD ดีเป็นพิเศษสำหรับ Scrum หรือไม่?

คำตอบสั้น ๆ : แน่นอนในเชิงบวก

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

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

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

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

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

แหล่งที่มาของภาพ

การทดสอบหน่วยหรือการพัฒนาขับเคลื่อนทดสอบนั้นคุ้มค่าหรือไม่?

ใช่แล้ว ลุงบ๊อบ (โรเบิร์ตซีมาร์ติน) เล่าในงานนำเสนอ;

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

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

มีหลายสิ่งที่เขียนลงไป

1. คุณมีหน้าที่รับผิดชอบในการทำให้คุณสมบัตินั้นทำงานได้ เขียนทดสอบ แค่ทำมัน.
2. เมื่อใดที่จะแทนที่การทดสอบหน่วยด้วยการทดสอบการรวม

SCRUM, การทดสอบหน่วยและ TDD นั้นเกี่ยวข้องกันหรือไม่?

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

มีอะไรที่ทำให้ TDD ดีเป็นพิเศษสำหรับ SCRUM หรือไม่?

ขณะที่ผมบอกข้างต้นพวกเขาทำให้ชุดที่ดี ; ถ้าคุณเพิ่มบางการทดสอบอัตโนมัติเพื่อมันแล้วมันมีความพิเศษมากขึ้น

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

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

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

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

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

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

นอกจากนี้มีอะไรที่ทำให้ TDD ดีเป็นพิเศษสำหรับ SCRUM หรือไม่?

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

ผู้คนคิดว่ามันเป็นความพยายามพิเศษเพราะมันเป็นกิจกรรมที่ต้องทำล่วงหน้า สิ่งที่คุณสูญเสียในเวลานี้คุณจะได้รับในภายหลัง

เหตุผลของฉันสำหรับการทดสอบหน่วยรวมถึง:

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

ให้ความรู้สึกถึงความก้าวหน้า

เตือนคุณหากรหัสเปลี่ยนแปลงการส่งออกของส่วนอื่น ๆ ของรหัส ทำให้การปรับโครงสร้างทำได้ง่ายขึ้น

ให้ชั้นเอกสารเพิ่มเติม (โดยเฉพาะถ้าคุณแสดงความคิดเห็นการทดสอบของคุณอย่างถูกต้อง)

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

มีคนอื่นรวมอยู่ในโพสต์อื่นในหัวข้อนี้ มันคุ้มค่า

การทดสอบหน่วยหรือการพัฒนาขับเคลื่อนทดสอบนั้นคุ้มค่าหรือไม่?

ใช่แน่นอน (ดูคำตอบอื่น ๆ )

[เป็น] ความคิดที่ดีและคุ้มค่ากับความพยายามและเวลาจริงหรือ

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

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

หากรหัสนั้นมีอยู่แล้วโดยไม่มีการทดสอบหน่วยมักจะมีงานพิเศษมากมายในการเขียนการทดสอบหน่วยหลังจากนั้นเพราะรหัสนั้นไม่ได้ถูกเขียนขึ้นเพื่อการทดสอบที่ง่าย

หากคุณทำ TDD รหัสนั้นจะทดสอบได้ง่ายโดยอัตโนมัติ

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

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

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

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

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

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

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

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

สำหรับแนวทางแดง - เขียว - refactor เพื่อ TDD ฉันพบว่าน่าเบื่อเล็กน้อย แต่เพื่อตัวเขาเอง

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

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

จริงๆแล้วมีการทดสอบหนึ่งประเภทที่ฉันพบพบเป็นที่ยอมรับกันโดยทั่วไปและฉันเชื่อว่าในที่สุดก็ไร้ประโยชน์ การทดสอบบนพื้นฐานของ GUI ได้แก่ โดยใช้ซีลีเนียม, webdriver, watir หรือ arquillian นี่คือวิธีที่เราได้รับวงจรการสร้าง 7 ชั่วโมงมากกว่าการสร้างรอบ 5 นาทีในโครงการ TDD ของฉัน

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

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

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