ถ้าการทดสอบหน่วยดีมากทำไมไม่มี บริษัท อื่นทำ [ปิด]


103

บริษัท ซอฟต์แวร์ตัวจริงแห่งแรกที่ฉันทำงานนั้นเกี่ยวกับการทดสอบหน่วย (NUnit) ฉันไม่รู้ว่าตอนนั้นเราเป็นคนยึดติดจริงๆ - ฉันไม่รู้ว่าการครอบคลุมโค้ดของเราเป็นอย่างไรและฉันกำลังเขียนการทดสอบหน่วยส่วนใหญ่ ตั้งแต่นั้นมาฉันได้พบกับ บริษัท บางแห่งที่ทำการทดสอบมากมาย แต่เป็นการทดสอบเก้าอี้: อาศัยบุคคลที่อยู่ที่นั่นมีความเข้ากันได้ต่ำและมีโอกาสจับข้อบกพร่องต่ำ ทัศนคติอื่น ๆ ก็คือมันเป็นสิ่งที่พวกเขาอยากจะไปด้วย "ในอนาคต"; โดยพื้นฐานแล้วเมื่อเงินตกลงมาจากท้องฟ้า

ฉันพลาดการทดสอบหน่วย - มันทำให้ชีวิตง่ายขึ้น แต่ฉันพบว่าเมื่อฉันมองหางานใหม่การทดสอบหน่วยอาจเป็นสิ่งที่ บริษัท ต่างๆอยากจะ "ก้าวไปด้วย" ในอนาคตหรือสิ่งที่พวกเขาไม่ทำเลย (เอ่อมันผ่านมาระยะหนึ่งแล้ว ตอนนี้!) ฉันจะบอกว่า 60-75% ของความต้องการงานที่ฉันดูในช่วง 2 ปีที่ผ่านมาไม่ได้อยู่ในรายการทดสอบหน่วยเลย ฉันคิดได้เพียงหนึ่งหรือสองข้อที่มีประสบการณ์การทดสอบหน่วยเป็นข้อกำหนด (สำหรับตำแหน่งนักพัฒนาระดับกลาง)

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

แก้ไข: แม้ว่าชื่อจะดูเป็นผู้สนับสนุนปีศาจ แต่ฉันก็ถือว่าตัวเองเป็นผู้เสนอการทดสอบหน่วย


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

11
การทดสอบเก้าอี้: คนนั่งบนเก้าอี้ขับเคลื่อนแอปพลิเคชันรายงานข้อบกพร่อง
jcollum

3
@Darknight ควรมี 50k upvotes สำหรับความซื่อสัตย์ของเขา มาเป็นคนหัวเก่ารับช่วงเวลาของวันนี้ ให้หน่วยทดสอบอึนั้นย้อนกลับไปในยุค 90 ที่เป็นของมัน เสียเวลามากที่สุด เป็นเพียงการนำเสนอเพื่อให้คุณดูมีความสำคัญ แต่ส่วนใหญ่ไม่ได้ทำอะไรเลย เรามีสิ่งที่เรียกว่า IDE ในปัจจุบันเราไม่ได้เขียนโปรแกรมโดยคอนโซลหรือในแผ่นจดบันทึกอีกต่อไป เรารู้ว่ารหัสของเราถูกต้องเพราะเราสามารถเคอร์เซอร์เหนือข้อความและดูค่าได้ ทำการทดสอบหน่วยในอดีตด้วยตัวจับเวลาเก่าอื่น ๆ ทั้งหมด
portfoliobuilder

1
@portfoliobuilder ใช่การเลื่อนดูค่าภายใน IDE ของคุณจะช่วยปรับปรุงคุณภาพโค้ดได้จริงๆ เนื่องจากสถานะจะเหมือนเดิมและรหัสจะไม่เปลี่ยนแปลง ถูกต้อง! และโชคดี.
Franz D.

1
@portfoliobuilder - คุณลืม / s
ocodo

