สิ่งที่เป็นรูปธรรมคือข้อดีของการทดสอบหน่วยที่เหมาะสมผ่านการทดสอบการใช้งานที่เรียกว่าการทดสอบหน่วย

โครงการที่ฉันกำลังทำอยู่นั้นมีการทดสอบแบบดั้งเดิมที่ไม่ได้ล้อเลียนอย่างถูกต้อง ด้วยเหตุนี้การพึ่งพาเพียงอย่างเดียวก็คือ EasyMock ซึ่งไม่สนับสนุนสถิตศาสตร์การก่อสร้างที่มีข้อโต้แย้ง ฯลฯ การทดสอบแทนอาศัยการเชื่อมต่อฐานข้อมูลและเช่น "รัน" การทดสอบ การเพิ่ม powermock เพื่อจัดการกับกรณีเหล่านี้กำลังถูกลดราคาลงเนื่องจากต้องมีการอัพเกรดโครงการที่มีอยู่เพื่อรองรับ (การอภิปรายอื่น)

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

• ทรัพยากร

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

• ความเชื่อถือได้

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

• บำรุงรักษาเพิ่มเติม

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

• เห็นพ้องด้วย

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

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

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

การทดสอบหน่วยที่ดีคือ (ต่อรหัสสะอาดและที่อื่น ๆ ):

• รวดเร็ว
• อิสระ
• ซึ่งทำซ้ำได้
• ตนเองการตรวจสอบ
• ทันเวลา

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

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

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

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

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

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

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

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

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