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

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

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

2
การทดสอบหน่วย:“ มันเป็นกลิ่นรหัสหากคุณทำการปรับโครงสร้างใหม่และไม่มีผู้ทำงานร่วมกัน”?
ฉันกำลังอ่านศิลปะของการทดสอบหน่วยโดย Roy Osherove ฉันอยู่ที่หัวข้อ 7.2 การเขียนแบบทดสอบที่คงไว้ซึ่งผู้เขียนมีหมายเหตุเกี่ยวกับกลิ่นรหัสนี้: หมายเหตุ: เมื่อคุณ refactor สถานะภายในที่จะมองเห็นได้จากการทดสอบภายนอกอาจถือได้ว่าเป็นกลิ่นรหัส (สัญญาณว่ามีบางอย่างผิดปกติในการออกแบบหรือตรรกะของรหัส) มันไม่ได้เป็นกลิ่นรหัสเมื่อคุณ refactoring เปิดเผยผู้ทำงานร่วมกัน มันเป็นกลิ่นรหัสหากคุณทำการปรับโครงสร้างใหม่และไม่มีผู้ทำงานร่วมกัน แก้ไข : สิ่งที่ผู้เขียนหมายถึงโดย "ผู้ทำงานร่วมกัน" คือการพึ่งพา ตัวอย่างบางส่วนของเขาสำหรับการพึ่งพาคือคลาสที่เข้าถึงฐานข้อมูลหรือเข้าถึงระบบไฟล์ของระบบปฏิบัติการ นี่คือที่ซึ่งเขากำหนดต้นขั้วและเริ่มใช้คำทำงานร่วมกัน: ต้นขั้วเป็นแทนควบคุมที่มีอยู่การพึ่งพา (หรือ ทำงานร่วมกัน ) ในระบบ ผู้เขียนไม่มีตัวอย่างของกลิ่นรหัสนี้และฉันมีปัญหาในการทำความเข้าใจ / นึกภาพว่ามันจะเป็นอย่างไร บางคนสามารถอธิบายสิ่งนี้ได้มากกว่านี้เล็กน้อยและอาจเป็นตัวอย่างที่ชัดเจน?

4
การเขียนการทดสอบหน่วยสำหรับชั้นเรียนที่เริ่มต้น EXE ภายนอก
ฉันเขียนคลาส C # ที่ใช้เพื่อเริ่มรายการ EXE (ไม่ใช่ของฉัน - EXE ของบุคคลที่สามที่ฉันต้องเรียกใช้) และให้พวกเขาทำงานต่อไป (จะตรวจสอบเป็นครั้งคราวเพื่อให้แน่ใจว่ามันยังคงทำงานอยู่และเริ่มต้นหากไม่ได้) . ฉันสามารถทดสอบตรรกะพื้นฐานของการเพิ่มการเอาออกและอื่น ๆ ได้ ฉันจะทดสอบหน่วยได้อย่างไรว่างานที่แท้จริงในการดูแล EXEs จะทำงานได้อย่างไร ความคิดเริ่มต้นของฉันคือการเริ่มต้นหุ่นจำลอง EXE ที่ปิดตัวเองหลังจาก 1 วินาทีจากนั้นใช้เพื่อทดสอบ นั่นไม่ใช่ขอบเขตของการทดสอบหน่วยหรือไม่

9
ในฐานะนักพัฒนามืออาชีพจะยอมรับได้หรือไม่หากไม่เขียนการทดสอบหน่วย? [ปิด]
ตามที่เป็นอยู่ในปัจจุบันคำถามนี้ไม่เหมาะสำหรับรูปแบบคำถาม & คำตอบของเรา เราคาดหวังคำตอบที่จะได้รับการสนับสนุนจากข้อเท็จจริงการอ้างอิงหรือความเชี่ยวชาญ แต่คำถามนี้อาจเรียกร้องให้มีการอภิปรายโต้แย้งโต้แย้งหรือการอภิปรายเพิ่มเติม หากคุณรู้สึกว่าคำถามนี้สามารถปรับปรุงและเปิดใหม่ได้โปรดไปที่ศูนย์ช่วยเหลือเพื่อขอคำแนะนำ ปิดให้บริการใน7 ปีที่ผ่านมา แค่สงสัยในข้อดีข้อเสียของการทดสอบหน่วย TDD / อัตโนมัติและมองหามุมมองของชุมชนว่าเป็นที่ยอมรับได้หรือไม่สำหรับนักพัฒนามืออาชีพในการเขียนแอปพลิเคชันโดยไม่สนับสนุนการทดสอบหน่วย

