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

ฉันกำลังถกหน่วย / บูรณาการทดสอบกับเพื่อนร่วมงานและเขาทำกรณีที่น่าสนใจกับการเขียนการทดสอบหน่วย ฉันเป็นผู้ทดสอบหน่วยใหญ่ (JUnit เป็นหลัก) ผู้เสนอ แต่ฉันสนใจที่จะรับฟังผู้อื่นในขณะที่เขาทำประเด็นที่น่าสนใจ

เพื่อสรุปคะแนนของเขา:

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

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

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

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

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

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

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

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

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

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

เวลาที่ใช้ดีกว่าในการทดสอบการรวมที่ครอบคลุมกรณีการใช้งานซึ่งทำให้การทดสอบที่มีขอบเขตน้อยกว่ามีความสำคัญน้อยลง / ไม่มากเลย

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

ฉันไม่รู้ว่าฉันยอมรับข้อโต้แย้งของเพื่อนร่วมงานของคุณ

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

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

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

หากคุณต้องการได้รับที่เหมาะสมยิ่งและปรัชญามีทรัพยากรที่ดีมากมาย:

• การทดสอบของ Ian Bicking ถือว่าเป็นอันตราย (การทดสอบไม่เพียงพอการทดสอบไม่ทำให้โค้ดสวยงาม)
• การครอบคลุมรหัสที่เพิ่มขึ้นของ Dan Manges อาจเป็นอันตราย (การใช้ความครอบคลุมโค้ดเนื่องจากเมตริกไม่ได้บอกคุณว่าคุณกำลังทำสิ่งที่มีประโยชน์หรือไม่)
• ถ้าอย่างนั้นมีข้อโต้แย้งที่ดีที่ไม่เขียนการทดสอบหน่วย? [ปิด]จาก Stack Overflow (ความมั่นใจมากเกินไปค่าใช้จ่ายไม่เป็นที่รู้จักไม่พบข้อบกพร่องร้ายกาจไม่สามารถแทนที่รหัสที่สวยงาม [kinda like Bicking] ฯลฯ ... )

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

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

การทดสอบหน่วยมีแนวโน้มที่จะแสดงความคิดเห็นมากกว่าทำใหม่

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

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

ฉันพยายามปรับโครงสร้างและการเปลี่ยนแปลงการทำงานแยกกันอยู่เสมอ เมื่อฉันต้องทำทั้งสองอย่างฉันมักจะทำ refactoring ก่อน

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

อ้างถึงคะแนนที่เพื่อนของคุณทำ:

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

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

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

ฉันคิดได้เพียงข้อโต้แย้งเดียวกับการทดสอบหน่วยและมันก็ค่อนข้างอ่อนแอ

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

อย่างไรก็ตาม: มีค่าใช้จ่ายเล็กน้อยในการเขียนแบบทดสอบตั้งแต่แรก

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