การทดสอบแบบ End-to-end กับการทดสอบแบบยูนิตควรทำการทดสอบแยกกัน

23

ที่ บริษัท ของเราเรามักจะตรวจสอบให้แน่ใจว่าเราได้ทำการทดสอบแบบครบวงจรสำหรับเว็บไซต์ / แอพเว็บของเรา นั่นหมายความว่าเราเข้าถึง URL กรอกแบบฟอร์มส่งแบบฟอร์มไปยัง URL อื่นและตรวจสอบผลลัพธ์ของหน้า เราทำสิ่งนี้เพื่อทดสอบการตรวจสอบแบบฟอร์มทดสอบว่าเทมเพลต HTML มีตัวแปรบริบทที่ถูกต้อง ฯลฯ

นอกจากนี้เรายังใช้มันเพื่อทดสอบตรรกะพื้นฐาน

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

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

unit-testing tdd acceptance-testing

— รูดอล์ฟโอลาห์
แหล่งที่มา

6

was told by a co-worker that the reason for this is that we can rip out and change the underlying implementation at any point as long as the end-to-end tests pass.

- นั่นเป็นความจริงของการทดสอบหน่วย ฟังดูแล้วเหมือนกับว่าการทดสอบแบบ end-to-end นั้นถูกใช้เป็นข้อแก้ตัวสำหรับการไม่เขียนการทดสอบหน่วย

— Robert Harvey

12

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

— dietbuddha

2

@dietbuddha ฉันคิดว่าแนวคิดทั่วไปเป็นจริงของการทดสอบหน่วย แต่ในขอบเขต (หน่วย) ที่เล็กลง

— Sam

38

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

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

— Karl Bielefeldt
แหล่งที่มา

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

— Rudolf Olah

14

ฉันเห็นว่าการทดสอบหน่วยเป็นเรื่องที่มีค่าเป็นส่วนใหญ่เพราะพวกเขา จำกัด ปัญหาได้อย่างรวดเร็ว End-to-end มีคุณค่าเพราะพวกเขาให้ความมั่นใจว่าทุกอย่างทำงานร่วมกัน

— Jason Swett

20

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

— หมอบราวน์
แหล่งที่มา

2

ข้อความสั้น ๆ เกี่ยวกับถ้อยคำ; แม้ว่าจะไม่ใช่วิทยาศาสตร์ที่แน่นอน แต่หลายคนก็บอกว่าการทดสอบแบบครบวงจรและการทดสอบแบบรวมเป็นสิ่งที่แตกต่างกัน ดูstackoverflow.com/questions/4904096/…

— sbrattla

6

หลังจากอีกไม่กี่ปีของการเขียนโปรแกรมและทำงานในโครงการฉันจะให้คำตอบสำหรับคำถามของฉันเอง

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

หากคุณใช้เฟรมเวิร์กเช่น Django หรือ Rails (หรือคลาสที่คุณกำหนดเอง) คุณควรมีคลาสฟอร์มที่จะจัดการการตรวจสอบความถูกต้องของฟอร์ม คุณจะมีคลาสมุมมองที่แสดงเทมเพลตที่แสดงผลและแบบฟอร์มและจัดการคำขอ GET และ POST

ในการสิ้นสุดการทดสอบคุณจะ:

รับ URL
กรอกแบบฟอร์มด้วยข้อมูลที่ถูกต้อง
โพสต์ฟอร์มไปที่ url
ตรวจสอบเพื่อให้แน่ใจว่าฐานข้อมูลได้รับการปรับปรุงหรือมีการดำเนินการบางอย่างเนื่องจากรูปแบบที่ถูกต้อง

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

ลองอีกครั้งด้วยการทดสอบหน่วย:

ทดสอบวิธีการรับมุมมอง
ทดสอบวิธีการดู POST ด้วยแบบฟอร์มปลอม / จำลอง
ทดสอบแบบฟอร์มด้วยข้อมูลที่ถูกต้อง
ทดสอบแบบฟอร์มด้วยข้อมูลที่ไม่ถูกต้อง
ทดสอบผลข้างเคียงของแบบฟอร์ม

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

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

— รูดอล์ฟโอลาห์
แหล่งที่มา

จุดข้อมูลอื่นบล็อกการทดสอบของ Google บอกว่าไม่มีการทดสอบ end2end อีกต่อไป: googletesting.blogspot.ca/2015/04/…

— Rudolf Olah

5

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

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

— m3th0dman
แหล่งที่มา

1

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

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

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

— dietbuddha
แหล่งที่มา

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

— Rudolf Olah

@omouse: เพียงเพราะคุณไม่ได้เขียนการทดสอบหน่วยไม่มีเหตุผลที่จะไม่เขียนรหัสที่ดี อย่างไรก็ตามหากคุณมีโปรแกรมเมอร์ที่ไม่มีประสบการณ์หรือเพิ่งมีนิสัยที่ไม่ดีคุณก็จะได้รับผลประโยชน์ที่คุ้มค่า ไม่ว่าในกรณีใดคุณควรทำการวิเคราะห์และลดให้เป็นสมการง่ายๆ For Any Practice: Practice iff Benefit > Cost

— dietbuddha