3
วิธีทำให้คลาส stateful ที่ซับซ้อนและการทดสอบของพวกเขาง่ายขึ้น?
ฉันอยู่ในโครงการระบบกระจายเขียนด้วยภาษาจาวาที่เรามีบางคลาสที่สอดคล้องกับวัตถุในโลกธุรกิจจริงที่ซับซ้อนมาก วัตถุเหล่านี้มีวิธีการมากมายที่สอดคล้องกับการกระทำที่ผู้ใช้ (หรือตัวแทนอื่น ๆ ) อาจนำไปใช้กับวัตถุนั้น เป็นผลให้คลาสเหล่านี้ซับซ้อนมาก วิธีการสถาปัตยกรรมทั่วไปของระบบนำไปสู่พฤติกรรมจำนวนมากที่เน้นไปที่คลาสไม่กี่คลาสและสถานการณ์การโต้ตอบที่เป็นไปได้มากมาย ตัวอย่างและเพื่อให้สิ่งต่าง ๆ ง่ายและชัดเจนสมมติว่าหุ่นยนต์และรถยนต์เป็นชั้นเรียนในโครงการของฉัน ดังนั้นในคลาส Robot ฉันจะมีวิธีการมากมายในรูปแบบต่อไปนี้: นอน(); isSleepAvaliable (); ตื่น (); isAwakeAvaliable (); เดิน (Direction); isWalkAvaliable (); ยิง (Direction); isShootAvaliable (); turnOnAlert (); isTurnOnAlertAvailable (); turnOffAlert (); isTurnOffAlertAvailable (); ชาร์จ (); isRechargeAvailable (); ไฟดับ(); isPowerOffAvailable (); stepInCar (รถยนต์); isStepInCarAvailable (); stepOutCar (รถยนต์); …

3
คุณจัดโครงสร้างหน่วยการทดสอบสำหรับวัตถุหลายรายการที่มีพฤติกรรมเดียวกันได้อย่างไร
ในหลายกรณีฉันอาจมีคลาสที่มีอยู่แล้วซึ่งมีพฤติกรรมบางอย่าง: class Lion { public void Eat(Herbivore herbivore) { ... } } ... และฉันมีการทดสอบหน่วย ... [TestMethod] public void Lion_can_eat_herbivore() { var herbivore = buildHerbivoreForEating(); var test = BuildLionForTest(); test.Eat(herbivore); Assert.IsEaten(herbivore); } ตอนนี้สิ่งที่เกิดขึ้นคือฉันต้องสร้างคลาส Tiger ที่มีพฤติกรรมเฉพาะตัวของ Lion: class Tiger { public void Eat(Herbivore herbivore) { ... } } ... และเนื่องจากฉันต้องการพฤติกรรมเดียวกันฉันจึงต้องทำการทดสอบเดียวกันฉันจึงทำสิ่งนี้: interface IHerbivoreEater …

