สำหรับหนึ่งฉันแทบจะไม่เพียงแค่นั่งที่นั่นและเขียนการทดสอบหน่วย การทดสอบหน่วยเป็นหนทางไปสู่จุดจบไม่ใช่จุดจบในตัวเอง พวกเขาเป็นวิธีการตอบรับ "รหัสนี้ทำหน้าที่พื้นฐานที่ควรจะทำหรือไม่"
ตัวอย่างเช่นบางคนจะเขียนฟังก์ชั่นแล้วเปิดเซสชันแบบโต้ตอบเพื่อทดสอบกับค่าสองสามค่าและตรวจสอบว่าใช้งานได้:
def fact x
if x == 0
1
else
x * fact(x-1)
end
end
>> fact 10
=> 3628800
>> fact 7
=> 5040
แต่ตอนนี้คุณค้นพบข้อบกพร่อง:
>> fact -1
SystemStackError: stack level too deep
from (irb):2:in `fact'
from (irb):5:in `fact'
from (irb):10
ดังนั้นคุณจะแก้ไข:
def fact x
if x < 0
raise "Can't take the factorial of a negative number"
elsif x == 0
1
else
x * fact(x-1)
end
end
>> fact -1
RuntimeError: Can't take the factorial of a negative number
from (irb):3:in `fact'
from (irb):10
แต่ตอนนี้คุณควรทดสอบเพื่อให้แน่ใจว่ายังใช้งานได้:
>> fact 10
=> 3628800
>> fact 7
=> 5040
อย่างที่คุณเห็นคุณทำการทดสอบซ้ำต่อไป ... และคุณต้องเปรียบเทียบผลลัพธ์ด้วยสายตา การทดสอบหน่วยเป็นวิธีการหลีกเลี่ยงการซ้ำซ้อนในกรณีนี้ มันลดปริมาณงานที่คุณต้องทำ และในขณะที่นี่เป็นตัวอย่างเล็ก ๆ น้อย ๆ ที่โง่เง่าในโลกแห่งความจริงมันมีความสำคัญมากขึ้นเรื่อย ๆ และยากขึ้นในการทดสอบด้วยตนเอง แน่นอนว่าสิ่งนี้หมายความว่าผู้คนไม่ได้ทดสอบแต่ละองค์ประกอบ พวกเขาแค่ทดสอบโปรแกรมทั้งหมด แต่แล้วแมลงก็คุดออกและพวกมันก็หายาก หรือข้อผิดพลาดเกิดขึ้นและพวกเขากำลังแก้ไข แต่มีคนแนะนำข้อผิดพลาดเดียวกันอีกครั้งเพราะไม่มีใครเพิ่มกรณีทดสอบเพื่อให้แน่ใจว่าจะไม่เกิดขึ้น หรือใครบางคนดูโค้ดชิ้นใหญ่แล้วบอกว่า "ฉันไม่รู้ว่าควรทำอะไรเพราะมันไม่ได้ทำเป็นเอกสารและไม่มีการทดสอบ ... ถ้าฉันแก้ไขข้อผิดพลาดนี้ฉันก็ไม่รู้ว่าจะทำยังไงดีขึ้นอยู่กับมัน บางทีฉันอาจจะเขียนมันใหม่ตั้งแต่ต้น "
การทดสอบหน่วยลดการทำงานพิเศษทั้งหมดในกรณีเหล่านี้ วิธีที่ดีที่สุดที่จะทำให้พวกเขาสนุกคือการทำให้แน่ใจว่าผู้คนเข้าใจงานทั้งหมดที่พวกเขากำลังเปลี่ยนและความยืดหยุ่นที่เพิ่มขึ้นซึ่งมาจากการรู้ว่าแต่ละชิ้นของรหัสควรทำอะไร ในระดับหนึ่งผู้คนจำเป็นต้องมีประสบการณ์มากขึ้นในการเขียนและการบำรุงรักษารหัสฐานขนาดใหญ่เพื่อทำความเข้าใจว่าการทดสอบหน่วยสำคัญแค่ไหน หากรหัสทั้งหมดของพวกเขาเป็นสิ่งที่พวกเขาเขียนครั้งเดียวและทิ้งพวกเขาจะไม่ได้รับมันเลยทีเดียว
และการทดสอบหน่วยไม่ควรเขียนตามความเป็นจริงเป็นงานพิเศษเมื่อคุณมีรหัสที่คุณ "รู้" ใช้งานได้แล้ว การทดสอบหน่วยควรเขียนขึ้นก่อนหรืออย่างน้อยที่สุด (เนื่องจากบางครั้งคุณลืมที่จะเขียนก่อน) หลังจากเขียนรหัสที่เป็นปัญหา สิ่งนี้เรียกว่าการพัฒนาที่ขับเคลื่อนด้วยการทดสอบและสามารถช่วยทำให้ API ของคุณดีขึ้น ถ้าคุณเขียนการทดสอบที่ใช้งาน API ก่อนคุณจะได้เรียนรู้ว่า API นั้นเป็นความเจ็บปวดที่จะใช้ก่อนที่คุณจะเขียนรหัสและสามารถออกแบบใหม่ได้ง่ายกว่าถ้าคุณเพิ่มการทดสอบในภายหลังเท่านั้น
MbUnitห้องสมุดมีการเปลี่ยนแปลงชีวิตของฉัน การทดสอบอัตโนมัติเป็นสิ่งสำคัญ การทดสอบอัตโนมัติช่วยประหยัดเวลา การทดสอบอัตโนมัติช่วยประหยัดเงิน การทดสอบอัตโนมัติสามารถช่วยชีวิต การทดสอบอัตโนมัติเป็นวิธีเดียว การทดสอบอัตโนมัติเป็นอีกหนึ่งเครือข่ายความปลอดภัย เมื่อฉันเป็นหนึ่งใน 50 คนที่ทำงานเกี่ยวกับสถาปัตยกรรมขนาดใหญ่ฉันรู้สึกเหมือนเป็นอิฐอีกก้อนในกำแพง ด้วยการทดสอบหน่วยฉันอยู่ในการควบคุม