คำตอบ:


112

จากประสบการณ์ของฉันมีปัจจัยหลายประการที่เกี่ยวข้องกับสิ่งนี้:

  1. ฝ่ายบริหารไม่เข้าใจจริงๆว่าการทดสอบหน่วยคืออะไรหรือเหตุใดจึงมีคุณค่าที่แท้จริงสำหรับพวกเขา
  2. ฝ่ายบริหารมีแนวโน้มที่จะให้ความสำคัญกับการจัดส่งผลิตภัณฑ์ที่รวดเร็วและ (ไม่ถูกต้อง) มองว่าการทดสอบหน่วยเป็นการต่อต้านเป้าหมายนั้น
  3. มีความเข้าใจผิดว่าการทดสอบเป็นเพียงความแพร่หลายของ QA เท่านั้น นักพัฒนาเป็นผู้เขียนโค้ดและเขียนแบบทดสอบไม่ได้
  4. มีความเข้าใจผิดกันโดยทั่วไปว่าฝ่ายบริหารจะต้องใช้เงินเพื่อทำการทดสอบหน่วยอย่างถูกต้องแม้ว่าจะมีเครื่องมือให้ใช้ฟรีก็ตาม (แน่นอนว่านักพัฒนาต้องใช้เวลาในการพิจารณา แต่ก็ไม่ได้ห้ามปรามจริงๆ)
  5. คำตอบของ Will จะปัดเศษคำตอบนี้ออก: เป็นการยากมากที่จะกำหนดค่าของรหัสทดสอบ (แก้ไข jcollum)

ตามธรรมชาติแล้วยังมีปัจจัยอื่น ๆ อีก แต่นั่นเป็นเพียงสิ่งที่ฉันพบเจอ


ใช่อธิบายการจัดการของฉันค่อนข้างมากและเราไม่มีการทดสอบ
Ty.

และการรองรับในภาษายอดนิยมบางภาษา (C / C ++) นั้นไม่ดี
Martin Beckett

@mgb - CxxUnit ทำงานได้ดีสำหรับฉัน ...
Dominic Rodger

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

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

87

1) มันยาก
2) ต้องใช้เวลา
3) ยากมากที่จะกำหนดค่าของรหัสทดสอบ

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


11
"การทดสอบหน่วยที่ดีจะลดข้อบกพร่อง แต่รหัสการผลิตที่ดีก็เช่นกัน" - การทดสอบหน่วยที่ดีทำให้สามารถปรับปรุงรหัสการผลิตได้ แม้ว่ารหัสจะเสียในตอนแรก แต่คุณมีความครอบคลุมในการทดสอบที่ดีคุณสามารถ refactor ระบบได้อย่างมั่นใจจนกว่ารหัสจะดี
Esko Luontola

1
Esko นอกจากจะมีความครอบคลุมที่ดีแล้วคุณยังต้องมีการทดสอบที่ดีเพื่อทดสอบบางสิ่ง คุณสามารถครอบคลุมรหัสได้ 100% และทดสอบได้น้อยมาก
Jacob Adams

ตอบโจทย์สุด ๆ ! คุณเคยพูดแบบเดียวกันกับคำตอบของฉันด้วยคำที่น้อยกว่ามาก
ลิ่ม

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

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

