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

132

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

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

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

คำถามคือเท่าไหร่เวลาที่แตกต่างกันจะเขียนรหัสทดสอบหน่วยผ่านรหัสไม่ได้ทดสอบและวิธีการที่แตกต่างเวลาที่ขยายขอบเขตโครงการขยาย?

unit-testing productivity solo-development

— ผัว
แหล่งที่มา

ความคิดเห็นไม่ได้มีไว้สำหรับการอภิปรายเพิ่มเติม การสนทนานี้ได้รับการย้ายไปแชท

— maple_shaft

8

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

— Tony Ennis

20

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

— RubberDuck

5

@RubberDuck มีจุดหนึ่งในโค้งของความซับซ้อนของโครงการที่วัดเป็นเวลาในการเขียนเทียบกับเวลาในการทดสอบโดยที่ "Wring it สองครั้ง" ใช้เวลาน้อยกว่า "เขียนและทดสอบมัน" ฉันคิดว่ามันอาจจะอยู่ที่ไหนสักแห่งในภูมิภาคของ bash oneliner

— Lyndon White

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

— JDługosz

149

การทดสอบในภายหลังของคุณจะมีค่าใช้จ่ายเพิ่มเติมในการเขียนการทดสอบ

อีกต่อไปข้อผิดพลาดชีวิตที่มีราคาแพงกว่าก็คือการแก้ไข

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

พระพุทธเจ้าทรงสอนภูมิปัญญาของทางสายกลาง การทดสอบเป็นสิ่งที่ดี มีสิ่งนั้นเป็นสิ่งที่ดีมากเกินไป กุญแจสำคัญคือสามารถบอกได้เมื่อคุณไม่สมดุล

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

รหัสทุกบรรทัดที่ไม่มีการทดสอบจะยากต่อการดีบักหรือเขียนใหม่อย่างมีนัยสำคัญ

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

ทุกข้อบกพร่องจะใช้เวลาในการแก้ไข

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

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

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

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

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

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

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

68

มีสิ่งดังกล่าวมากเกินไปของสิ่งที่ดีไม่ว่าคุณหรือพระพุทธเจ้าได้ทดสอบคุกกี้ของคุณยายของฉัน :-)

— Pierre Arlaud

3

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

— corsiKa

3

ฉันคิดว่านี่เป็นคำตอบที่สมดุลมาก: การทดสอบทุกอย่างแม้แต่เรื่องเล็ก ๆ น้อย ๆ อาจเสียเวลา การมีการทดสอบที่ดีสำหรับชิ้นส่วนที่ซับซ้อนที่สามารถแตกหักได้ง่ายสามารถช่วยได้จริงๆ ฉันเพิ่งย้ายพอร์ตโครงการขนาดเล็ก แต่ไม่สำคัญจาก Java ไปยัง C ++ ตอนแรกที่ฉันทำการทดสอบและสิ่งนี้ทำให้ฉันตั้งค่าการใช้งาน C ++ ทั้งหมด เมื่อการทดสอบทั้งหมดเป็นสีเขียวจะต้องมีการย้ายคลาสที่ง่ายขึ้นเพียงไม่กี่คลาสและมันก็ค่อนข้างราบรื่น ในทางตรงกันข้ามฉันไม่ได้ทำการทดสอบสำหรับรหัสทั้งหมด: นี้จะมีการดำเนินการเป็นเวลานานอย่างน้อย 3, 4 วันด้วยกำไรน้อย

— Giorgio

5

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

— Tony Suffolk 66

6

@ TonySuffolk66 คุณถูกต้องมันเป็นคุณสมบัติการทำงานที่จ่ายเงิน (ยกเว้นยอดขาย flimflam) อย่างไรก็ตามผู้คนกำลังสร้างคุณลักษณะการทำงานมานานก่อนที่ TDD จะเป็นเรื่อง พวกเขาจะหายไปนาน โปรดจำไว้ว่า TDD เป็นวิธีการทดสอบที่มีระเบียบวินัย มันไม่ได้เป็นวิธีเดียวในการทดสอบ

— candied_orange

112

ฉันเห็นด้วยกับคำตอบที่เหลือ แต่เพื่อตอบคำถามต่าง ๆ ของเวลาโดยตรง

