การทดสอบหน่วยคืออะไร [ปิด]

ฉันเห็นคำถามมากมายถามว่า 'วิธี' การทดสอบหน่วยในภาษาเฉพาะ แต่ไม่มีคำถามถามว่า 'อะไร', 'ทำไม' และ 'เมื่อ'

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

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

• การรันการทดสอบจะกลายเป็นอัตโนมัติและสามารถทำซ้ำได้
• คุณสามารถทดสอบในระดับละเอียดมากกว่าการทดสอบจุดและคลิกผ่าน GUI

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

อีกวิธีในการดูการทดสอบหน่วยคือคุณเขียนการทดสอบก่อน สิ่งนี้เรียกว่าการพัฒนาทดสอบขับเคลื่อน (TDD สำหรับช่วงสั้น ๆ ) TDD นำข้อดีเพิ่มเติมมาให้:

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

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

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

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

ฉันไม่เห็นด้วยกับ Dan (ถึงแม้ว่าทางเลือกที่ดีกว่าอาจไม่ใช่คำตอบ) ... แต่ ...

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

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

1. ทำให้ง่ายขึ้นในการเปลี่ยนการใช้งานด้านเทคนิคในขณะที่แน่ใจว่าคุณจะไม่เปลี่ยนพฤติกรรม (ปรับโครงสร้างใหม่) โค้ดที่ถูกทดสอบหน่วยอย่างถูกต้องสามารถ refactored / ทำความสะอาดอย่างจริงจังกับโอกาสน้อยที่จะทำลายอะไรโดยไม่สังเกตเห็นมัน
2. ให้ความมั่นใจแก่ผู้พัฒนาเมื่อเพิ่มพฤติกรรมหรือทำการแก้ไข
3. เอกสารรหัสของคุณ
4. ระบุส่วนต่าง ๆ ของรหัสของคุณที่มีการจับคู่อย่างแน่นหนา มันยากที่จะทดสอบรหัสหน่วยที่คู่กันอย่างแน่นหนา
5. ระบุวิธีการใช้ API ของคุณและค้นหาปัญหาก่อน
6. ระบุวิธีการและชั้นเรียนที่ไม่เหนียวแน่นมาก

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

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

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

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

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

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

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

นี่เป็นข้อได้เปรียบหลักของการทดสอบหน่วยผ่านการทดสอบด้วยมือ แต่เดี๋ยวก่อนยังมีอีก:

• การทดสอบหน่วยสั้นลงห่วงข้อเสนอแนะการพัฒนาอย่างมาก: ด้วยแผนกทดสอบแยกต่างหากอาจใช้เวลาเป็นสัปดาห์เพื่อให้คุณรู้ว่ามีข้อผิดพลาดในรหัสของคุณตามเวลาที่คุณลืมบริบทมากแล้วจึงอาจใช้เวลาหลายชั่วโมงในการ ค้นหาและแก้ไขข้อบกพร่อง; OTOH พร้อมการทดสอบหน่วยรอบข้อเสนอแนะวัดได้ในไม่กี่วินาทีและโดยทั่วไปกระบวนการแก้ไขข้อบกพร่องจะเป็นไปตามเส้นของ "โอ้ดวลจุดโทษ * ฉันลืมตรวจสอบเงื่อนไขนั้นที่นี่" :-)
• หน่วยทดสอบเอกสารอย่างมีประสิทธิภาพ(ความเข้าใจของคุณ) พฤติกรรมของรหัสของคุณ
• การทดสอบหน่วยบังคับให้คุณประเมินทางเลือกการออกแบบของคุณใหม่ซึ่งส่งผลให้การออกแบบง่ายขึ้นและสะอาดขึ้น

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

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

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

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

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

การฝึกฝนเกี่ยวกับข้อดีเชิงปรัชญาของการทดสอบหน่วยและ TDD นี่คือบางส่วนของการสังเกต "หลอดไฟ" ที่สำคัญซึ่งทำให้ฉันเข้าสู่ขั้นตอนแรกที่ไม่แน่นอนของฉันบนถนนสู่การตรัสรู้ TDD (ไม่มีข่าวดั้งเดิมหรือจำเป็น) ...

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

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

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

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

