ในฐานะนักพัฒนามืออาชีพจะยอมรับได้หรือไม่หากไม่เขียนการทดสอบหน่วย? [ปิด]

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

เพื่อทดสอบอะไร

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

ตอนนี้ในฐานะนักพัฒนาคุณต้องรู้วิธีการเขียนการทดสอบหน่วยและคุณต้องการที่ไหน

ทฤษฎี

มีความเข้าใจผิดกันว่าการทดสอบหน่วยมีการทดสอบ "หน่วย"
การทดสอบหน่วยเช่นเดียวกันทุกการทดสอบอื่น ๆ , ฟังก์ชั่นการทดสอบ ไม่มีอะไรสามารถทดสอบได้อีกแล้ว

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

ไม่รับประกันว่าทั้งระบบจะทำงานได้ แต่จะทำให้การทดสอบง่ายขึ้น

TDD ไม่ใช่ข้อกำหนดสำหรับตัวมันเอง มันทำให้การเข้ารหัสง่ายขึ้นโดยบังคับให้นักพัฒนาตอบคำถามแรก "ฉันจะใช้รหัสอะไรจริง ๆ "

ค่าใช้จ่าย

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

สมมติว่าคุณทำผิดพลาดในรหัสของคุณและตรวจจับและแก้ไขในวันเดียวกัน ค่าใช้จ่ายเป็น$ X
ลองสมมติว่าข้อผิดพลาดยังไม่ถูกตรวจจับและไปที่การสร้างภายในรายสัปดาห์ โชคดีที่ QA ตรวจพบยกข้อผิดพลาดในการติดตามข้อผิดพลาดปัญหาคือเรื่องของการสนทนา 5 นาทีในการประชุม 5 คน ฯลฯ ในที่สุดคุณแก้ไขมัน ค่าใช้จ่ายคือผลรวมของกำลังคนที่ใช้โดยทุกคนและอาจเป็น$ 3 * Xในกรณีนี้
ถ้าข้อผิดพลาดไปที่การทดสอบเบต้าและเกี่ยวข้องกับผู้คนมากขึ้น สมมติว่า$ 10 * X
หากไม่ได้รับการตรวจพบเป็นเวลานานให้ไปหาลูกค้า 1,000 ราย (หวังว่าจะไม่เป็นล้าน!) 10 คนตรวจพบพวกเขาพูดคุยกับเจ้าหน้าที่ฝ่ายสนับสนุนของคุณบางคนอาจเรียกเจ้านายของคุณว่าเพื่อนร่วมทีมของคุณพยายามทำซ้ำ ฯลฯ ฯลฯ ในที่สุดข้อบกพร่องจะกลับมาหาคุณและคุณจะแก้ไข ทั้งหมดเท่าไหร่? ดีกว่า$ 50 * X

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

ข้อดี

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

ของนักโทษ

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

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

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

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

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

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

แน่นอนคุณไม่ต้องการ "ไม่มีการทดสอบ" หากคุณเขียนการทดสอบหน่วยคุณอย่างน้อยรับรองว่ารหัสของคุณตรงกับการทดสอบของคุณ (แม้ว่าคุณจะต้องให้แน่ใจว่าการทดสอบของคุณตรงกับข้อกำหนดของคุณ)

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

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

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

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

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

ดังนั้นมันอาจเป็นฟังก์ชันของ

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

มีสถานการณ์มากมายที่ไม่สามารถเขียนการทดสอบหน่วยได้ ตอนนี้ TDD อยู่ที่ 'in' แต่ไม่ใช่กระสุนเงิน

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

misconception that Unit test finds bugsมีความเป็น นั่นไม่จริงสำหรับทุกกรณี การทดสอบหน่วยไม่เกี่ยวกับการค้นหาข้อบกพร่องหรือตรวจสอบการถดถอย examine each unit of your code separatelyมันเป็นโดยความหมาย แต่เมื่อแอปพลิเคชันของคุณทำงานได้จริงหน่วยทั้งหมดนั้นต้องทำงานร่วมกันและทั้งหมดนั้นซับซ้อนและบอบบางกว่าผลรวมของชิ้นส่วนที่ผ่านการทดสอบอย่างอิสระ

ดังนั้นเป้าหมายของการทดสอบหน่วย (ภายในกระบวนการ TDD) คือการออกแบบส่วนประกอบของซอฟต์แวร์ให้แข็งแกร่ง

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

ในฐานะนักพัฒนามืออาชีพจะยอมรับได้หรือไม่หากไม่เขียนการทดสอบหน่วย?

เลขที่

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

การทดสอบหน่วยเหล่านี้ควรละเอียดเพียงใด

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

หากคำตอบของคุณคือ 'ไม่' คุณควรสร้างการทดสอบหน่วยที่ดีกว่า (หรือการทดสอบ)
หากคำตอบของคุณคือ 'ใช่' แสดงว่ารหัสของคุณพร้อมสำหรับการยืนยันแล้ว

ในฐานะนักพัฒนามืออาชีพจะยอมรับได้หรือไม่ที่จะไม่ทำการทดสอบหน่วยโดยอัตโนมัติ ?

ใช่.

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

เน้น: ฉันไม่ได้บอกว่ามันเป็นไปไม่ได้ที่จะเขียนการทดสอบหน่วยอัตโนมัติสำหรับรหัส UI ฉันแค่บอกว่าจากประสบการณ์ของฉันบางครั้งมันก็ยากที่จะเขียนการทดสอบหน่วยอัตโนมัติสำหรับ รหัส UI บางอย่าง