Roy OsheroveในหนังสือของเขาThe Art of Unit Testing, Second Editionหน้า 200 ได้ศึกษากรณีของการดำเนินโครงการขนาดใกล้เคียงกันกับทีมที่คล้ายกัน (ทักษะฉลาด) สำหรับลูกค้าสองรายที่แตกต่างกันซึ่งทีมหนึ่งทำการทดสอบในขณะที่อีกอันไม่ได้ทำ

ผลลัพธ์ของเขาเป็นเช่นนั้น:

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

— อากิ
แหล่งที่มา

32

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

— JimmyJames

7

@JimmyJames เป็นกรณีศึกษาซึ่งมีการใช้อย่างกว้างขวางในธุรกิจและวิทยาศาสตร์เป็นอย่างมากเมื่อมันยังไม่เป็นไปได้ที่จะทำการทดลองที่มีขนาดใหญ่ มีวารสารจิตวิทยาที่เต็มไปด้วยพวกเขา "Unscientific" ไม่ใช่คำที่ถูกต้อง

— djechlin

25

ทำไมฉันถึงคิดว่าถ้าผลลัพธ์ของกรณีศึกษาแสดงตรงกันข้ามมันจะไม่ทำให้มันกลายเป็นหนังสือ ;-)?

— Doc Brown

11

@DocBrown ฉันสงสัยว่ามีกรณีศึกษาจำนวนเท่าใดที่ถูกสร้างขึ้นและถูกยกเลิกไปก่อนที่พวกเขาจะพบคำตอบที่ถูกต้อง :-)

— gbjbaanb

6

@JimmyJames ที่เกือบจะมีคุณสมบัติเป็นวิทยาศาสตร์อย่างแน่นอน นอกจากนี้นักวิทยาศาสตร์คนอื่นอาจอ่านกรณีศึกษา "n = 1" ตัดสินใจว่ามันคุ้มค่าที่จะศึกษามากกว่านี้จากนั้นทำการศึกษาทางสถิติขนาดใหญ่หรือแม้แต่การทดลองที่ควบคุมระยะยาวและยืนยันหรือปฏิเสธ นั่นเป็นวิธีการทางวิทยาศาสตร์ นั่นเป็นวิธีที่มันควรจะทำงาน คุณสามารถอ่านเพิ่มเติมเกี่ยวกับวิธีการทำงานของวิทยาศาสตร์ที่นี่en.wikipedia.org/wiki/Scientific_method

— djechlin

30

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

ผลของการศึกษาคือการเพิ่มเวลาในการพัฒนาระหว่าง 15% -35% (ซึ่งไม่มีที่ไหนเลยใกล้กับตัวเลข 2x ที่นักวิจารณ์ TDD อ้างถึงบ่อยครั้ง) และการลดลงของความหนาแน่นข้อบกพร่องก่อนปล่อยจาก 40% –90% (! ) โปรดทราบว่าทุกทีมไม่เคยมีประสบการณ์เกี่ยวกับ TDD มาก่อนดังนั้นเราสามารถสันนิษฐานได้ว่าการเพิ่มขึ้นของเวลาอย่างน้อยก็สามารถนำมาประกอบกับการเรียนรู้ได้และจะลดลงไปอีกเมื่อเวลาผ่านไป แต่นี่ไม่ใช่การประเมินโดยการศึกษา

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

— Jörg W Mittag
แหล่งที่มา

1

มันจะน่าสนใจมากขึ้นที่จะกำหนดข้อ จำกัด เพิ่มเติม: ไม่มีสถานะที่ไม่แน่นอน, ดังต่อไปนี้ SOLID, การพิมพ์แบบคงที่, ไม่ต้องพึ่งพาnull, การทำงานมากกว่าความจำเป็น, สัญญารหัส, การวิเคราะห์แบบคงที่, การวิเคราะห์แบบคงที่ ของการทดสอบหน่วยจะลดลง (แต่ไม่หายไป)

— Den

24

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

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

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

และแน่นอนหลังจากนั้นมันมักจะใช้เวลาสองสามรอบการเดินทางเพื่อให้ถูกต้องจริง

ทีนี้ถ้าฉันใช้การทดสอบหน่วย จากนั้นกระบวนการจะมีลักษณะดังนี้:

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

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

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

— Winston Ewert
แหล่งที่มา

1

และการใช้บางอย่างเช่น nCrunch สามารถตัดขั้นตอนที่ 2 และ 4 ทำให้ลูปข้อเสนอแนะแน่นยิ่งขึ้น

— ร่าเริง

