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

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

ตอนนี้ทุกอย่างผ่านไปและทุกอย่างสงบลงทุกคนตกลงที่จะเปลี่ยนเราให้เป็นทีมงานที่มีประสิทธิผลของ TDD / BDD ...

ตอนนี้คำถามเกี่ยวกับรหัสที่เรามีอยู่แล้ว: (1) มันยังไม่เป็นไรหรือเป็นความคิดที่ดีที่จะหยุดการพัฒนาส่วนใหญ่และเริ่มเขียนกรณีทดสอบที่เป็นไปได้ทั้งหมดตั้งแต่เริ่มต้นถึงแม้ว่าทุกอย่างจะทำงานได้อย่างสมบูรณ์ ? หรือ (2) เป็นการดีกว่าที่จะรอสิ่งที่ไม่ดีเกิดขึ้นจากนั้นในระหว่างการแก้ไขการทดสอบหน่วยการทดสอบใหม่หรือ (3) แม้กระทั่งลืมรหัสก่อนหน้าและเพียงแค่เขียนการทดสอบหน่วยสำหรับรหัสใหม่เท่านั้นและเลื่อนทุกอย่าง

มีไม่กี่ที่ดีและบทความที่เกี่ยวข้องเช่นนี้ ฉันยังไม่แน่ใจว่ามันคุ้มค่าหรือไม่ที่จะพิจารณาเรื่องนี้เพราะเรามีเวลา จำกัด และโครงการ / งานอื่น ๆ อีกมากมายกำลังรอเราอยู่

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

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

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

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

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

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

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

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

หากคุณไม่สามารถดูได้ว่าด้วยตัวของมันเองสามารถช่วยให้คุณบรรลุกำหนดเวลาได้เร็วขึ้นแสดงว่าคุณไม่พร้อมสำหรับการทำงานของ TDD คุณต้องฝึกฝนที่บ้าน

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

เป็นความคิดที่ดีหรือไม่ที่จะเขียนกรณีทดสอบที่เป็นไปได้ทั้งหมดหลังจากเปลี่ยนทีมเป็น TDD?

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

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

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

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

(2) ดีกว่าที่จะรอสิ่งที่ไม่ดีเกิดขึ้นจากนั้นในระหว่างการแก้ไขเขียนหน่วยทดสอบใหม่หรือ

(3) แม้แต่ลืมรหัสก่อนหน้าและเพียงแค่เขียนการทดสอบหน่วยสำหรับรหัสใหม่เท่านั้นและเลื่อนทุกอย่างไปยัง refactor ที่สำคัญต่อไป

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

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

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

มันยังคงเป็นไรหรือเป็นความคิดที่ดีที่จะหยุดการพัฒนาส่วนใหญ่และเริ่มเขียนกรณีทดสอบที่เป็นไปได้ทั้งหมดตั้งแต่ต้น [... ]?

รับรหัส¹แบบดั้งเดิมเขียนการทดสอบหน่วยในสถานการณ์เหล่านี้:

• เมื่อแก้ไขข้อบกพร่อง
• เมื่อ refactoring
• เมื่อเพิ่มฟังก์ชันการทำงานใหม่ให้กับรหัสที่มีอยู่

มีประโยชน์เช่นเดียวกับการทดสอบหน่วยการสร้างชุดทดสอบหน่วยที่สมบูรณ์สำหรับ¹รหัสฐานข้อมูลที่มีอยู่อาจไม่ใช่แนวคิดที่สมจริง พลังที่ผลักดันให้คุณส่งมอบในวันครบกำหนด พวกเขาไม่ให้เวลาคุณในการสร้างการทดสอบหน่วยที่เพียงพอในขณะที่คุณกำลังพัฒนา คุณคิดว่าพวกเขาจะให้เวลาคุณอย่างเพียงพอในการสร้างแบบทดสอบสำหรับ "โปรแกรมที่ใช้งานได้" หรือไม่?

¹ _{รหัสดั้งเดิมคือรหัสที่ไม่มีการทดสอบหน่วย นี่คือนิยาม TDD ของรหัสดั้งเดิม มันใช้แม้ว่ารหัสดั้งเดิมจะส่งมอบใหม่ [แม้ว่าหมึกยังไม่แห้ง]}

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

