คำถามติดแท็ก unit-testing

ฉันอ่านข้อความในบล็อกเมื่อเช้านี้และพบสิ่งนี้ : ถ้าคลาสเดียวที่ใช้อินเทอร์เฟซลูกค้าคือ CustomerImpl คุณไม่มีความหลากหลายและความสามารถในการสับเปลี่ยนได้จริง ๆ เนื่องจากไม่มีวิธีใดที่จะทดแทน runtime ได้เลย มันเป็นเรื่องธรรมดาทั่วไป นั่นเป็นเหตุผลสำหรับฉันเมื่อการใช้งานอินเทอร์เฟซเพิ่มความซับซ้อนและหากมีเพียงการใช้เพียงครั้งเดียวอย่างใดอย่างหนึ่งอาจยืนยันว่ามันเพิ่มความซับซ้อนที่ไม่จำเป็น การเขียนโค้ดที่มีความเป็นนามธรรมมากกว่าที่ควรจะเป็นมักจะถูกพิจารณาว่าเป็นกลิ่นของรหัสที่เรียกว่า "การเก็งกำไรทั่วไป" (หรือที่กล่าวถึงในโพสต์) แต่ถ้าฉันติดตาม TDD ฉันไม่สามารถสร้างการทดสอบเป็นสองเท่าได้อย่างง่ายดายโดยไม่ต้องคำนึงถึงการเก็งกำไรไม่ว่าจะอยู่ในรูปแบบของการใช้อินเทอร์เฟซหรือตัวเลือก polymorphic อื่น ๆ ของเรา ดังนั้นเราจะคืนดีการแลกเปลี่ยนนี้ได้อย่างไร มันคุ้มค่าหรือไม่ที่จะเป็นการเก็งกำไรโดยทั่วไปเพื่ออำนวยความสะดวกในการทดสอบ / TDD? หากคุณใช้การทดสอบเป็นสองเท่าให้นับเป็นการนำไปใช้ครั้งที่สองและทำให้ความคิดทั่วๆไปไม่เป็นการเก็งกำไรอีกต่อไป? คุณควรพิจารณากรอบการเยาะเย้ยเฮฟวี่เวทที่ช่วยให้ผู้เยาะเย้ยเป็นรูปธรรมมากขึ้น (เช่นโมลเทียบกับ Moq ใน C # โลก) หรือไม่ หรือคุณควรทดสอบกับชั้นเรียนที่เป็นรูปธรรมและเขียนสิ่งที่อาจพิจารณาว่าเป็นการทดสอบ "การรวม" จนกว่าจะถึงเวลาที่การออกแบบของคุณต้องมีความหลากหลาย ฉันอยากรู้อยากเห็นที่จะอ่านคนอื่นจะใช้เวลาในเรื่องนี้ - ขอบคุณล่วงหน้าสำหรับความคิดเห็นของคุณ

11 design  unit-testing  code-smell  polymorphism 

ปิด. คำถามนี้เป็นคำถามปิดหัวข้อ ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้เป็นหัวข้อสำหรับ Software Engineering Stack Exchange ปิดให้บริการใน5 ปีที่ผ่านมา ฉันสงสัยในการเขียนรหัสการทำงานใหม่อยู่เสมอ - การย้ายรหัสจะไม่มีข้อยกเว้น อย่างไรก็ตามด้วยการถือกำเนิดของ TDD และการทดสอบอัตโนมัติมันมีความเหมาะสมมากกว่าในการเขียนและสร้างรหัสใหม่ ไม่มีใครรู้ว่ามีเครื่องมือ TDD ที่สามารถใช้ในการย้ายรหัสเก่าได้หรือไม่? เป็นการดีที่คุณสามารถทำต่อไปนี้: เขียนการทดสอบหน่วยผู้ไม่เชื่อเรื่องภาษาสำหรับรหัสเก่าที่ผ่าน (หรือล้มเหลวหากคุณพบข้อบกพร่อง!) เรียกใช้การทดสอบหน่วยในฐานรหัสอื่น ๆ ของคุณที่ล้มเหลว เขียนรหัสในภาษาใหม่ของคุณที่ผ่านการทดสอบโดยไม่ต้องดูรหัสเก่า อีกทางเลือกหนึ่งคือการแยกขั้นตอนที่ 1 เป็น "การทดสอบหน่วยการเขียนในภาษา 1" และ "การทดสอบหน่วยพอร์ตเป็นภาษา 2" ซึ่งเพิ่มความพยายามอย่างมากและจำเป็นต้องพิสูจน์ว่าฐานรหัสเก่ากำลังจะหยุดหลังจากนั้น พอร์ต (นั่นคือคุณจะไม่ได้รับประโยชน์จากการรวมอย่างต่อเนื่องในฐานรหัสนี้) แก้ไข: มันคุ้มที่จะสังเกตคำถามนี้ใน StackOverflow

11 unit-testing  language-agnostic  porting 

ฉันเพิ่งเจอCyclomatic Complexityและฉันต้องการพยายามทำความเข้าใจให้ดีขึ้น อะไรคือตัวอย่างการเขียนโปรแกรมเชิงปฏิบัติของปัจจัยต่าง ๆ ที่นำไปสู่การคำนวณความซับซ้อน โดยเฉพาะสำหรับสมการวิกิพีเดียM = E − N + 2Pฉันต้องการเข้าใจความหมายของคำศัพท์แต่ละข้อต่อไปนี้ให้ดีขึ้น: E = จำนวนขอบของกราฟ N = จำนวนโหนดของกราฟ P = จำนวนขององค์ประกอบที่เชื่อมต่อ ฉันสงสัยว่าทั้งEหรือNอาจเป็นจำนวนคะแนนการตัดสินใจ (ถ้า, ถ้า, สำหรับ, foreach, ฯลฯ ) ในบล็อกของรหัส แต่ฉันไม่แน่ใจว่าที่ใดหรือสิ่งอื่น ๆ ที่มีความหมาย ฉันเดาด้วยว่าPหมายถึงการเรียกใช้ฟังก์ชั่นและอินสแตนซ์ของคลาส แต่ไม่มีคำจำกัดความที่ชัดเจนที่ฉันเห็น หากใครบางคนสามารถส่องแสงเพิ่มอีกนิดด้วยตัวอย่างโค้ดที่ชัดเจนของแต่ละอันมันจะช่วยได้ จากการติดตาม Cyclomatic Complexity มีความสัมพันธ์โดยตรงกับจำนวนการทดสอบหน่วยที่จำเป็นสำหรับการครอบคลุมเส้นทาง 100% หรือไม่? ตัวอย่างเช่นวิธีการที่มีความซับซ้อน 4 บ่งบอกว่าจำเป็นต้องมีการทดสอบ 4 บทเพื่อครอบคลุมวิธีการดังกล่าวหรือไม่? ในที่สุดการแสดงออกปกติส่งผลกระทบต่อความซับซ้อนของวัฏจักรและถ้าเป็นเช่นนั้นได้อย่างไร

11 unit-testing  cyclomatic-complexity 

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

11 php  unit-testing 

ปิด. คำถามนี้เป็นคำถามปิดหัวข้อ ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้เป็นหัวข้อสำหรับ Software Engineering Stack Exchange ปิดให้บริการใน6 ปีที่ผ่านมา ฉันค้นหางานนำเสนอที่ดี (ต้องการสไลด์ + เสียงหรือวิดีโอ) ในการทดสอบหน่วย แต่สิ่งที่ฉันพบคือหนังสือและบทความในบล็อก งานนำเสนอไม่ควรเกิน 50 นาทีเนื่องจากจะมีการนำเสนอในอาหารกลางวันถุงสีน้ำตาล แนวคิดทั่วไปหรือวิธีการทำบนแพลตฟอร์ม. NET คือสิ่งที่ฉันกำลังมองหา คุณช่วยแนะนำงานนำเสนอที่ตรงกับคำอธิบายนั้นได้หรือไม่?

11 .net  unit-testing  presentation 

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

11 unit-testing  tdd 

สิ่งที่ฉันสังเกตเห็นเมื่อเร็ว ๆ นี้คือเมื่อฉันทำโครงการประเภทต่อไปนี้: เมื่อเริ่มต้นโครงการ ทำงานกับ MVP / เครื่องต้นแบบ การเพิ่มคุณสมบัติที่ไม่ได้กำหนดไว้ทั้งหมด ทำงานในโครงการขนาดเล็ก สำหรับการอ้างอิงฉันกำลังทำงานในโครงการ Python ซึ่งปัจจุบันมีรหัส ~ 1k บรรทัดรวมถึงความคิดเห็นและช่องว่างทั้งหมด ฉันพบว่ามันง่ายขึ้นอย่างมากในการเขียนการทดสอบการรวมการทำงานครั้งแรกทำงานบนรหัสและจากนั้นเมื่อ API ค่อนข้างแข็งจริง ๆ แล้วสามารถเพิ่มการทดสอบหน่วยได้ ประเภทของการทดสอบที่ฉันสามารถเรียกใช้ในmainฟังก์ชั่นของฉันดังนั้นพูดและมี "จบสิ้น" มากกว่าสิ่งอื่นใด เนื่องจากการทดสอบหน่วยนั้นน่ารำคาญจริง ๆ เมื่อ API มีการเปลี่ยนแปลงอย่างรวดเร็วค่อนข้างบ่อยซึ่งเป็นกรณีเมื่อทำงานกับโครงการที่ตรงกับเกณฑ์ใด ๆ หรือส่วนใหญ่ข้างต้น วิธีนี้เป็นแนวทางที่ดีหรือไม่และเกณฑ์ใดที่ควรพิจารณาเมื่อทำการตัดสินใจว่าจะเริ่มต้นด้วยการทดสอบหน่วยหรือการรวมเข้าด้วยกันเป็นครั้งแรกสำหรับโครงการประเภทนี้หรือไม่? ฉันขาดคุณค่าของการทดสอบหน่วยของโครงการประเภทนี้ก่อนที่ API จะแข็งตัวมากขึ้นหรือไม่

11 design  unit-testing  integration-tests 

ถ้าเราทดสอบฟังก์ชั่น B โดยการทดสอบฟังก์ชั่น C ซึ่งเรียกฟังก์ชั่น B นั่นคือการเขียนโปรแกรมทดสอบเพื่อทดสอบฟังก์ชั่น C ซึ่งเรียกฟังก์ชั่น B นั้นเป็นวิธีทดสอบยังคงเรียกว่าการทดสอบหน่วยหรืออย่างอื่น? เมื่อใดจึงจะต้องการทดสอบทางอ้อมในฟังก์ชันที่เรียกใช้ฟังก์ชันเป้าหมายและเมื่อใดจึงควรทดสอบฟังก์ชันโดยตรง

11 unit-testing  testing 

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

11 unit-testing  tdd  code-smell  anti-patterns 

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

11 unit-testing  documentation 

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

11 unit-testing 

ฉันเพิ่งสอบครั้งสุดท้ายของฉันสำหรับหลักสูตรวิศวกรรมซอฟต์แวร์สำหรับโปรแกรมปริญญาโทของฉันและหนึ่งในคำถามในการสอบมีดังต่อไปนี้: Unit Testing is considered: a. White-box Testing b. Black-box Testing c. Either ในประสบการณ์การพัฒนาซอฟต์แวร์ 7 ปีของฉันการทดสอบหน่วยได้ใช้แนวทางกล่องสีขาวเสมอ ผู้ทดสอบมีความรู้เต็มรูปแบบเกี่ยวกับการใช้งานหน่วยการเรียนรู้ในขณะที่เขียนการทดสอบ การทดสอบกล่องดำมาในภายหลังในรูปแบบของการรวมระบบและการทดสอบการยอมรับ อย่างไรก็ตามคำตอบที่ถูกต้องในการสอบ (ตามอาจารย์) คือการทดสอบหน่วยสามารถเป็นการทดสอบกล่องสีขาวหรือกล่องดำ ฉันได้ทำการวิจัยมาแล้วและดูเหมือนว่าหลาย ๆ กรณี "การทดสอบหน่วยกล่องดำ" ถูกใช้เพื่ออธิบายวิธีการทดสอบครั้งแรกที่การทดสอบหน่วยถูกเขียนขึ้นก่อนรหัสคือ อย่างไรก็ตามในความคิดของฉันนี้ยังคงทดสอบกล่องสีขาว ในขณะที่การใช้งานยังไม่มีอยู่ใครก็ตามที่กำลังเขียนการทดสอบโดยทั่วไปมีความคิดที่ดีเกี่ยวกับการใช้งานซอร์สโค้ด ใครช่วยอธิบายให้ฉันฟังว่าการทดสอบหน่วยกล่องดำทำงานอย่างไร (ถ้ามันเป็นเรื่องจริง) และแตกต่างจากการทดสอบยูนิตกล่องขาวอย่างไร

11 unit-testing  testing  tdd 

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

10 unit-testing  testing  continuous-integration 

ที่ทำงานเรามีระบบที่ค่อนข้างซับซ้อน เรียกระบบนี้ว่า System_A ทีมงาน QA ของเราได้สร้างระบบอื่นเรียกระบบนี้ว่า System_B เพื่อทดสอบ System_A วิธีที่ใช้ System_B มีดังนี้ เราสร้างอินพุต (โดยใช้ System_B เอง), IN, ประมวลผลอินพุตดังกล่าวกลับผ่าน System_B และสร้างเอาต์พุต O_B ดังนั้นกระบวนการดังต่อไปนี้: System_B(IN) -> O_B. จากนั้นเราก็ทำเช่นเดียวกันสำหรับ System_A เพื่อสร้างผลลัพธ์ของตัวเอง O_A: System_A(IN) -> O_A. เมื่อใดก็ตามจะถือว่า O_B เป็นเอาต์พุตที่คาดหวังและ O_A เป็นเอาต์พุตที่ตรวจพบ / เกิดขึ้นจริง โดยนัยก็คือ O_B เป็นแหล่ง "ทองคำ" (ความจริง) อย่างไรก็ตามเราพบปัญหาหลายอย่าง O_A ผิด O_B ถูกต้อง O_A …

10 unit-testing  testing  qa  acceptance-testing  integration-testing 

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

10 unit-testing  code-quality  integration-tests  test-coverage