5. ในทำนองเดียวกันนักออกแบบประเภทนี้สามารถดูสิ่งที่พวกเขากำลังทำอยู่ พวกเขาสามารถเดินไปเพื่อหยุดพักดื่มน้ำ / บุหรี่ / iphone แล้วกลับไปที่จอภาพที่ให้คิวภาพทันทีที่พวกเขาไปถึง TDD ให้สิ่งที่คล้ายกันกับเรา มันง่ายกว่าที่จะเห็นว่าเราไปถึงไหนเมื่อชีวิตเข้ามาแทรกแซง ...

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

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

งานนำเสนอนี้เป็นการแนะนำที่ยอดเยี่ยมสำหรับการทดสอบความดีที่อร่อยทุกอย่าง

ฉันอยากจะแนะนำหนังสือรูปแบบการทดสอบ xUnit โดย Gerard Meszaros มันมีขนาดใหญ่ แต่เป็นทรัพยากรที่ยอดเยี่ยมสำหรับการทดสอบหน่วย นี่คือลิงค์ไปยังเว็บไซต์ของเขาที่เขากล่าวถึงพื้นฐานของการทดสอบหน่วย http://xunitpatterns.com/XUnitBasics.html

ฉันใช้การทดสอบหน่วยเพื่อประหยัดเวลา

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

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

กรณีพิเศษทั้งหมดที่คุณคิดว่าเมื่อพัฒนารหัสสามารถบันทึกในรหัสในการทดสอบหน่วย การทดสอบหน่วยยังเป็นแหล่งตัวอย่างเกี่ยวกับวิธีใช้รหัส

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

สำหรับการทดสอบการเข้าถึงข้อมูลฉันพยายามเขียนการทดสอบที่ไม่มีการเปลี่ยนแปลงหรือล้างข้อมูลหลังจากนั้น

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

นี่คือสิ่งที่ฉันทำ ฉันจะบอกว่าการทดสอบหน่วยเป็นแนวปฏิบัติของการเขียนการทดสอบซอฟต์แวร์เพื่อตรวจสอบว่าซอฟต์แวร์จริงของคุณทำในสิ่งที่มันหมายถึง นี้เริ่มต้นด้วยjUnitในโลก Java และได้กลายเป็นวิธีที่ดีที่สุดใน PHP เป็นอย่างดีด้วยSimpleTestและPHPUnit เป็นแนวปฏิบัติหลักของ Extreme Programming และช่วยให้คุณมั่นใจได้ว่าซอฟต์แวร์ของคุณยังคงทำงานตามที่ตั้งใจไว้หลังจากทำการแก้ไข หากคุณมีการครอบคลุมการทดสอบที่เพียงพอคุณสามารถทำการรีแฟคเตอร์หลักแก้ไขข้อผิดพลาดหรือเพิ่มคุณสมบัติได้อย่างรวดเร็วโดยไม่ต้องกังวลกับปัญหาอื่น ๆ

จะมีประสิทธิภาพมากที่สุดเมื่อการทดสอบหน่วยทั้งหมดสามารถเรียกใช้โดยอัตโนมัติ

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

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

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

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

บรรณารักษ์เช่นNUnit , xUnitหรือJUnitนั้นจำเป็นถ้าคุณต้องการพัฒนาโครงการของคุณโดยใช้วิธีการTDD ที่ได้รับความนิยมโดย Kent Beck:

คุณสามารถอ่านรู้เบื้องต้นเกี่ยวกับการทดสอบขับเคลื่อนการพัฒนา (TDD)หนังสือหรือเคนท์เบ็คทดสอบขับเคลื่อนการพัฒนาตามตัวอย่าง

จากนั้นหากคุณต้องการให้แน่ใจว่าการทดสอบของคุณครอบคลุมส่วนที่ "ดี" ของรหัสของคุณคุณสามารถใช้ซอฟต์แวร์เช่นNCover , JCover , PartCoverหรืออะไรก็ได้ พวกเขาจะบอกเปอร์เซ็นต์ความครอบคลุมของโค้ดของคุณ ขึ้นอยู่กับว่าคุณเชี่ยวชาญใน TDD มากน้อยเพียงใดคุณจะรู้ว่าคุณฝึกฝนมาดีพอ :)

