ฉันชื่อคำถามล้อเล่นเพราะฉันแน่ใจว่า "มันขึ้นอยู่กับ" แต่ฉันมีคำถามเฉพาะบางอย่าง
การทำงานในซอฟต์แวร์ที่มีการพึ่งพาในระดับลึกมาก ๆ ทีมของฉันคุ้นเคยกับการใช้การเยาะเย้ยอย่างกว้างขวางเพื่อแยกโมดูลรหัสแต่ละรายการออกจากการพึ่งพาที่อยู่ด้านล่าง
ดังนั้นฉันจึงประหลาดใจที่Roy Osheroveแนะนำในวิดีโอนี้ว่าคุณควรใช้การเยาะเย้ยเพียงบางอย่างเช่น 5% ของเวลา ฉันเดาว่าเรานั่งอยู่ระหว่าง 70-90% ฉันเคยเห็นคำแนะนำที่คล้ายกันเป็นครั้งคราวเช่นกัน
ฉันควรกำหนดสิ่งที่ฉันพิจารณาว่าเป็นสองหมวดหมู่ของ "การทดสอบการรวม" ซึ่งแตกต่างกันอย่างมากว่าพวกเขาควรได้รับชื่อต่างกัน: 1) การทดสอบระหว่างกระบวนการซึ่งรวมโมดูลรหัสหลายโมดูลและ 2) การทดสอบนอกกระบวนการ ไปยังฐานข้อมูลระบบไฟล์บริการบนเว็บ ฯลฯ มันเป็นประเภทที่ 1 ที่ฉันกังวลการทดสอบที่รวมโมดูลรหัสหลายโมดูลทั้งหมดในกระบวนการ
คำแนะนำของชุมชนส่วนใหญ่ที่ฉันได้อ่านแสดงให้เห็นว่าคุณควรเลือกการทดสอบแบบแยกหน่วยที่ละเอียดและละเอียดจำนวนมากและการทดสอบแบบรวมตั้งแต่ต้นจนจบแบบหยาบจำนวนเล็กน้อยเนื่องจากการทดสอบหน่วยจะให้ข้อเสนอแนะที่แม่นยำกับคุณ อาจมีการสร้างการถดถอย แต่การทดสอบแบบหยาบซึ่งยุ่งยากในการตั้งค่าจริงตรวจสอบการทำงานแบบ end-to-end ของระบบ
ได้รับสิ่งนี้ดูเหมือนว่าจำเป็นที่จะต้องใช้การเยาะเย้ยบ่อยครั้งเพื่อแยกรหัสหน่วยแยกเหล่านี้
รับโมเดลวัตถุดังนี้:
... ยังพิจารณาด้วยว่าความลึกของการพึ่งพาแอปพลิเคชันของเรานั้นลึกกว่าที่ฉันจะได้พอดีในภาพนี้เพื่อให้มีหลายเลเยอร์ N ระหว่าง 2-4 เลเยอร์และ 5-13 เลเยอร์
ถ้าฉันต้องการทดสอบการตัดสินใจเชิงตรรกะอย่างง่าย ๆ ในหน่วย # 1 และถ้าการอ้างอิงทุกครั้งถูกสร้างขึ้นในคอนสตรัคเตอร์โค้ดที่ขึ้นอยู่กับมันเช่นนั้นพูด 2 2 3 และ 4 ถูกสร้างคอนสตรัคชันในโมดูล 1 ใน ภาพฉันอยากฉีด mocks 2, 3 และ 4 ลงใน 1
มิฉะนั้นฉันจะต้องสร้างอินสแตนซ์ที่เป็นรูปธรรมของ 2, 3 และ 4 ซึ่งอาจยากกว่าการพิมพ์พิเศษบางอย่าง บ่อยครั้งที่ 2, 3 และ 4 จะมีข้อกำหนดด้านคอนสตรัคเตอร์ซึ่งท้าทายต่อการตอบสนองและตามกราฟ (และจากความเป็นจริงของโครงการของเรา) ฉันจะต้องสร้างอินสแตนซ์ของ N ถึง 13 ให้เป็นรูปธรรม 2, 3 และ 4
สถานการณ์นี้มีความท้าทายมากขึ้นเมื่อฉันต้องการ 2, 3, หรือ 4 ในการทำงานบางอย่างเพื่อให้ฉันสามารถทดสอบการตัดสินใจเชิงตรรกะอย่างง่ายใน # 1 ฉันอาจต้องเข้าใจและ "เหตุผลทางจิตใจเกี่ยวกับ" กราฟวัตถุ / ต้นไม้ทั้งหมดในครั้งเดียวเพื่อให้ได้ 2, 3, หรือ 4 เพื่อทำงานในวิธีที่จำเป็น บ่อยครั้งที่ดูเหมือนว่าทำ myMockOfModule2.Setup ได้ง่ายกว่า (x => x.GoLeftOrRight ()) ผลตอบแทน (ขวาใหม่ ()); เพื่อทดสอบว่าโมดูล 1 ตอบสนองอย่างที่คาดไว้เมื่อโมดูล 2 บอกว่าให้ไปทางขวา
ถ้าฉันจะทดสอบตัวอย่างที่เป็นรูปธรรมของ 2 ... N ... 13 ทั้งหมดการตั้งค่าการทดสอบจะมีขนาดใหญ่มากและซ้ำกันส่วนใหญ่ ความล้มเหลวในการทดสอบอาจไม่ได้ผลดีมากในการระบุตำแหน่งของความล้มเหลว การทดสอบจะไม่เป็นอิสระ ( ลิงค์สนับสนุนอื่น )
จริงอยู่ที่มันมักจะสมเหตุสมผลที่จะทำการทดสอบในระดับรัฐแทนที่จะใช้การโต้ตอบการทดสอบชั้นล่างเนื่องจากโมดูลเหล่านั้นไม่ค่อยมีการพึ่งพาใด ๆ เพิ่มเติม แต่ดูเหมือนว่าการเยาะเย้ยเป็นสิ่งจำเป็นโดยนิยามเพื่อแยกโมดูลใด ๆ ที่อยู่เหนือสุด
จากทั้งหมดนี้ทุกคนสามารถบอกสิ่งที่ฉันอาจหายไปได้ไหม เป็นทีมของเรามากเกินไป mocks หรืออาจมีข้อสันนิษฐานบางอย่างในแนวทางการทดสอบหน่วยทั่วไปที่ชั้นของการพึ่งพาในแอปพลิเคชันส่วนใหญ่จะตื้นพอที่จริง ๆ แล้วมันสมเหตุสมผลในการทดสอบโมดูลโค้ดทั้งหมดที่รวมเข้าด้วยกัน (ทำให้กรณีของเรา "พิเศษ") หรืออาจแตกต่างกันทีมของเราไม่ได้ จำกัด บริบทที่มีขอบเขตอย่างเพียงพอหรือไม่?
Or is there perhaps some assumption in typical unit testing guidance that the layers of dependency in most applications will be shallow enough that it is indeed reasonable to test all of the code modules integrated together (making our case "special")? <- นี่