3
กระบวนการปรับใช้การพัฒนาแบบว่องไว การควบคุมคุณภาพและเจ้าของธุรกิจทดสอบที่ไหน
ฉันอ่านมากเมื่อเร็ว ๆ นี้เกี่ยวกับกระบวนการปรับใช้เว็บแอปพลิเคชันต่าง ๆ โดยใช้ SVN หรือ GIT เพื่อดูการออกแบบวิธีที่เราปรับใช้ในที่ทำงาน เช่นเดียวกับวิธีที่มีความหลากหลายของความคล่องตัวก็ถือว่าสิ่งที่มุ่งมั่นที่จะต้นแบบหรือลำตัวพร้อมที่จะผลิต ทั้ง GitHub และ Etsy, http://codeascraft.etsy.com/2010/05/20/quantum-of-deployment/บอกว่าพวกเขาทำงานบนพื้นฐานนี้ (แม้ว่า Etsy จะมีสภาพแวดล้อมจริง) กระบวนการนี้ถือว่าการทดสอบหน่วยและการทดสอบ CI ทั้งหมดได้รับการดำเนินการ คุณเรียกใช้การทดสอบแบบโลคัลและบน CI จากนั้นคอมมิทไปที่ trunk ดังนั้นที่จุดนี้รหัสของคุณในทางเทคนิคเสียง รหัสของคุณอาจถูกต้องทางเทคนิค แต่การทดสอบผู้ใช้ / ฟังก์ชั่นอาจพบข้อผิดพลาดมากขึ้นโดยเฉพาะอย่างยิ่งเมื่อมันมาถึงการทดสอบส่วนหน้า คำถามของฉันคือสิ่งนี้ เจ้าของ QA และธุรกิจจะทดสอบการเปลี่ยนแปลงคุณสมบัติที่คุณนำไปใช้ที่ไหน บนเครื่องพัฒนาท้องถิ่นของคุณก่อนที่คุณจะผูกพันหรือบนเครื่อง QA / การแสดงละคร? หากคุณมีเครื่อง staging ที่รัน trunk และคุณคิดว่ารหัสทั้งหมดที่กำหนดให้กับ trunk นั้นพร้อมใช้งานแล้วกำลังผลิต ... เอ๊ะ .. แล้วรหัสใดที่ถูกปิดและดีที่จะเข้าสู่การผลิตจากทั้งทางเทคนิคและธุรกิจ มุมมอง? …

4
สิ่งที่เข้าใจภายใต้“ หน่วย” ในการทดสอบหน่วย
ตามที่ฉันเข้าใจในทฤษฎีภายใต้ "หน่วย" คนหมายถึงวิธี (ใน OOP) แต่ในการทดสอบการปฏิบัติซึ่งยืนยันว่าวิธีการแยกบางอย่างนั้นเป็นการทดสอบพฤติกรรมที่บอบบางมาก (ไม่ได้ตรวจสอบผลลัพธ์ แต่เป็นข้อเท็จจริงที่เรียกวิธีการพึ่งพาบางอย่าง) ดังนั้นฉันเห็นผู้คนจำนวนมากที่เรียนเป็นกลุ่มเข้าใจคลาสเล็ก ๆ ที่เกี่ยวข้องอย่างใกล้ชิด ในกรณีนี้มีเพียงการอ้างอิงภายนอกเท่านั้นที่จะถูกล้อเลียน / ขัดและสำหรับการอ้างอิงที่อยู่ภายในการใช้งานจริงของหน่วย ในกรณีนี้มีสถานะมากขึ้นมีความหมาย (ตามข้อกำหนด) และการทดสอบที่ไม่เปราะบาง ดังนั้นคำถามคือคุณรู้สึกอย่างไรเกี่ยวกับวิธีการเหล่านี้และมันถูกต้องหรือไม่ที่จะเรียกการทดสอบหน่วยวิธีที่สองหรืออาจเป็นการทดสอบบูรณาการระดับต่ำ หากคุณเห็นข้อควรพิจารณาบางประการเกี่ยวกับการใช้ TDD ด้วยวิธีการทดสอบวิธีใดวิธีหนึ่งเหล่านี้ฉันจะขอบคุณสำหรับความคิดของคุณ

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