72

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

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

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

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

  • ปฏิสัมพันธ์ของผู้ใช้ ครึ่งหนึ่งของแอปพลิเคชันของคุณคือตรรกะของอินเทอร์เฟซผู้ใช้ คุณจะทดสอบด้วยวิธีอัตโนมัติได้อย่างไรซึ่งจะไม่พังทลายหากคุณเลื่อนปุ่ม
  • การโต้ตอบกับ API ภายนอกและเฟรมเวิร์ก หากคุณกำลังเขียนไดรเวอร์เคอร์เนลของ Windows คุณจะทดสอบหน่วยอย่างไร คุณเขียนต้นขั้วสำหรับทุกฟังก์ชั่น IRP และเคอร์เนลที่คุณใช้สร้างการจำลองเคอร์เนล OS อย่างมีประสิทธิภาพหรือไม่?
  • การสื่อสารบนเครือข่ายเป็นสิ่งที่เกิดขึ้นในศตวรรษที่ 21 คุณประสานการทดสอบหน่วยที่ประกอบด้วยส่วนประกอบแบบกระจายหลายตัวได้อย่างไร
  • คุณจะเลือกกรณีทดสอบที่ดีได้อย่างไร? ฉันมักจะเห็นผู้คนพยายาม "ทำสิ่งต่างๆแบบสุ่มโดยวนซ้ำ 1,000 ครั้งและดูว่ามันพัง" หรือไม่ เมื่อคุณทำเช่นนี้ความพยายามจะสูงกว่าผลตอบแทนข้อบกพร่องที่สำคัญจะพลาดไปและการทดสอบหน่วยจะถูกยกเลิก
  • คุณจะทดสอบได้อย่างไรว่ามีคุณสมบัติตรงตามข้อกำหนด?
  • ความรู้เกี่ยวกับรูปแบบในการทดสอบมีน้อยมาก: ต้นขั้วคำตอบสำเร็จรูปการทดสอบการถดถอยเป็นแนวคิดที่คนส่วนใหญ่ไม่รู้ มีกี่คนในที่ทำงานของคุณอ่านหนังสือเกี่ยวกับการทดสอบหน่วย?

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

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


2
ความคิดที่ดี. แต่อย่าเรียกเวลาในการสร้างการทดสอบหน่วยแยกจากเวลาในการสร้างรหัส "ผลิตภัณฑ์"!
Jeff Kotula

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

1
ในไดรเวอร์เคอร์เนลหนึ่งตัวที่ฉันทำงานอยู่ฉันได้ปรับโครงสร้างโค้ดจำนวนมากลงในไลบรารีที่ฉันเชื่อมโยงเข้ากับชุดทดสอบโหมดผู้ใช้ รหัสเฉพาะนี้ไม่เชื่อเรื่องพระเจ้าต่อสิ่งแวดล้อมดังนั้นจึงง่ายพอ ฉันยังไม่ได้ลองใช้ แต่ IRP เช่นระบบไฟล์และฐานข้อมูลควรเป็นที่เยาะเย้ย
George V.Reilly

1
ด้วย Bochs หรือ QEMU คุณสามารถเขียนการจำลองอุปกรณ์ของคุณเพื่อให้ไดรเวอร์เคอร์เนลของคุณพูดด้วย
Zan Lynx

2
@floding คำตอบที่น่าสนใจ ฉันคิดว่าฉันจะต้องไปอ่านหนังสือเกี่ยวกับการทดสอบหน่วย
Dan Rosenstark

28

การทดสอบส่วนใหญ่ไม่ได้ทดสอบอะไรเลย
คุณเขียน fileopen () ฟังก์ชั่นและ unittest ที่ล้มเหลวหากไฟล์ไม่มีอยู่และสำเร็จถ้าไฟล์นั้นมีอยู่ เยี่ยมมาก! ตอนนี้คุณตรวจสอบแล้วว่าใช้งานได้กับชื่อไฟล์ในภาษาจีน BIG5 หรือไม่? บน NFS share? บน vista ด้วยไฟล์บนคีย์ USB และเปิด UAC?

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

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


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

5
องค์ประกอบที่คุณขาดหายไปคือการทดสอบหน่วยไม่ได้เป็นเพียงสิ่งที่ทำครั้งเดียว หากฉันพบในภายหลังว่าฉันต้องแก้ไขข้อบกพร่องด้วย fileopen () บนการแชร์ NFS ฉันสามารถเพิ่มการทดสอบลงในชุดทดสอบของฉันสำหรับสิ่งนี้ จากนั้นเมื่อฉันพัฒนามากขึ้นในอนาคตฉันมีการทดสอบการถดถอย
Paul Osborne

