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

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

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

บางคนแนะนำฉันว่าไม่จำเป็น

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

และมันมีประโยชน์น้อยมาก

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

พวกเขายังอ้างว่ามีเพียงไม่กี่ บริษัท ที่ทำการทดสอบหน่วยด้วยซอฟต์แวร์การผลิต

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

คุณใช้การทดสอบหน่วยที่งานของคุณหรือไม่และคุณได้อะไรจากการทดสอบนี้? (เช่นคุณภาพของรหัสที่ดีขึ้นลดเวลาในระยะยาว ฯลฯ )

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

ฉันทำ unittests แต่ไม่ทำงาน (หรือน้อย)

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

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

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

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

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

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

ฉันมักจะเคียงข้างกับเพื่อนร่วมงานของคุณ แต่ขึ้นอยู่กับจุดเท่านั้น

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

def add(x, y)
  x + y
end

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

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

1. เมื่อคุณกำลังทดสอบ
2. เมื่อคุณทำการดีบั๊ก
3. ในขณะที่คุณกำลังพัฒนาสิ่งที่ยุ่งยากจริงๆ

ลองผ่านแต่ละคนสมมติว่าคุณกำลังพัฒนาแอปพลิเคชันเว็บบางประเภท

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

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

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

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

Bottom line: การทดสอบหน่วยใช่แน่นอน แต่คุณควรใช้ฟังก์ชั่นการใช้งานขั้นพื้นฐาน - จนกว่าคุณจะต้องการใช้ในการดีบักหรือตรวจสอบให้แน่ใจว่าฟังก์ชั่นการทำงานที่มีขนดกบางอย่างทำงานได้อย่างถูกต้อง (รวมถึงในกรณีหลัง

รหัสทั้งหมดจะต้องผ่านการทดสอบ ไม่มีทางเลือกเกี่ยวกับเรื่องนั้น

รหัสที่ยังไม่ทดลองไม่ได้ผล: ไม่น่าเชื่อถือที่จะทำอะไร

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

การทดสอบหน่วยง่ายต่อการเขียนแก้จุดบกพร่องได้ง่ายขึ้นและง่ายต่อการจัดการ

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

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

การทดสอบมีผลบังคับใช้ การทดสอบระดับสูงทั้งหมดขึ้นอยู่กับหน่วยที่ใช้งานได้จริง

ทำให้การทดสอบหน่วยเป็นสิ่งจำเป็นอย่างมีเหตุผล ไม่มีทางเลือกอื่น

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

มันค่อนข้างง่าย: ถ้าคุณไม่สามารถแสดงให้เห็นว่าการทำงานของรหัส (และสิ่งที่วิธีที่ดีกว่าข้อกำหนดที่ปฏิบัติการในรูปแบบของการทดสอบ?) แล้วมันไม่ทำงาน

สิ่งนี้ทำให้ฉัน:

• ความสบายใจ: เซิร์ฟเวอร์ CI ของฉันบอกให้ฉันทราบว่า codebase ทั้งหมดทำงานได้ดี
• ความสามารถในการปรับปรุงรหัสของฉัน: ฉันสามารถปรับโครงสร้างรหัสของฉัน - refactor มัน - รู้ว่าหลังจากการปรับโครงสร้างฉันไม่เสียอะไรเลย

การทดสอบหน่วยเป็นวินัย เนื่องจากไม่จำเป็นสำหรับโค้ดในการทำงานจึงมักถูกทิ้ง

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

ฉันสงสัยว่าเพื่อนร่วมงานของคุณที่แนะนำไม่ให้ใช้ไม่ใช่โปรแกรม ถ้าอย่างนั้นเราก็จะบอกว่ามีไม่กี่คนที่ฉันให้คุณค่าสูงกว่าคนอย่างMartin FowlerหรือKent Beck ;)

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

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

การทดสอบหน่วยต้องใช้ภาษาที่เป็นมิตรการทดสอบการออกแบบหน่วยทดสอบที่เป็นมิตรและปัญหาที่เป็นมิตรทดสอบหน่วย

C ++ การออกแบบมัลติเธรดและ GUI จะเป็นฝันร้ายและความครอบคลุมของปัญหาจะน่ากลัว

.NET, แอสเซมบลี dll เธรดเดี่ยวที่ใช้ซ้ำได้, ตรรกะการคำนวณที่บริสุทธิ์จะเป็นเรื่องง่าย

คุ้มหรือไม่ฉันไม่สามารถพูดได้

คุณปรับโครงสร้างมากหรือไม่? คุณเห็น "ข้อบกพร่องที่โง่เขลา" เช่น "ออกไปทีละคน" ในโค้ดของคุณมากแค่ไหน?

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

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

ฉันขลุกอยู่ในการทดสอบหน่วยในโครงการจำลองบ้า ๆ บอ ๆ แต่ฉันไม่ได้หัวของฉันเกี่ยวกับ TDD / BDD เต็มรูปแบบเป่าและไม่มีที่ปรึกษาที่สามารถช่วยทำให้มันยากมากที่จะทำอย่างถูกต้อง

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

มันเป็นวิธีที่ดีในการค้นหาสิ่งที่พลาดในการตรวจสอบรหัส

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

เปรียบเทียบกับ 40+ นาทีสำหรับการทดสอบระบบอัตโนมัติระดับและชั่วโมง / วันสำหรับการทดสอบด้วยตนเอง แน่นอนการทดสอบหน่วยไม่ใช่การทดสอบเพียงอย่างเดียวที่คุณควรทำ แต่ในระดับโค้ดที่ละเอียดยิ่งขึ้นพวกเขาสามารถช่วยค้นหาข้อบกพร่องและทดสอบเคสขอบเหล่านั้นที่การทดสอบระบบ / การรวมระบบไม่สามารถสัมผัสได้ รหัสของเราจะต้องผ่านการทดสอบที่ครอบคลุมการตัดสินใจมากกว่า 75% และฟังก์ชั่นครอบคลุม 100% ซึ่งจะทำได้ยากมากหากไม่มีการทดสอบหน่วย

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

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

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

ค่าใช้จ่าย: โค้ดช้าลง, Learning Curve, Developer Inertia

ประโยชน์: โดยทั่วไปฉันพบว่าตัวเองเขียนโค้ดได้ดีขึ้นเมื่อฉันทดสอบครั้งแรก - ฉลาดพอสมควร ...

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

ฉันทำแบบทดสอบหน่วยงานเมื่อฉันมีโอกาสและพยายามโน้มน้าวให้เพื่อนร่วมงานทำแบบเดียวกัน

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

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

แนวทางของฉันสำหรับการทดสอบหน่วยคือ:

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

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

ส่วนที่ยากที่สุดคือการเขียนการทดสอบหน่วยที่ดี

มันเป็นมาตรฐานที่ดีสำหรับรหัสของคุณ