ใหม่ต่อการทดสอบหน่วยวิธีการเขียนการทดสอบที่ยอดเยี่ยม? [ปิด]

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

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

ฉันเขียนข้อสอบไปแล้วหลายชั้น แต่ตอนนี้ฉันสงสัยว่าฉันทำถูกไหม

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

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

แก้ไข: ฉันชอบที่จะขอบคุณ Stack Overflow ฉันมีอินพุตที่ยอดเยี่ยมในเวลาน้อยกว่า 15 นาทีที่ตอบเวลาอ่านออนไลน์มากขึ้นที่ฉันเพิ่งทำ

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

ฉันคิดว่าคุณทำผิด

การทดสอบหน่วยควร:

• ทดสอบวิธีหนึ่ง
• ให้ข้อโต้แย้งบางอย่างกับวิธีการนั้น
• ทดสอบว่าผลลัพธ์เป็นไปตามที่คาดไว้

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

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

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

testAdd()
{
    int x = 5;
    int y = -2;
    int expectedResult = 3;
    Calculator calculator = new Calculator();
    int actualResult = calculator.Add(x, y);
    Assert.AreEqual(expectedResult, actualResult);
}

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

สำหรับการทดสอบหน่วยฉันพบทั้ง Test Driven (การทดสอบครั้งแรกรหัสที่สอง) และรหัสแรกการทดสอบที่สองนั้นมีประโยชน์อย่างยิ่ง

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

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

ตัวอย่างง่ายๆเช่นทั้งหมดfunction square(number)นั้นยอดเยี่ยมและทั้งหมดและอาจเป็นตัวเลือกที่ไม่ดีในการใช้เวลาทดสอบจำนวนมาก คนที่ทำตรรกะทางธุรกิจที่สำคัญนั่นคือที่การทดสอบมีความสำคัญ ทดสอบข้อกำหนด อย่าทดสอบท่อประปา หากข้อกำหนดมีการเปลี่ยนแปลงให้คาดเดาว่าจะต้องทำการทดสอบอะไรเช่นกัน

การทดสอบไม่ควรเป็นการทดสอบอย่างแท้จริงว่าฟังก์ชั่น foo เรียกใช้ฟังก์ชันบาร์ 3 ครั้ง ว่าเป็นสิ่งที่ผิด. ตรวจสอบว่าผลลัพธ์และผลข้างเคียงถูกต้องไม่ใช่กลไกภายใน

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

การย้ายรหัสที่มีอยู่เป็นการทดสอบการพัฒนาแบบขับเคลื่อน

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

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

ทำให้การทดสอบของคุณมีขนาดเล็ก: หนึ่งการทดสอบต่อความต้องการ

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

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

ลองเขียนการทดสอบหน่วยก่อนเขียนวิธีการทดสอบ

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

คุณควรทำการทดสอบผลลัพธ์ของวิธีการเสมอไม่ใช่วิธีที่ได้รับผลลัพธ์เหล่านั้น

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

When I'm writing tests for a method, I have the feeling of rewriting a second time what I          
already wrote in the method itself.
My tests just seems so tightly bound to the method (testing all codepath, expecting some    
inner methods to be called a number of times, with certain arguments), that it seems that
if I ever refactor the method, the tests will fail even if the final behavior of the   
method did not change.

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