"ฉันยังคงต้องเรียกใช้โปรแกรมประยุกต์ด้วยตนเอง" เป็นข้อสังเกตที่สำคัญ IMHO ไม่มีกระสุนเงิน

— Den

20

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

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

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

http://rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste.pdf

— Jared Smith
แหล่งที่มา

1

ฉันไม่คุ้นเคยกับ BDD มากนัก แต่จะเดาได้ว่ามันทำงานที่หยาบเล็กน้อยกว่าระดับวิธีการ / ฟังก์ชั่นและอาจมีการเชื่อมต่อกับค่าผู้ใช้น้อยลง

— Jared Smith

1

ที่เกี่ยวข้อง

— Robbie Dee

9

"การทดสอบเพื่อประโยชน์ในการทดสอบ (การทดสอบเล็กน้อยหรือการทดสอบซ้ำซาก) หรือการใช้การชี้วัดตามอำเภอใจ (เช่นการครอบคลุมโค้ด) เป็นการเขียนโปรแกรมสินค้า - ลัทธิ" จริงและเป็นอย่างดีกล่าว ทดสอบในแบบที่คุณรู้สึกเหมือนเป็นคนเลว - คิดว่าตัวเองเป็น ... สายลับนักกีฬาชั้นยอด ... อย่าทดสอบเหมือน "แผนกรัฐบาล" คุณรู้?

— Fattie

2

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

— Jared Smith

2

ฉันก็จะบอกว่าการทดสอบให้มูลค่าทางธุรกิจโดยประมาณ (แม้ว่าจะไม่ถูกต้อง) เมื่อใดก็ตามที่พวกเขาล้มเหลวและความละเอียดคือการปรับปรุงรหัสภายใต้การทดสอบ ดังนั้นหากคุณกำลังใช้ TDD ที่เกิดขึ้นโดยอัตโนมัติอย่างน้อยหนึ่งครั้งต่อการทดสอบ การทดสอบตามนิยามโดยนิยามไม่สามารถล้มเหลวและไร้ประโยชน์เช่นนั้น สำหรับการทดสอบแบบ "เล็กน้อย" - การทำงานกับ Java TCK ในช่วงต้น ๆ ของอาชีพของฉันฉันไม่แปลกใจอีกต่อไปว่าการทดสอบเล็ก ๆ น้อย ๆ เป็นไปได้ที่จะล้มเหลวเมื่อนำ API มาใช้ใหม่ตั้งแต่ต้น ;-) แต่มูลค่าทางธุรกิจคือ เกือบทุกคำทำนายแบบฮิวริสติกนัลก็เช่นกัน "ตามอำเภอใจ" เช่นกัน

— Steve Jessop

9

ขึ้นอยู่กับบุคคลรวมถึงความซับซ้อนและรูปร่างของรหัสที่คุณใช้งานด้วย

สำหรับฉันในโครงการส่วนใหญ่การเขียนการทดสอบหน่วยหมายความว่าฉันจะทำงานให้เสร็จเร็วขึ้นประมาณ 25% ใช่รวมถึงเวลาที่จะเขียนแบบทดสอบ

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

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

7

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

— sara

1

@kai - +1 ฉันใช้เวลาหลายสัปดาห์อ่านเกี่ยวกับ TDD ก่อนที่ฉันจะลอง ฉันอ่านทุกอย่างที่ฉันสามารถหาได้ ฉันอ่านหนังสือ. ฉันอ่านตัวอย่างที่รู้จักกันดีทั้งหมดของบล็อกเปรียว ฉันอ่านxUnit Test Patterns cover-to-cover ในช่วงสองสามสัปดาห์แรกฉันยังต้องใช้เวลานานถึงสองเท่า

— จูลส์

2

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

— duffymo

@kai: ด้วยเหตุผลที่คล้ายกันผู้คนจำนวนมากไม่สามารถสัมผัสได้ พวกเขาลองมันครั้งเดียวและหลังจากผ่านไปหนึ่งชั่วโมงก็ยังไม่ได้พิมพ์เร็วกว่าก่อน ;-)

— Steve Jessop

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

— sara

4

คำถามคือเท่าไหร่เวลาที่แตกต่างกันจะเขียนรหัสทดสอบหน่วยผ่านรหัสไม่ได้ทดสอบและวิธีการที่แตกต่างเวลาที่ขยายขอบเขตโครงการขยาย?

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

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

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

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

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

คำถามที่ดีกว่าอาจเป็น:

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

