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

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

12
หากรหัสทดสอบหน่วยของคุณ“ มีกลิ่น” มีความสำคัญหรือไม่?
โดยปกติฉันแค่ทำการทดสอบหน่วยของฉันด้วยกันโดยใช้การคัดลอกและวางและวิธีปฏิบัติที่ไม่ดีอื่น ๆ การทดสอบหน่วยมักจะดูน่าเกลียดมากพวกเขาเต็มไปด้วย "กลิ่นรหัส" แต่สิ่งนี้สำคัญหรือไม่ ฉันมักจะบอกตัวเองตราบใดที่รหัส "ของจริง" คือ "ดี" นั่นคือทั้งหมดที่สำคัญ นอกจากนี้การทดสอบหน่วยมักจะต้องการ "แฮ็กที่มีกลิ่นเหม็น" ที่หลากหลายเช่นฟังก์ชั่นขัดถู ฉันควรกังวลเกี่ยวกับการทดสอบหน่วยที่ออกแบบมาไม่ดี ("เหม็น") อย่างไร

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

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

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

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

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

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

2
ควรจัดรหัสทดสอบหน่วย C ++ เพื่อประสิทธิภาพการทดสอบหน่วยสูงสุดอย่างไร
คำถามนี้ไม่เกี่ยวกับกรอบการทดสอบหน่วย คำถามนี้ไม่เกี่ยวกับการเขียนการทดสอบหน่วย คำถามนี้เกี่ยวกับสถานที่ที่จะวางโค้ด UT และวิธี / เวลา / สถานที่ในการรวบรวมและเรียกใช้ ในการทำงานอย่างมีประสิทธิภาพด้วยรหัสมรดก Michael Feathers ยืนยันว่า ทดสอบหน่วยที่ดี ... ทำงานเร็ว และนั่น การทดสอบหน่วยที่ใช้เวลา 1 / 10th ของวินาทีในการทำงานคือการทดสอบหน่วยช้า ฉันคิดว่าคำจำกัดความเหล่านี้สมเหตุสมผล ฉันยังคิดว่าพวกเขาบอกเป็นนัยว่าคุณต้องเก็บชุดการทดสอบหน่วยและชุดการทดสอบรหัสเหล่านั้นที่ใช้เวลานานกว่าแยกจากกัน แต่ฉันคิดว่านั่นคือราคาที่คุณจ่ายสำหรับการโทรหาการทดสอบหน่วยเท่านั้น . เห็นได้ชัดว่าปัญหาใน C ++ คือการ "เรียกใช้" การทดสอบหน่วยของคุณคุณต้อง: แก้ไขรหัสของคุณ (การผลิตหรือการทดสอบหน่วยขึ้นอยู่กับ "รอบ" ที่คุณอยู่) รวบรวม ลิงค์ เริ่มการทดสอบหน่วยปฏิบัติการ ( s ) แก้ไข(หลังจากลงคะแนนเสียงแปลก ๆ ) : ก่อนลงรายละเอียดฉันจะลองสรุปประเด็นที่นี่: รหัสการทดสอบหน่วย C ++ …

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

7
แนวปฏิบัติที่เหมาะสมที่สุดเมื่อทำการทดสอบหน่วยสำหรับการพัฒนาแบบฝัง
ฉันกำลังมองหากลยุทธ์การปฏิบัติที่ดีที่สุดสำหรับโค้ดทดสอบหน่วยที่เขียนขึ้นสำหรับระบบฝังตัว โดยระบบฝังตัวฉันหมายถึงรหัสเช่นไดรเวอร์อุปกรณ์ตัวจัดการ ISR เป็นต้นสิ่งที่ใกล้เคียงกับโลหะ การทดสอบหน่วยส่วนใหญ่ไม่สามารถทำได้หากไม่ทำการทดสอบบนฮาร์ดแวร์ด้วยความช่วยเหลือของ ICE บางครั้งหน่วยสมองกลฝังตัวก็จำเป็นต้องติดอยู่กับสิ่งกระตุ้นอื่น ๆ เช่นสวิตช์เชิงกลมอเตอร์สเต็ปเปอร์และหลอดไฟ สิ่งนี้มักจะเกิดขึ้นในแบบแมนนวลระบบอัตโนมัติจะยอดเยี่ยม แต่ยากและมีราคาแพงเพื่อให้บรรลุ ปรับปรุง ฉันเจอโครงร่างการทดสอบ C ซึ่งดูเหมือนว่าจะประสบความสำเร็จในการทดสอบโครงการแบบฝัง มันใช้ความคิดของฮาร์ดแวร์เยาะเย้ย ตรวจสอบความสามัคคี , CMockและอาจCeedling อัพเดท 06 ก.ค. 2559 มาทั่วcmocka - ดูเหมือนว่าจะทำงานอย่างแข็งขันมากขึ้น