2
ข้อผิดพลาดจำนวนมากเกิดจากการโต้ตอบนอกรหัสที่โปรแกรมเมอร์ไม่ได้นึกถึงและไม่สามารถพบได้เพียงแค่ตรวจสอบโค้ด ปัญหาทั่วไปของ gui คือเครื่องที่มีการตั้งค่า DPI สูง / ต่ำมาก - คุณสามารถทดสอบฟังก์ชั่นไดอะล็อกของหน่วยได้ทั้งหมดที่คุณต้องการ แต่จะไม่เห็นสิ่งนี้
Martin Beckett

5
นั่นไม่ใช่หน้าที่ของการทดสอบหน่วยและการโต้ตอบระหว่างส่วนต่าง ๆ ของโค้ดนั้นสามารถทดสอบหน่วยได้มากและแน่นอนว่าหากส่วนเหล่านั้นถูกเขียนโดยทีมแยกหน่วยทดสอบโค้ดของคุณกับอินเทอร์เฟซที่ใช้ร่วมกันและการเยาะเย้ยองค์ประกอบของทีมอื่น ๆ แนวทางปฏิบัติที่ดี
Steven Evers

1
TDD จัดการปัญหาการทดสอบที่เข้มงวดของ "โปรแกรมเมอร์ที่เขียนโค้ดแล้วก็เขียนการทดสอบด้วย" โดยให้คุณเขียนแบบทดสอบก่อนที่จะเขียนโค้ด
Ophidian


15

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


12

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

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

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

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


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

12

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

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

ในระยะสั้นเราไม่เชื่อใน TDD แต่เราต้องการทดสอบหน่วย เราไม่มีประสบการณ์ในการทำเช่นนั้นและหาได้ไม่ยาก


1
ย้อนกลับไปเมื่อสถานที่ที่ฉันทำงานมี coders มากพอเราได้จับคู่การเขียนโปรแกรม ฉันพบว่ามันมีประสิทธิภาพมากสำหรับคนหนึ่งที่จะเขียนการทดสอบเป็นรหัสอื่น ๆ มันนำไปสู่คำถามที่ชาญฉลาดมากเกี่ยวกับโค้ดด้วย
Zan Lynx

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

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

3
เป็นไปได้อย่างไรที่คุณ "ไม่แน่ใจว่า" จะทดสอบหน่วย แต่เชื่อว่า TDD ทำให้เกิดความคิดสร้างสรรค์และความยืดหยุ่นได้
jcorcoran

1
@Steve 6 ปีต่อมาคงจะดีถ้าคุณเคยแนะนำการทดสอบหน่วย (หรือแม้แต่ TDD) และคุณจะทำต่อไปหรือไม่
Luke Puplett

11

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

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

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


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

ใช้เวลาสองสามนาทีในการเริ่มต้นฮัดสันและเขียนแบบทดสอบหน่วย หากการทดสอบหน่วยอยู่ในรายการ "สิ่งที่ต้องทำ" อยู่แล้วแสดงว่าคุณกำลังทำงานของคุณ คณะกรรมการมักจะประทับใจกับแผนภูมิและภาพที่สวยงามดังนั้นขอแสดงกราฟเทรนด์สวย ๆ จากฮัดสัน;)
Allen Rice

ใช่ มาฟังความจริงกันเถอะ แม้ว่าเราจะใช้เวลาตลอดเวลาในการต่อสู้กับแนวทางปฏิบัติที่ดีที่สุด แต่ก็ไม่ได้ใช้ในโลกแห่งความจริงเสมอไป สงสารน้องจริงๆ
NeedHack

หมอไม่ถามว่าควรล้างมือไหม?
ocodo

7

