ฉันจะวาดเส้นแบ่งระหว่างการทดสอบหน่วยและการทดสอบการรวมได้อย่างไร พวกเขาควรจะแยกจากกัน?


11

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

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

วัตถุคำขอ HTTP ปลอม -> กรอบงาน MVC -> วัตถุตอบกลับ HTTP -> ตรวจสอบว่าการตอบสนองนั้นถูกต้อง

เพราะนี่เป็นสิ่งที่ทำได้โดยไม่ต้องใช้เครื่องมือพิเศษ (เบราว์เซอร์อัตโนมัติเป็นต้น) ฉันสามารถทำได้ด้วยกรอบการทดสอบตามปกติ (ฉันใช้ NUnit)

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


การทดสอบบูรณาการเกี่ยวข้องกับการทดสอบการใช้งานจริงมากกว่าหนึ่งรายการของส่วนประกอบของคุณด้วยกัน (การใช้งานจริงหมายถึงไม่มี mocks)
Kemoda

1
คำถามนี้เกี่ยวข้องกับการทดสอบและควบคุมคุณภาพ ดังนั้นฉันขอแนะนำให้โยกย้ายไปยังไซต์ที่เกี่ยวข้อง SQA บน Stack Exchange ( sqa.stackexchange.com )
dzieciou

@dzieciou ไม่รู้ด้วยซ้ำว่ามีอยู่จริง!
Earlz

คำตอบ:


19

การรวมกับการทดสอบหน่วย

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

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

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

ซึ่งหมายความว่าการรู้ว่าแบบจำลองนั้นถูกจัดเก็บจริงในฐานข้อมูลหรือหากมีการออกคำเตือนจริง ๆ หลังจากอัลกอริทึม X ล้มเหลว

การทดสอบพัฒนาขับเคลื่อน

ลองย้อนกลับไปดูการพัฒนาระบบขับเคลื่อนทดสอบ (TDD) มีหลายสิ่งที่ต้องคำนึงถึง

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

บูรณาการครั้งแรกกับบูรณาการครั้งสุดท้าย

การทดสอบการรวมเข้ากับวัฏจักร TDD ในหนึ่งในสองวิธี ฉันรู้จักคนที่ชอบเขียนก่อน พวกเขาเรียกการรวมการทดสอบการทดสอบแบบ end-to-end และกำหนดการทดสอบแบบ end-to-end เป็นการทดสอบที่ทดสอบเส้นทางทั้งหมดของ usecase ได้อย่างสมบูรณ์ กำลังตรวจสอบผลลัพธ์เอาต์พุต ฯลฯ ... ) จากนั้นพวกเขาเริ่มต้นด้วยการทดสอบหน่วยแรกของพวกเขาทำให้มันผ่านเพิ่มอีกหนึ่งวินาทีทำให้มันผ่าน ฯลฯ ... ช้าลงมากขึ้นเรื่อย ๆ ของการทดสอบบูรณาการรวมเช่นกันจนกว่าคุณสมบัติจะเสร็จสิ้น

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

ปฏิบัติการ

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

เรามักจะใช้ไฟล์ทดสอบหนึ่งไฟล์สำหรับหนึ่งคลาสโดยวิธีการ

แนะนำให้อ่าน

  1. การพัฒนาซอฟต์แวร์เชิงวัตถุโดยการทดสอบหนังสือเล่มนี้เป็นตัวอย่างที่ดีมากของวิธีการทดสอบการรวมระบบครั้งแรก
  2. ศิลปะแห่งการทดสอบหน่วยพร้อมตัวอย่างใน dot.netในการทดสอบหน่วยพร้อมตัวอย่างใน dot.net: D หนังสือดีมากเกี่ยวกับหลักการที่อยู่เบื้องหลังการทดสอบหน่วย
  3. Robert C. Martin บน TDD (บทความฟรี): อ่านบทความสองบทความแรกที่เขาลิงก์ด้วยเช่นกัน

2

สิ่งที่สำคัญในกลยุทธ์การทดสอบคือการครอบคลุมการทดสอบ - คือความสามารถในการแสดงให้เห็นว่าการทำงานทั้งหมดจะถูกทดสอบ

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

ฉันจะวาดเส้นแบ่งระหว่างการทดสอบหน่วยและการทดสอบการรวมได้ที่ไหน

การทดสอบการรวมกันนั้นง่ายกว่าเร็วกว่าและถูกกว่าวาดเส้นให้ไกลที่สุด ...

ฉันควรทดสอบทีละชั้น (มากที่สุดเท่าที่จะทำได้) ด้วยการทดสอบหน่วย?

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

ควรวางการทดสอบการรวมในโครงการทดสอบเดียวกันกับโครงการทดสอบหน่วยของฉันหรือไม่

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


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

0

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

ด้วยการทดสอบหน่วยฉันมักจะทดสอบหนึ่งคลาส (SUT) ในไฟล์

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.