4
ชื่อใหม่สำหรับการทดสอบหน่วย [ปิด]
ปิด คำถามนี้เป็นคำถามความคิดเห็นตาม ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้สามารถตอบข้อเท็จจริงและการอ้างอิงได้โดยแก้ไขโพสต์นี้ ปิดให้บริการใน4 ปีที่แล้ว ฉันไม่เคยชอบทดสอบหน่วย ฉันคิดเสมอว่ามันเพิ่มปริมาณงานที่ฉันต้องทำ กลายเป็นว่าเป็นเพียงความจริงในแง่ของจำนวนบรรทัดของรหัสที่คุณเขียนจริงและยิ่งไปกว่านั้นสิ่งนี้จะถูกชดเชยโดยการเพิ่มจำนวนบรรทัดของโค้ดที่มีประโยชน์ที่คุณสามารถเขียนในหนึ่งชั่วโมงด้วยการทดสอบและการพัฒนาแบบทดสอบ ตอนนี้ฉันชอบการทดสอบหน่วยเพราะพวกเขาอนุญาตให้ฉันเขียนโค้ดที่มีประโยชน์ซึ่งค่อนข้างบ่อยครั้งแรกที่ใช้งานได้! (เคาะบนไม้) ฉันพบว่าผู้คนลังเลที่จะทำการทดสอบหน่วยหรือเริ่มต้นโครงการด้วยการพัฒนาด้วยการทดสอบหากพวกเขาอยู่ภายใต้เส้นเวลาที่เข้มงวดหรือในสภาพแวดล้อมที่คนอื่นไม่ทำดังนั้นพวกเขาจึงไม่ทำ ค่อนข้างชอบปฏิเสธวัฒนธรรมที่จะลอง ฉันคิดว่าหนึ่งในสิ่งที่ทรงพลังที่สุดเกี่ยวกับการทดสอบหน่วยคือความมั่นใจที่จะทำให้คุณทำการปรับโครงสร้างใหม่ นอกจากนี้ยังให้ความหวังใหม่ที่ฉันสามารถมอบรหัสให้ผู้อื่นเพื่อปรับปรุง / ปรับปรุงและถ้าการทดสอบหน่วยของฉันยังคงใช้งานได้ฉันสามารถใช้ไลบรารี่เวอร์ชันใหม่ที่พวกเขาแก้ไขได้โดยไม่ต้องกลัว นี่เป็นแง่มุมสุดท้ายของการทดสอบหน่วยที่ฉันคิดว่าต้องการชื่อใหม่ การทดสอบหน่วยเป็นเหมือนสัญญาของสิ่งที่รหัสนี้ควรทำตอนนี้และในอนาคต เมื่อฉันได้ยินคำทดสอบฉันคิดว่าหนูเป็นกรงด้วยการทดลองหลายครั้งเพื่อให้เห็นถึงประสิทธิภาพของสารประกอบ นี่ไม่ใช่สิ่งที่การทดสอบหน่วยเราไม่ได้ลองใช้รหัสที่แตกต่างกันเพื่อดูว่าอะไรคือวิธีที่มีความรู้สึกมากที่สุดเรากำลังกำหนดสิ่งที่เราคาดหวังกับสิ่งที่อินพุต ในตัวอย่างของหนูการทดสอบหน่วยเป็นเหมือนคำจำกัดความของการทำงานของจักรวาลเมื่อเทียบกับการทดลองที่ทำกับหนู ฉันกำลังแตกหรือไม่มีใครเห็นการปฏิเสธที่จะทำการทดสอบและพวกเขาคิดว่ามันเป็นเหตุผลที่คล้ายกันที่พวกเขาไม่ต้องการที่จะทำมันได้หรือไม่ คุณ / คนอื่น ๆ ให้เหตุผลอะไรเพื่อไม่ทำการทดสอบ คุณคิดว่าแรงจูงใจของพวกเขาไม่ใช่การทดสอบหน่วย? และในฐานะชื่อใหม่สำหรับการทดสอบหน่วยที่อาจผ่านการคัดค้านบางอย่างแล้ว jContract ล่ะ? (Java เป็นศูนย์กลางฉันรู้ว่า :) หรือหน่วยสัญญาหรือไม่
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.