จากสิ่งที่ฉันได้เห็น บริษัท จำนวนมากมีฐานรหัสขนาดใหญ่และคู่กันสูงซึ่งไม่สามารถทดสอบหน่วยได้จริง นอกจากนี้ยังไม่มีข้อกำหนดที่สามารถทดสอบได้ที่เหมาะสมดังนั้นการทดสอบหน่วยจะทดสอบกับข้อกำหนด "ตามที่สร้างขึ้น" โดยพฤตินัย


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

7

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


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

6

การทดสอบหน่วยควรเป็นเพียงส่วนหนึ่งของเวิร์กโฟลว์การพัฒนาโค้ดเช่นเดียวกับคอมไพเลอร์

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

ผมเชื่อว่านี่คือคำตอบสำหรับคำถามของคุณ"สิ่งที่ขาดหายไปและทำไม บริษัท ไม่ได้ทำการทดสอบหน่วย" :-)


1
+1 สำหรับ "ควรเป็นส่วนหนึ่งของเวิร์กโฟลว์การพัฒนาโค้ด" นักพัฒนามืออาชีพทุกคนควรทำการทดสอบหน่วยของตนเองโดยไม่คำนึงถึงกระบวนการที่เป็นทางการ อาร์กิวเมนต์เท่านั้นที่ถูกต้องเกี่ยวกับเรื่องนี้คือความหมายของการเป็นหน่วย
Dunk

1
@Dunk หากคุณไม่ได้กำหนด "หน่วย" คุณจะบอกว่า "นักพัฒนามืออาชีพควรทำการทดสอบของตนเอง"
ChrisW

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

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

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

5

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


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

1
ใช่นั่นเป็นเหตุผลว่าทำไมฉันถึงบอกว่ามันยากที่จะหาปริมาณประโยชน์ของการทดสอบ
Ovi Tisler

5

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

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

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


5

ผมคิดว่าโปรแกรมเมอร์ต้องเพิ่งเริ่มทำ การทดสอบง่ายๆสองสามอย่างที่จะเริ่มต้นนั้นง่ายต่อการพิสูจน์ว่าเป็นส่วนหนึ่งของการพัฒนา

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

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


4

การทดสอบหน่วยเป็นหนึ่งในคำศัพท์เกี่ยวกับกล่องดำที่คนส่วนใหญ่เคยได้ยิน แต่ไม่รู้ว่าอะไรคือการทดสอบหน่วยเริ่มต้นอย่างไรเขียนอย่างไรวิธีเรียกใช้การทดสอบจริงสิ่งที่ควรทดสอบ ฯลฯ . ฯลฯ ฯลฯ

ในหลาย ๆ กรณีนักพัฒนาที่ไม่แน่ใจนั้นง่ายกว่าที่จะไล่มันออกไปเพราะไม่จำเป็นหรือเป็นไอซิ่งบางอย่างที่ "นักพัฒนาระดับองค์กร" ต้องการเท่านั้น


4

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

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

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

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


3

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


ฉันเห็นด้วย. หากคุณใช้โมเดล / มุมมอง / คอนโทรลเลอร์การทดสอบแบบจำลองและคอนโทรลเลอร์ก็สมเหตุสมผลดี UI มักจะได้รับการทดสอบที่ดีที่สุดโดยมนุษย์
Zan Lynx

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

3

ฉันพลาดการทดสอบหน่วย - มันทำให้ชีวิตง่ายขึ้น

นั่นไม่ใช่เหตุผลที่เพียงพอสำหรับ บริษัท ในการนำการทดสอบหน่วยมาใช้

เหตุผลที่เพียงพออาจ "ถูกกว่า" (และ / หรือ "ดีกว่า"): ซึ่งไม่ใช่เรื่องง่ายที่จะพิสูจน์เกี่ยวกับการทดสอบหน่วย

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

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


3