5
คุณจะโน้มน้าวผู้บริหารให้“ ลงทุน” ในการทดสอบหน่วยได้อย่างไร
คุณโน้มน้าวผู้จัดการของคุณให้ทดสอบหน่วยได้อย่างไร โดย "ใช้" ฉันหมายถึงได้รับอนุญาตให้พัฒนาเช็คอินเพื่อควบคุมแหล่งที่มาและรักษาการทดสอบหน่วยในช่วงเวลาอื่น ๆ การคัดค้านการจัดการทั่วไปคือ: ลูกค้าไม่ได้ชำระเงินสำหรับการทดสอบหน่วย โครงการไม่อนุญาตให้มีเวลาสำหรับการทดสอบหน่วย หนี้ทางเทคนิค? หนี้สินทางเทคนิคคืออะไร คุณรู้จักคำคัดค้านอื่น ๆ หรือไม่? คุณมีคำตอบอะไร ขอบคุณล่วงหน้า!

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

14
การทดสอบหน่วยของอัลกอริทึมแบบสุ่ม / ไม่กำหนด
โครงการปัจจุบันของฉันรวบรัดเกี่ยวข้องกับการสร้าง "เหตุการณ์แบบสุ่ม - จำกัด " ฉันกำลังสร้างตารางการตรวจสอบ บางคนขึ้นอยู่กับข้อ จำกัด ของตารางที่เข้มงวด คุณทำการตรวจสอบสัปดาห์ละครั้งในวันศุกร์เวลา 10:00 น. การตรวจสอบอื่น ๆ คือ "สุ่ม"; มีข้อกำหนดขั้นพื้นฐานที่กำหนดค่าได้เช่น "การตรวจสอบจะต้องเกิดขึ้น 3 ครั้งต่อสัปดาห์", "การตรวจสอบจะต้องเกิดขึ้นระหว่างเวลา 9.00 น. - 21.00 น." และ "ไม่ควรมีการตรวจสอบสองครั้งภายในระยะเวลา 8 ชั่วโมงเดียวกัน" แต่ ภายในข้อ จำกัด ใดก็ตามที่กำหนดค่าไว้สำหรับชุดการตรวจสอบเฉพาะวันที่และเวลาที่เกิดขึ้นไม่ควรคาดเดาได้ การทดสอบหน่วยและ TDD, IMO มีคุณค่าอย่างมากในระบบนี้เนื่องจากสามารถใช้ในการสร้างแบบเพิ่มหน่วยในขณะที่ข้อกำหนดทั้งหมดยังไม่สมบูรณ์และทำให้แน่ใจว่าฉันไม่ได้ "ทำวิศวกรรมมากเกินไป" เพื่อทำสิ่งที่ฉันทำ ตอนนี้ฉันรู้ว่าฉันต้องการ ตารางงานที่เข้มงวดเป็นงานชิ้นเอกสำหรับ TDD อย่างไรก็ตามฉันพบว่ามันยากที่จะกำหนดสิ่งที่ฉันกำลังทดสอบเมื่อฉันเขียนการทดสอบสำหรับส่วนที่สุ่มของระบบ ฉันสามารถยืนยันได้ว่าเวลาทั้งหมดที่ผลิตโดยตัวจัดตารางเวลาจะต้องตกอยู่ภายใต้ข้อ จำกัด แต่ฉันสามารถใช้อัลกอริทึมที่ผ่านการทดสอบดังกล่าวทั้งหมดโดยไม่มีเวลาที่แท้จริง "สุ่ม" มาก ในความเป็นจริงนั้นเป็นสิ่งที่เกิดขึ้นจริง …

