โครงการของฉันต้องมีขนาดใหญ่แค่ไหนสำหรับฉันในการทดสอบหน่วย? [ปิด]

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

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

โครงการของคุณใหญ่พออยู่แล้ว

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

    class Simple {
        boolean reallySimple() {
            return true; // how do we make sure it doesn't change to false?
        }
    }


    class SimpleTest {
        void assertReallySimple() {
            // ensure reallySimple return value isn't changed unexpectedly
            UnitTestFramework.assertTrue(new Simple().reallySimple());
        }
    }

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

เท่าที่ฉันกังวลประโยชน์หลักของการทดสอบหน่วยคือ:

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

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

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

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

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

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

เวลาที่ผ่านมาผมพบว่าโพสต์ดี: ทำไมการทดสอบหน่วยเพิ่มความเร็วในการพัฒนา มันสามารถช่วยคุณตอบคำถามได้

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

ฉันมี "ศรัทธา"

นี่อาจเป็นเหตุผลที่สำคัญที่สุดที่หน่วยทดสอบจะเร่งการพัฒนาในบริบทขององค์กร

ฉันสามารถวางใจได้ว่าทุกอย่างยังใช้งานได้หากการทดสอบทั้งหมดผ่าน หากการทดสอบล้มเหลวพวกเขาจะชี้ให้เห็นอย่างชัดเจนถึงปัญหาที่วาง ...

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

Michael Feathers แนะนำในหนังสือเล่มหนึ่งของเขาสองวิธีในการทำงานกับการเปลี่ยนแปลงรหัส:

• แก้ไขและอธิษฐาน
• ครอบคลุมและปรับเปลี่ยน

ไม่สำคัญว่าฐานรหัสจะใหญ่ขนาดไหน

ตามKent Beckในคำตอบของเขาสำหรับคำถาม Stack Overflow การทดสอบหน่วยของคุณลึกแค่ไหน? คุณควรทดสอบโค้ดที่คุณมักจะผิด

ถ้าโดยทั่วไปฉันไม่ได้ทำผิดแบบ (เช่นการตั้งค่าตัวแปรที่ไม่ถูกต้องในนวกรรมิก) ฉันจะไม่ทดสอบมัน

ทำการทดสอบหน่วยเพื่อประหยัดเวลาและปรับปรุง:

• การติดตามบั๊ก
• การสร้างใหม่และ / หรือการเขียนโค้ดใหม่
• การทดสอบบูรณาการ
• การทดสอบการถดถอยเป็นต้น

มันจะต้องเขียนการทดสอบหน่วยสำหรับส่วนที่ค่อนข้างซับซ้อนของโปรแกรม

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

"ฉันควรทดสอบเครื่องนี้หรือไม่" โดยปกติสามารถตอบได้โดยการตอบคำถามต่อไปนี้: "เป็นสิ่งสำคัญที่ฟังก์ชั่นนี้ทำงานได้อย่างถูกต้องและเป็นสิ่งสำคัญที่ฉันจะต้องรู้ว่าเมื่อมันหยุดทำงานหรือไม่?"

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

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

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

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

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

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

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

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

TL; DRเวอร์ชัน:

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

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

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

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

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

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

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

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

ข้อความอ้างอิงจาก"รหัสสะอาด" ของ Robert C. Martin : "ถ้ามันเป็นเรื่องเล็กน้อยที่จะเขียนมันเป็นเรื่องง่ายที่จะทดสอบ" ดังนั้นจึงไม่มีข้อแก้ตัวที่จะข้ามการทดสอบสำหรับโปรแกรมระยะสั้นและเรื่องไร้สาระ

มันไม่ใช่เรื่องของขนาด - มันคือสิ่งที่คุณทำกับมัน (และอายุเท่าไหร่) หากฉันเรียนรู้วิธีการทำงานของเทคโนโลยีและวางแผนที่จะทิ้งสิ่งต่าง ๆ ออกไป (เราเรียกสิ่งนี้ว่า Sprum ใน Scrum) ฉันจะเขียนโค้ดโดยไม่ทำการทดสอบมากนัก หากคุณวางแผนที่จะพัฒนามันต่อไป (แม้ว่าคุณจะเป็นแค่เด็ก ๆ ) คุณควรเขียนการทดสอบรอบ ๆ รหัส TDD เป็นเทคนิคการออกแบบก่อนที่จะเป็นเทคนิคการทดสอบ คุณต้องการให้มีภาพที่ชัดเจนของสิ่งที่คุณต้องการให้รหัสทำก่อนที่จะผูกมัดในรายละเอียดของการดำเนินการ ฉันก็จะไม่ขอแนะนำให้พยายามเขียนการทดสอบหน่วยที่กว้างขวางเกี่ยวกับรหัสมรดกจำนวนมาก พยายามระบุชิ้นส่วนเหล่านั้นที่ซับซ้อน (มีความซับซ้อนสูง / รหัสสปาเก็ตตี้รู้สึกถึงพวกเขา) และชิ้นส่วนเหล่านั้นที่ล้มเหลวบ่อยครั้ง (พวกเขามักจะเหมือนกัน) อย่างที่คนอื่นแนะนำฉันจะไปอ่านหนังสือของ Kent Beck บน TDD และอ่านหนังสือของ Michael Feather อย่างแน่นอน สิ่งที่พวกเขาไม่ได้ครอบคลุมมากคือแง่มุมทางการเมืองในการเขียนบททดสอบหน่วยเกี่ยวกับรหัส นักพัฒนาหลายคนเกลียดที่จะต้องเปลี่ยนรหัสเพื่อให้สามารถทดสอบได้และนักพัฒนาจำนวนมากไม่รู้สึกว่าจำเป็นต้องทดสอบโค้ดเลย มันเป็นสิ่งที่เราต้องทำงานเป็นอาชีพ ทุกคนต้องมีวินัยวิศวกรรมวิศวกรรมเพื่อพิสูจน์ (มักคณิตศาสตร์) ว่างานของพวกเขาได้พบกับสเปค เราควรทำเช่นเดียวกัน

การผูกโปรเจคในขอบเขตของคลาสหรือฟังก์ชันการทำงานจากนั้นพิจารณาว่าสิ่งนี้เหมาะสมสำหรับการทดสอบหน่วยหรือไม่ มีประโยชน์มากมายของการทดสอบหน่วยแอปพลิเคชัน แต่ความงามที่แท้จริงเริ่มต้นเมื่อคุณต้องบำรุงรักษาแอปพลิเคชันหรือต้องทำงานในสภาพแวดล้อมแบบกระจาย ทางเลือกจึงมาที่นี่ แม้แต่การเปลี่ยนแปลงเล็กน้อยในรหัสของคุณอาจทำให้เกิดภัยพิบัติ
ฉันจะไม่แนะนำ 'การทดสอบหน่วย' เท่านั้น แต่ยังแนะนำให้ตรวจสอบความครอบคลุมโค้ดของคุณด้วยเพื่อให้มั่นใจว่าโค้ดของคุณครอบคลุมการทดสอบหน่วยสูงสุด เกณฑ์สำหรับความคุ้มครองรหัสจะต้องไม่น้อยกว่า95%และเป้าหมายต้องเป็นรอบ100% คุณสามารถใช้เครื่องมือในการติดตามการครอบคลุมรหัสของคุณและสร้างรายงาน
Visual Studio ให้ข้อมูลความครอบคลุม -http://msdn.microsoft.com/en-us/library/ms182496(v=vs.80).aspx
นอกจากนี้คุณยังสามารถใช้ NCover หรือ dotCover