วิธีการอธิบายคุณค่าของการทดสอบหน่วย


30

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

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

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

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


1
ดูเหมือนว่าเวลาที่ฉันถาม "Guy ฐานข้อมูลผู้เชี่ยวชาญ" เหตุใดข้อมูลบัตรเครดิตคือ A. unhashed และ B. เหตุใดเขตข้อมูลหมายเลขโทรศัพท์จึงเป็น nvarchar (MAX) และ C เหตุใดจึงไม่มีความสัมพันธ์ระหว่างตารางใด ๆ เขาไม่ได้รับมัน
มัฟฟินแมน

1
(นี่คือคำตอบประชดประชันมันเป็นเรื่องตลก ) -> (A) หากมีบางคนบุกเข้าไปในเซิร์ฟเวอร์ฐานข้อมูลของคุณคุณมีปัญหาที่ใหญ่กว่า (B) การจัดเก็บข้อมูลราคาถูกและจะเกิดอะไรขึ้นถ้าใครต้องการจัดเก็บข้อมูลเมตาภายในเขตข้อมูล (C) ทารก NoSQL;) ( ให้ฉันย้ำอีกครั้งฉันล้อเล่น )
Darknight

มีทั้งบทเกี่ยวกับเรื่องนี้ในที่ดีเป็นศิลปะของหน่วยทดสอบ
StuperUser

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

2
@ WayneM ออกจาก อย่างจริงจัง.
AK_

คำตอบ:


18

ฉันต้องการแนะนำแนวคิดของการทดสอบหน่วย (และการทดสอบทั่วไป) กับเพื่อนร่วมงานของฉัน

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

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

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

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

ดูเพิ่มเติมนี้หัวข้อที่เกี่ยวข้อง: การทดสอบหน่วยอัตโนมัติ, การทดสอบการรวมหรือการทดสอบการยอมรับ

และรุ่นก่อนหน้าจาก SO: การทดสอบหน่วยคืออะไร


4
+1 สำหรับการใช้งานจริง เราทำสิ่งนี้ใน 50+ dev ของเรา ร้านค้าและมันจับ ทุกครั้งที่เราได้รับอีกหนึ่ง dev เขียนแบบทดสอบพวกเขาติดงอมแงม
เบียร์

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

คุณได้ตรวจสอบการทดสอบในตอนแรกหรือคุณแค่เก็บไว้ด้วยตัวเอง? ฉันสามารถจินตนาการได้ว่าผู้ตรวจสอบจะไม่ตื่นเต้นถ้าฉันเริ่มตรวจสอบในไฟล์ทดสอบโดยไม่ได้รับอนุมัติจากหัวหน้าของฉัน
Frode Akselsen

12

ปัจจัยใหม่โดยไม่ต้องกลัว

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

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

ฉันสามารถพิณบนมากขึ้น แต่นี่คือการคุ้มครองอย่างดีพื้นดินเช่นลุงบ๊อบบน TDDและมาร์ตินฟาวเลอร์บน TDD

การอ้างอิง

โอ้ฉันจะเพิ่มอีกหนึ่งสิ่ง มันจะแสดงให้พวกเขาเห็นว่า TDD บังคับให้มีการออกแบบที่ดีซึ่งช่วยให้คุณจัดการกับการพึ่งพาได้อย่างหมดจด

Bob: "โอ้ c% ^ p! เจ้านายแค่บังคับให้พวกเราทุกคนใช้ MS SQL Server 2008" Jane: "ก็โอเคความเสียหายในการย่อให้เล็กสุดเพราะเรา DI แหล่งข้อมูลและคลาส DAO ของเราฉันดีใจมากที่ TDD สนับสนุน เราไปตามทางนั้น "


4

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

เมื่อเรามีกรณีทดสอบอัตโนมัติที่ดีผลที่ตามมาจะเร็วขึ้นมีความมั่นใจและไม่กลัวการพัฒนา (อาจเป็นการแก้ไขบั๊กการเพิ่มประสิทธิภาพหรือการกู้แฟคตอริ่ง)


4

ทําคณิตศาสตร์

  • t mt = เวลาที่ใช้ในการทดสอบทุกสิ่งที่คุณอาจนึกออกด้วยตนเอง
  • t wt = เวลาที่ใช้ในการเขียนการทดสอบ
  • k = จำนวนครั้งที่คุณอาจต้องทดสอบทุกอย่างก่อนออกรหัสใหม่

    ถ้า (t wt <t mt ) หรือ (t wt <(k * t mt )) ดังนั้นมันจึงไม่ใช่เรื่องง่าย: การเขียนการทดสอบจะช่วยเร่งการพัฒนา

มิฉะนั้นดูอัตราส่วน (t wt / (k * t mt )) หากเป็นจำนวนมากให้รอโอกาสอื่น จัดให้มีเหตุผลอย่างอื่นในการทดสอบการถดถอย

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

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


ฉันให้ +1 คุณ แต่คณิตศาสตร์นั่นดูน่ากลัว!
Wayne Molina

@Wayne เป็นเพียงตัวห้อยพวกเขากำลังข่มขู่ แต่การเขียนโปรแกรมไม่ได้มีไว้สำหรับน้องสาว! ;-)
Steven A. Lowe

1

หนึ่งคำแนะนำถ้าคุณเป็นร้านค้าของ Microsoft: หาเอกสารบางอย่างใน MSDN ที่แนะนำการทดสอบหน่วยหรือ couping หลวมเป็นวิธีที่ดีที่สุด (ผมแน่ใจว่ามีหลายกรณีของนี้ ) และจุดที่มันถ้ามีความขัดแย้ง

มันอาจฟังดูเป็นวิธีที่โหดร้ายในการทำสิ่งต่าง ๆ แต่ฉันพบว่าการใช้คำว่า 'การปฏิบัติที่ดีที่สุด' จะทำให้คุณมีทางยาวโดยเฉพาะกับการจัดการ


1

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

คำสำคัญที่นี่คือวิวัฒนาการไม่ใช่การปฏิวัติ

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