การทดสอบหน่วยเป็นการทดสอบหน่วยของรหัส (เช่นฟังก์ชั่นเดียว) โดยไม่จำเป็นต้องใช้โครงสร้างพื้นฐานที่หน่วยของรหัสนั้นต้องพึ่งพา คือทดสอบในการแยก

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

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

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

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

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

หน่วยส่วนหนึ่งของชื่อเป็นเรื่องเกี่ยวกับความตั้งใจที่จะทดสอบหน่วยเล็ก ๆ ของรหัส (วิธีการหนึ่งตัวอย่าง) ในเวลา

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

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

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

ฉันคิดว่าประเด็นที่คุณไม่เข้าใจคือกรอบการทดสอบหน่วยเช่น NUnit (และที่คล้ายกัน) จะช่วยคุณในการทดสอบขนาดเล็กและขนาดกลางโดยอัตโนมัติ โดยปกติคุณสามารถเรียกใช้การทดสอบใน GUI (เช่นในกรณีของNUnit ) โดยเพียงแค่คลิกปุ่มแล้ว - หวังว่า - ดูแถบความคืบหน้าเป็นสีเขียว หากเปลี่ยนเป็นสีแดงกรอบงานจะแสดงให้คุณเห็นว่าการทดสอบใดที่ล้มเหลวและสิ่งที่ผิดพลาดอย่างแน่นอน ในการทดสอบหน่วยปกติคุณมักใช้การยืนยันเช่นAssert.AreEqual(expectedValue, actualValue, "some description")- ดังนั้นหากทั้งสองค่าไม่เท่ากันคุณจะเห็นข้อผิดพลาดว่า "คำอธิบายบางอย่าง: คาดหวัง <คาดหวังคุ้มค่า> แต่เป็น <actualValue>"

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

ใช้Testivus สิ่งที่คุณต้องรู้อยู่ที่นั่น :)

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

xUnit , NUnit , mbUnitฯลฯ เป็นเครื่องมือที่ช่วยคุณในการเขียนการทดสอบ

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

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

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

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

ฉันไปที่งานนำเสนอในการทดสอบหน่วยที่ FoxForward 2007 และได้รับคำสั่งว่าอย่าทดสอบหน่วยใด ๆ ที่ทำงานกับข้อมูล ท้ายที่สุดถ้าคุณทดสอบข้อมูลสดผลลัพธ์จะไม่สามารถคาดเดาได้และถ้าคุณไม่ทดสอบข้อมูลจริงแสดงว่าคุณไม่ได้ทดสอบรหัสที่คุณเขียน น่าเสียดายที่การเข้ารหัสส่วนใหญ่ที่ฉันทำวันนี้ :-)

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

ฉันไม่ได้มาถึงจุดจบเพราะฉันต้องการ - กิจวัตรประจำวัน - ตอนนี้ - dammit แต่มันเป็นการออกกำลังกายที่ดี

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

เราจะทำการทดสอบหน่วยได้อย่างไร

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

ตอนนี้เรามีมากถึง 40% และเราสามารถเลือกผลไม้ที่แขวนต่ำได้เกือบทั้งหมด

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

นี่เป็นคำตอบว่าทำไมคุณควรทำการทดสอบหน่วย

วิดีโอ 3 รายการด้านล่างครอบคลุมการทดสอบหน่วยในจาวาสคริปต์ แต่หลักการทั่วไปมีผลกับทุกภาษา

การทดสอบหน่วย: นาทีตอนนี้จะประหยัดเวลาหลายชั่วโมงต่อมา - Eric Mann - https://www.youtube.com/watch?v=_UmmaPe8Bzc

การทดสอบหน่วย JS (ดีมาก) - https://www.youtube.com/watch?v=-IYqgx8JxlU

การเขียน JavaScript ที่สามารถทดสอบได้ - https://www.youtube.com/watch?v=OzjogCFO4Zo

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

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

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

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

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

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

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