• ความครอบคลุมมากกว่า 30% (หรือที่เรียกว่าการทดสอบการรวมสองอย่าง): หากการทดสอบของคุณล้มเหลวมีบางอย่างผิดปกติ (หรือการทดสอบของคุณไม่สม่ำเสมอ) โชคดีที่การทดสอบเตือนคุณอย่างรวดเร็ว! แต่การเปิดตัวจะยังคงต้องมีการทดสอบด้วยตนเองอย่างกว้างขวาง
• ครอบคลุมมากกว่า 90% (ส่วนประกอบส่วนใหญ่มีการทดสอบหน่วยผิวเผิน): หากการทดสอบของคุณผ่านซอฟต์แวร์น่าจะดีที่สุด ชิ้นส่วนที่ยังไม่ผ่านการทดสอบนั้นเป็นเคสแบบขอบซึ่งใช้ได้กับซอฟต์แวร์ที่ไม่สำคัญ แต่การเปิดตัวจะยังคงต้องมีการทดสอบด้วยตนเอง
• ครอบคลุมฟังก์ชั่น / statement / branch / requirements สูงมาก: คุณใช้ชีวิตในความฝันของTDD / BDDและการทดสอบของคุณนั้นสะท้อนการทำงานของซอฟต์แวร์ของคุณได้อย่างแม่นยำ คุณสามารถปรับโครงสร้างด้วยความมั่นใจสูงรวมถึงการเปลี่ยนแปลงสถาปัตยกรรมขนาดใหญ่ หากการทดสอบผ่านซอฟต์แวร์ของคุณเกือบพร้อมแล้ว จำเป็นต้องมีการทดสอบควันด้วยตนเองบางอย่างเท่านั้น

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

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

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

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

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

อย่าเขียนการทดสอบสำหรับรหัสที่มีอยู่ มันไม่คุ้มค่า.

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

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

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

ในขณะเดียวกันก็ยังคงเป็นงานเขียนเขียนเหล่านี้เท่าที่ควรจะเขียนไว้ก่อน มันจะใช้เวลามากเพื่อประโยชน์เล็กน้อย

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

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

ใช้กับสิ่งที่คุณต้องการเปลี่ยนซึ่งเป็นส่วนปกติของกระบวนการ

การทดสอบเป็นวิธีหนึ่งในการสื่อสารความเข้าใจ

ดังนั้นเขียนการทดสอบสำหรับสิ่งที่คุณเข้าใจว่าควรเป็นจริง

คุณสามารถเข้าใจสิ่งที่ควรเป็นจริงเมื่อคุณทำงานกับมัน

ดังนั้นเขียนการทดสอบสำหรับรหัสที่คุณทำงานด้วยเท่านั้น

เมื่อคุณทำงานกับรหัสคุณจะได้เรียนรู้

ดังนั้นเขียนและเขียนการทดสอบซ้ำเพื่อจับสิ่งที่คุณได้เรียนรู้

ล้างและทำซ้ำ

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

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

สองตัวเลือก:

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

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

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

1. ยืนยันว่าการทดสอบสำเร็จ
2. ทำการเปลี่ยนแปลง
3. ยืนยันว่าการทดสอบยังคงประสบความสำเร็จ

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

ดังนั้นฉันขอแนะนำให้แบ่งงานเขียนทดสอบและการเปลี่ยนแปลงเพื่อหลีกเลี่ยงนักพัฒนาที่เสียสละคุณภาพหนึ่งสำหรับงานอื่น

แม้ว่าทุกอย่างจะทำงานได้อย่างสมบูรณ์โอเค (ยัง!)?

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

(3) แม้แต่ลืมรหัสก่อนหน้าและเพียงแค่เขียนการทดสอบหน่วยสำหรับรหัสใหม่เท่านั้นและเลื่อนทุกอย่างไปยัง refactor ที่สำคัญต่อไป

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

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

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

และเลื่อนทุกอย่างไปยังตัวสร้างสำคัญรายต่อไป

หากกำหนด refactor ที่สำคัญต่อไปคุณต้องเขียนการทดสอบ

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

สองเซ็นต์ของฉัน:

รอการอัปเกรดทางเทคนิคที่สำคัญไปยังระบบและเขียนการทดสอบแล้ว ... อย่างเป็นทางการด้วยการสนับสนุนของธุรกิจ

อีกวิธีหนึ่งสมมติว่าคุณเป็นร้าน SCRUM ปริมาณงานของคุณจะแสดงตามความสามารถและคุณสามารถจัดสรร% ของการทดสอบหน่วย แต่ ...

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

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