การเรียนรู้เป็นกระบวนการสองขั้นตอน: เรียนรู้ที่จะทำมันให้ดีพอจากนั้นเรียนรู้ที่จะทำมันเร็วขึ้น

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

3

บางแง่มุมที่ต้องพิจารณาไม่ได้กล่าวถึงในคำตอบอื่น ๆ

ผลประโยชน์พิเศษ / ค่าใช้จ่ายเพิ่มเติมขึ้นอยู่กับประสบการณ์ด้วยการเขียน unittests
- กับโครงการทดสอบหน่วยแรกของฉันค่าใช้จ่ายเพิ่มขึ้นเป็นสามเท่าเพราะฉันต้องเรียนรู้มากและทำผิดพลาดมากมาย
- หลังจาก 10 ปีของประสบการณ์กับ tdd ฉันต้องการเวลาในการเขียนโค้ดเพิ่มอีก 25% ในการเขียนการทดสอบล่วงหน้า
ด้วย tdd-moduls มากขึ้นยังคงต้องการการทดสอบด้วยตนเอง - gui และการรวมเข้าด้วยกัน
tdd จะทำงานเมื่อดำเนินการตั้งแต่ต้น
- การใช้ tdd กับโครงการที่มีอยู่แล้วที่ปลูกอยู่นั้นมีราคาแพง / การแพร่กระจาย แต่คุณสามารถใช้การทดสอบการถดถอยแทน
การทดสอบอัตโนมัติ (unittests และการทดสอบประเภทอื่น ๆ ) จำเป็นต้องใช้ const maintanace เพื่อให้ทำงานได้
- มีการสร้างการทดสอบผ่านการคัดลอกและวางสามารถทำให้ testcode-maintanace มีราคาแพง
- ด้วยรหัสการทดสอบประสบการณ์ที่เพิ่มขึ้นจะกลายเป็นแบบแยกส่วนและง่ายต่อการบำรุงรักษามากขึ้น
ด้วยประสบการณ์ที่เพิ่มขึ้นคุณจะได้รับความรู้สึกเมื่อมันคุ้มค่าที่จะสร้างการทดสอบอัตโนมัติและเมื่อไม่
- ตัวอย่างไม่มีประโยชน์มากนักสำหรับผู้ได้รับ / setters / wrapper ง่าย ๆ
- ฉันไม่เขียนการทดสอบอัตโนมัติผ่านทาง gui
- ฉันดูแลว่านักธุรกิจสามารถทำการทดสอบได้

สรุป

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

หมายเหตุ: ด้วย "การทดสอบหน่วย" ฉันหมายถึง "การทดสอบตัวแยกแบบแยก"

หมายเหตุ: ด้วย "การทดสอบการถดถอย" ฉันหมายถึง

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

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

ต้องการการพิสูจน์อักษร (เทียบเท่าวรรณกรรมของการทดสอบ?)

— JDługosz

3

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

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

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

เริ่มช้า สร้างความคล่องแคล่วก่อนตัดสินใจ คุณสามารถหยุด

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

3

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

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

ฉันจะบอกว่าการทดสอบนั้นดี แต่ให้แน่ใจว่าคุณทดสอบเร็วและทดสอบว่ากำไรนั้นดีแค่ไหน

— Arthur Havlicek
แหล่งที่มา

1

"ฉันควรพัฒนาโมดูลทดสอบสำหรับ VBA จริง ๆ หรือไม่" เจ้ากรรมใช่คุณควร rubberduckvba.com/Features#unitTesting

— RubberDuck

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

— Arthur Havlicek

คะแนนยุติธรรมทั้งหมด @ArthurHavlicek

— RubberDuck

2

การทดสอบการเขียนยังเป็นเรื่องเล็กน้อยใน VBA มีคุณสมบัติแฟนซีทั้งหมดที่กรอบบาง unittest มี? มันยากกว่า แต่การรันโปรแกรมที่เรียกmainTest()ว่าโมดูลการทดสอบทั้งหมดของคุณนั้นไม่ได้ยากขนาดนั้น

— enderland

1

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

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

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

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

— Robbie Dee
แหล่งที่มา

สิ่งที่อยู่ในประโยคแรกของคุณเรียกว่าการทดสอบการถดถอย

— cat

0

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

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

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

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

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

— คริสเตียนซาวเออร์
แหล่งที่มา

0

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

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

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

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

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