แน่นอนในโลกแห่งอุดมคติคุณไม่สามารถโต้แย้งการทดสอบหน่วยได้

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

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

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

  • ความซับซ้อนของรหัส: เฉพาะรหัสทดสอบที่ต้องการการทดสอบ วิธีการกำหนดตัวแปรบรรทัดเดียวไม่จำเป็นต้องมีการทดสอบ วิธีการ 50 บรรทัดที่มีหลายเส้นทางของการดำเนินการอาจทำได้

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

และอย่างที่คนอื่น ๆ ชี้ให้เห็นการทดสอบนั้นดีพอ ๆ กับคนที่เขียน


3

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

เหตุผลประการที่สองคือการทดสอบหน่วยสามารถใช้ได้ (ในลักษณะที่สมเหตุสมผล) กับรหัสที่เป็นไปตามมาตรฐานคุณภาพบางอย่างอยู่แล้ว มีโอกาสที่ codebase ที่มีอยู่บางส่วนจะไม่อยู่ในหมวดหมู่นั้น

เหตุผลประการที่สามคือความเกียจคร้านและ / หรือความถูก


3

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

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


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

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

2

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

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

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


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

2

คนเกียจคร้านและยอมรับการเปลี่ยนแปลงเมื่อถูกบังคับเท่านั้น


2

2 เซ็นต์ของฉัน:

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

ดังนั้นมันเป็นเพียงเรื่องของเวลา

มีการอภิปรายของ Martin-Coplien ซึ่ง Bob Martin ยืนยันว่า:

"ในปัจจุบันนี้ผู้พัฒนาขาดความรับผิดชอบในการจัดส่งบรรทัดรหัสที่เขาไม่ได้ดำเนินการในการทดสอบหน่วย"

[ http://www.infoq.com/interviews/coplien-martin-tdd]


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

2

หากคุณต้องการขายทุกคนในการทดสอบให้ทำดังต่อไปนี้:

  1. เขียนแบบทดสอบจำนวนมาก
  2. แจ้งนักพัฒนาคนอื่น ๆ ที่เปลี่ยนรหัสและไม่ผ่านการทดสอบของคุณ
  3. พวกเขาจะแก้ไขรหัสของพวกเขา
  4. ตอนนี้คุณสามารถปล่อยได้โดยไม่มีจุดบกพร่องเหล่านั้น

แม้แต่ผู้จัดการก็เข้าใจเรื่องนี้


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

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

@jcollum ตามปกติมันขึ้นอยู่กับอัตราส่วนต้นทุน / กำไร
quant_dev

2

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


2

เช่นเดียวกับความคิดที่ดีส่วนใหญ่การนำไปใช้มีส่วนเกี่ยวข้องกับการพึ่งพาเส้นทางขององค์กรมากกว่าคุณภาพของความคิด

ใน บริษัท ส่วนใหญ่ที่มีการจัดส่งผลิตภัณฑ์จะมีการสร้างแผนก QA จำนวนมากโดยมีหัวหน้า QA ระดับอาวุโส การทดสอบเป็นฐานของทีม QA

ทีม QA ไม่น่าจะเขียนโค้ดทดสอบหน่วยได้เนื่องจากโดยทั่วไปแล้ว บริษัท จะไม่รับพนักงานในทีม QA ที่มีโค้ดเดอร์สำหรับงานหนัก

ทีมเขียนโปรแกรมไม่เต็มใจที่จะเขียนโค้ดทดสอบเนื่องจากสร้างความขัดแย้งกับทีม QA

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


1

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


คุณควรอ่านลิงก์เกี่ยวกับ ROI
jcollum

1

บริษัท ส่วนใหญ่ไม่มีประโยชน์ ไม่ใช่คนที่คุณ (หรือฉัน) ทำงานให้แน่นอน


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

ถาม: "ทำไม บริษัท อื่น ๆ ถึงไม่ทำ [การทดสอบหน่วย]" ตอบ: "เพราะ บริษัท ส่วนใหญ่ไม่มีประโยชน์" ดูเหมือนคำตอบสำหรับฉัน ...
Roger Lipscombe
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.