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

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

เป็นเรื่องปกติหรือว่าฉันกำลังทำอะไรผิดปกติ?

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

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

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

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

ในที่สุดการทดสอบก็ควรเป็นสองเท่าของเอกสาร! หนึ่งควรเขียนการทดสอบหน่วยในลักษณะที่รหัสตั้งใจจะใช้; เช่นการทดสอบ (และการใช้งาน) ควรจะง่ายวางสิ่งที่ซับซ้อนในการดำเนินการ

หากการทดสอบของคุณเขียนยากรหัสที่ทดสอบนั้นอาจใช้ยาก!

มันคือ.

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

พิจารณารหัสง่ายๆ:

public void SayHello(string personName)
{
    if (personName == null) throw new NullArgumentException("personName");

    Console.WriteLine("Hello, {0}!", personName);
}

การทดสอบจะเป็นอย่างไร? มีอย่างน้อยสี่กรณีทดสอบที่นี่:

1. nullชื่อบุคคล เป็นข้อยกเว้นจริง ๆ แล้วโยน นั่นคือโค้ดทดสอบอย่างน้อยสามบรรทัดที่จะเขียน

2. "Jeff"ชื่อบุคคล เราได้รับคำ"Hello, Jeff!"ตอบหรือไม่? นั่นคือรหัสทดสอบสี่บรรทัด

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

4. ชื่อบุคคลนั้นสั้นพอสำหรับสตริง แต่ยาวเกินกว่าที่จะรวมกับ"Hello, "และเครื่องหมายอัศเจรีย์ จะเกิดอะไรขึ้น¹

ต้องใช้รหัสทดสอบจำนวนมาก ยิ่งไปกว่านั้นชิ้นส่วนพื้นฐานที่สุดของรหัสมักจะต้องการรหัสการติดตั้งซึ่งเริ่มต้นวัตถุที่จำเป็นสำหรับรหัสภายใต้การทดสอบซึ่งมักจะนำไปสู่การเขียนสตับและ mocks ฯลฯ

หากอัตราส่วนมีขนาดใหญ่มากในกรณีนี้คุณอาจตรวจสอบบางสิ่ง:

• มีการทำสำเนารหัสในการทดสอบหรือไม่ ความจริงที่ว่าเป็นรหัสทดสอบไม่ได้หมายความว่ารหัสควรซ้ำ (คัดลอกวาง) ระหว่างการทดสอบที่คล้ายกัน: การทำซ้ำดังกล่าวจะทำให้การบำรุงรักษาการทดสอบเหล่านั้นยาก

• มีการทดสอบซ้ำซ้อนหรือไม่ ตามกฎของหัวแม่มือหากคุณลบการทดสอบหน่วยความครอบคลุมสาขาควรลดลง หากไม่เป็นเช่นนั้นอาจเป็นการระบุว่าไม่จำเป็นต้องทำการทดสอบเนื่องจากเส้นทางนั้นครอบคลุมโดยการทดสอบอื่นแล้ว

• คุณกำลังทดสอบเฉพาะรหัสที่คุณควรทดสอบหรือไม่ คุณไม่ได้คาดหวังให้ทดสอบเฟรมเวิร์กพื้นฐานของไลบรารีของบุคคลที่สาม แต่เฉพาะรหัสของโครงการเท่านั้น

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

หมายเหตุเกี่ยวกับ TDD

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

^{¹ให้nเป็นความยาวสูงสุดของสตริง เราสามารถเรียกSayHelloและผ่านโดยอ้างอิงถึงสตริงที่มีความยาวn - 1 ซึ่งน่าจะใช้ได้ดี ในConsole.WriteLineขั้นตอนนี้การจัดรูปแบบควรจบด้วยสตริงที่มีความยาวn + 8 ซึ่งจะส่งผลให้เกิดข้อยกเว้น อาจเป็นไปได้เนื่องจากข้อ จำกัด ของหน่วยความจำแม้แต่สตริงที่มีอักขระn / 2 จะทำให้เกิดข้อยกเว้น คำถามหนึ่งที่ควรถามคือการทดสอบที่สี่นี้เป็นการทดสอบหน่วย (ดูเหมือนว่าการทดสอบหน่วยหนึ่ง แต่อาจมีผลกระทบที่สูงขึ้นมากในแง่ของทรัพยากรเทียบกับการทดสอบหน่วยโดยเฉลี่ย) และถ้ามันทดสอบรหัสจริงหรือกรอบพื้นฐาน}

ฉันคิดว่ามันสำคัญที่จะต้องแยกความแตกต่างระหว่างกลยุทธ์การทดสอบสองประเภท: การทดสอบหน่วยและการทดสอบการรวม / การยอมรับ