9
เราจำเป็นต้องทำการบันทึกเมื่อทำ TDD หรือไม่?
เมื่อทำการ Red, Green & Refactor cycle เราควรเขียนโค้ดขั้นต่ำเพื่อผ่านการทดสอบ นี่คือวิธีที่ฉันได้รับการสอนเกี่ยวกับ TDD และวิธีที่หนังสือเกือบทั้งหมดบรรยายกระบวนการ แต่สิ่งที่เกี่ยวกับการเข้าสู่ระบบ? จริงๆแล้วฉันไม่ค่อยได้ใช้การบันทึกในแอพพลิเคชั่นเว้นแต่มีบางสิ่งที่ซับซ้อนจริงๆที่เกิดขึ้นอย่างไรก็ตามฉันได้เห็นโพสต์มากมายที่พูดถึงความสำคัญของการบันทึกที่เหมาะสม ดังนั้นนอกเหนือจากการบันทึกข้อยกเว้นฉันไม่สามารถพิสูจน์ความสำคัญที่แท้จริงของการบันทึกในแอปพลิเคชันที่ผ่านการทดสอบที่เหมาะสม (การทดสอบหน่วย / การรวม / การยอมรับ) ดังนั้นคำถามของฉันคือ: เราจำเป็นต้องเข้าสู่ระบบหากเรากำลังทำ TDD อยู่หรือไม่? การทดสอบที่ล้มเหลวจะไม่เปิดเผยว่ามีอะไรผิดปกติกับแอปพลิเคชันหรือไม่ เราควรเพิ่มการทดสอบสำหรับกระบวนการบันทึกในแต่ละวิธีในแต่ละคลาสหรือไม่ หากระดับการบันทึกบางส่วนถูกปิดใช้งานในสภาพแวดล้อมการผลิตเช่นนั้นจะไม่แนะนำการพึ่งพาระหว่างการทดสอบและสภาพแวดล้อมหรือไม่? ผู้คนพูดถึงวิธีที่ง่ายในการดีบัก แต่หนึ่งในข้อดีหลักเกี่ยวกับ TDD คือฉันมักจะรู้ว่ามีอะไรผิดปกติเนื่องจากการทดสอบที่ล้มเหลว มีบางอย่างที่ฉันพลาดไปไหม

13
เราจะทำให้การทดสอบหน่วยทำงานอย่างรวดเร็วได้อย่างไร
เรามาถึงจุดที่โครงการของเราซึ่งเรามีการทดสอบเกือบหนึ่งพันครั้งและผู้คนหยุดทำงานก่อนที่จะทำการเช็คอินเพราะมันใช้เวลานานมาก อย่างดีที่สุดพวกเขาเรียกใช้การทดสอบที่เกี่ยวข้องกับชิ้นส่วนของรหัสที่พวกเขาเปลี่ยนแปลงและที่เลวร้ายที่สุดพวกเขาเพียงตรวจสอบโดยไม่ต้องทดสอบ ฉันเชื่อว่าปัญหานี้เกิดจากความจริงที่ว่าโซลูชันเพิ่มขึ้นถึง 120 โครงการ (เรามักจะทำโครงการขนาดเล็กมากและนี่เป็นเพียงครั้งที่สองที่เราทำ TDD อย่างถูกต้อง) และเวลาสร้าง + ทดสอบเพิ่มขึ้นประมาณสองถึงสามนาที บนเครื่องที่น้อยกว่า เราจะลดระยะเวลาในการทดสอบได้อย่างไร มีเทคนิคไหม? แกล้งทำมากขึ้น? แกล้งทำน้อยลงหรือไม่ บางทีการทดสอบการรวมที่ใหญ่กว่านั้นไม่ควรทำงานโดยอัตโนมัติเมื่อทำการทดสอบทั้งหมดใช่ไหม แก้ไข:เพื่อเป็นการตอบสนองต่อคำตอบหลาย ๆ คำเราใช้ CI และ build server อยู่แล้วนี่คือวิธีที่ฉันรู้ว่าการทดสอบล้มเหลว ปัญหา (จริง ๆ แล้วเป็นอาการ) คือเราได้รับข้อความเกี่ยวกับงานสร้างที่ล้มเหลว ใช้การทดสอบบางส่วนเป็นสิ่งที่คนส่วนใหญ่ทำ แต่ไม่ใช่ทั้งหมด และเกี่ยวกับการทดสอบพวกเขาทำได้ค่อนข้างดีพวกเขาใช้ของปลอมสำหรับทุกสิ่งและไม่มี IO เลย
40 c#  unit-testing  tdd  nunit 

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.