แม้ว่าการทดสอบหน่วยเป็นสิ่งจำเป็นในบางกรณีก็มักจะทำเกินความสิ้นหวัง สิ่งนี้ถูกทำให้แย่ลงโดยการวัดที่ไม่มีความหมายบังคับให้นักพัฒนาเช่น "ความครอบคลุม 100%" http://www.rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste.pdfให้ข้อโต้แย้งที่น่าสนใจสำหรับเรื่องนี้ พิจารณาประเด็นต่อไปนี้ด้วยการทดสอบหน่วยที่ก้าวร้าว:

• การทดสอบที่ไม่มีจุดหมายมากมายที่ไม่ได้บันทึกมูลค่าทางธุรกิจ แต่มีอยู่เพียงเพื่อให้ได้ความครอบคลุมที่ครอบคลุมมากขึ้น 100% ที่ทำงานฉันต้องเขียนการทดสอบหน่วยสำหรับโรงงานที่ไม่ทำอะไรนอกจากสร้างคลาสใหม่ มันไม่เพิ่มคุณค่าใด ๆ หรือวิธีการ. equals () แบบยาวที่สร้างขึ้นโดย Eclipse - ไม่จำเป็นต้องทดสอบสิ่งเหล่านี้
• เพื่อให้การทดสอบง่ายขึ้นนักพัฒนาจะแบ่งขั้นตอนวิธีที่ซับซ้อนออกเป็นหน่วยทดสอบที่เล็กลง ฟังดูเหมือนชนะใช่ไหม? ไม่ใช่ถ้าคุณต้องการเปิด 12 คลาสเพื่อติดตามพา ธ รหัสทั่วไป ในกรณีเหล่านี้การทดสอบหน่วยสามารถลดความสามารถในการอ่านรหัสได้ ปัญหาอีกข้อหนึ่งคือถ้าคุณสับโค้ดของคุณเป็นชิ้นเล็กเกินไปคุณจะพบว่ามีคลาส (หรือส่วนของโค้ด) ที่ดูเหมือนว่าจะไม่มีเหตุผลใดเลยนอกจากจะเป็นเซตย่อยของโค้ดอีกชุดหนึ่ง
• Refactoring รหัส coveraged สูงอาจเป็นเรื่องยากที่คุณยังต้องรักษาความอุดมสมบูรณ์ของการทดสอบหน่วยที่ขึ้นอยู่กับการทำงานเพียงเพื่อให้ สิ่งนี้ทวีความรุนแรงมากขึ้นโดยการทดสอบหน่วยพฤติกรรมซึ่งส่วนหนึ่งของการทดสอบของคุณยังตรวจสอบการมีปฏิสัมพันธ์ของผู้ทำงานร่วมกันของชั้นเรียน (มักจะล้อเลียน)

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

ร้านค้าหลายแห่งเมาสุรา kdd ช่วย แต่เมื่อลิงก์ด้านบนแสดงให้เห็นการศึกษาจำนวนมากแสดงให้เห็นว่าประโยชน์ของมันไม่สามารถสรุปได้

ไม่สามารถวางนัยทั่วไปได้

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

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

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

ซึ่งหมายความว่า:

• หากคุณเขียนการทดสอบที่ล้มเหลวให้ทำการแก้ไขรหัสด้วยสิ่งที่ง่ายที่สุดที่ทำงานได้สั้นกว่าการเขียนแบบทดสอบ
• ถ้าคุณเขียนการทดสอบที่ผ่านแล้วคุณไม่มีรหัสพิเศษในการเขียนใช้เวลาในการเขียนการทดสอบมากกว่ารหัสอย่างมีประสิทธิภาพ

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

ใช่ถ้าคุณกำลังพูดถึงการเขียนข้อสอบหลังจากข้อเท็จจริงคุณจะใช้เวลามากขึ้น:

• การกำหนดพฤติกรรมที่ต้องการ
• การกำหนดวิธีการทดสอบพฤติกรรมที่ต้องการ
• การเติมเต็มการพึ่งพารหัสเพื่อให้สามารถเขียนการทดสอบ
• การแก้ไขรหัสสำหรับการทดสอบที่ล้มเหลว

กว่าที่คุณจะใช้จ่ายการเขียนรหัสจริง

ใช่มันเป็นมาตรการที่คาดหวัง

ฉันพบว่ามันเป็นส่วนที่สำคัญที่สุด

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

นี่คือเหตุผลที่หนึ่งในคำตอบอื่น ๆ ในหน้านี้พูดถึงว่าใน "หลักสูตร" พวกเขาทำการทดสอบ 90% เพราะทุกคนต้องการเรียนรู้คำเตือนของวัตถุประสงค์ของพวกเขา

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

อาจเป็นสำหรับคนจำนวนมาก แต่ก็ขึ้นอยู่กับ

หากคุณกำลังเขียนการทดสอบครั้งแรก (TDD) คุณอาจประสบกับการทับซ้อนกันในเวลาที่ใช้ในการเขียนการทดสอบมีประโยชน์อย่างมากในการเขียนรหัส พิจารณา:

• การกำหนดผลลัพธ์และอินพุต (พารามิเตอร์)
• อนุสัญญาการตั้งชื่อ
• โครงสร้าง - สถานที่ที่จะวางสิ่งต่าง ๆ
• ความคิดเก่าธรรมดา

เมื่อเขียนการทดสอบหลังจากเขียนโค้ดคุณอาจพบว่ารหัสของคุณนั้นไม่สามารถทดสอบได้ง่ายดังนั้นการทดสอบการเขียนจึงยากขึ้น / ใช้เวลานานขึ้น

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

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

ในบางจุดเราทุกคนสามารถเขียนโค้ดที่ดีได้ดังนั้นเครื่องมือและเทคนิคบางอย่างสามารถให้การพัฒนาทักษะของเราได้มาก มันไม่เหมือนกับที่ฉันสามารถสร้างบ้านได้ถ้าฉันเห็นเลเซอร์นำทางเท่านั้น

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

ใช่แล้ว. มีข้อแม้บ้าง

ประการแรกมันเป็น "ปกติ" ในแง่ที่ว่าร้านค้าขนาดใหญ่ส่วนใหญ่ทำงานในลักษณะนี้ดังนั้นแม้ว่าวิธีนี้จะถูกเข้าใจผิดและเป็นใบ้อย่างสมบูรณ์ แต่ความจริงที่ว่าร้านค้าขนาดใหญ่ส่วนใหญ่ทำงานด้วยวิธีนี้ทำให้ "ปกติ"

จากนี้ฉันไม่ได้หมายความว่าการทดสอบมันผิด ฉันทำงานในสภาพแวดล้อมที่ไม่มีการทดสอบและในสภาพแวดล้อมที่มีการทดสอบแบบย้ำคิดย้ำทำและฉันยังสามารถบอกคุณได้ว่าแม้การทดสอบแบบย้ำคิดย้ำทำก็ดีกว่าไม่มีการทดสอบ

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

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

ในคำนำของ Roy Osherove's Art of Unit Testing (Manning, 2009) ผู้เขียนยอมรับว่ามีส่วนร่วมในโครงการที่ล้มเหลวเป็นส่วนใหญ่เนื่องจากภาระการพัฒนาอย่างมากที่กำหนดโดยการทดสอบหน่วยที่ออกแบบมาไม่ดีซึ่งต้องรักษาตลอด ระยะเวลาของความพยายามในการพัฒนา ดังนั้นหากคุณพบว่าตัวเองใช้เวลามากเกินไปที่จะไม่ทำอะไรนอกจากทำแบบทดสอบนี่ไม่ได้แปลว่าคุณอยู่ในเส้นทางที่ถูกต้องเพราะมันเป็น "ปกติ" ความพยายามในการพัฒนาของคุณอาจเข้าสู่โหมดที่ไม่แข็งแรงซึ่งอาจจำเป็นต้องทบทวนวิธีการทดสอบของคุณอย่างรุนแรงเพื่อบันทึกโครงการ

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

• ใช่สำหรับการเขียนการทดสอบหน่วย (ทดสอบโมดูลแยก) ถ้ารหัสมีการเชื่อมโยงอย่างสูง (แบบดั้งเดิมไม่ต้องแยกจากข้อกังวลมากพอขาดการพึ่งพาการฉีดไม่ได้พัฒนา tdd )
• ใช่สำหรับการเขียนการรวม / การยอมรับการทดสอบหากตรรกะที่จะทดสอบสามารถเข้าถึงได้ผ่านทางgui-code เท่านั้น
• ไม่สำหรับการเขียนการรวม / การยอมรับการทดสอบตราบใดที่ gui-code และตรรกะทางธุรกิจถูกแยกออก (การทดสอบไม่จำเป็นต้องโต้ตอบกับ gui)
• ไม่มีสำหรับการเขียนการทดสอบหน่วยหากมีการแยกความกังวล, การพึ่งพาการฉีด, รหัสถูกทดสอบขับ developped (tdd)