Đối với một, tôi gần như không bao giờ chỉ ngồi đó và viết bài kiểm tra đơn vị. Các bài kiểm tra đơn vị là một phương tiện để kết thúc, không phải là kết thúc trong chính họ. Chúng là một cách trả lời "mã này có thực hiện nhiệm vụ cơ bản mà nó được cho là không."
Chẳng hạn, một số người sẽ viết một hàm và sau đó mở một phiên tương tác để kiểm tra nó trên một vài giá trị và đảm bảo rằng nó hoạt động:
def fact x
if x == 0
1
else
x * fact(x-1)
end
end
>> fact 10
=> 3628800
>> fact 7
=> 5040
Nhưng bây giờ bạn phát hiện ra một lỗi:
>> fact -1
SystemStackError: stack level too deep
from (irb):2:in `fact'
from (irb):5:in `fact'
from (irb):10
Vì vậy, bạn sửa nó:
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
Nhưng bây giờ bạn thực sự phải kiểm tra để đảm bảo nó vẫn hoạt động:
>> fact 10
=> 3628800
>> fact 7
=> 5040
Như bạn có thể thấy, bạn tiếp tục lặp lại các bài kiểm tra tương tự ... và bạn phải so sánh kết quả một cách trực quan. Kiểm tra đơn vị là một cách để tránh sự lặp lại trong trường hợp này; nó làm giảm bao nhiêu công việc bạn cần làm. Và trong khi đây là một ví dụ nhỏ ngớ ngẩn, trong thế giới thực, nó ngày càng trở nên quan trọng hơn và ngày càng khó kiểm tra bằng tay. Tất nhiên, điều này có nghĩa là mọi người chỉ đơn giản là không kiểm tra các thành phần riêng lẻ; họ chỉ kiểm tra toàn bộ chương trình. Nhưng sau đó, bọ xít mọc lên và chúng khó tìm hơn nhiều. Hoặc có lỗi xảy ra và chúng đã được sửa, nhưng ai đó lại giới thiệu cùng một lỗi, vì không ai thêm trường hợp kiểm tra để đảm bảo điều đó không xảy ra. Hoặc ai đó nhìn vào một đoạn mã lớn và nói "Tôi không biết việc này phải làm gì, vì nó không được ghi chép lại và không có bài kiểm tra nào ... nếu tôi sửa lỗi này, tôi không biết liệu tôi có phá vỡ thứ gì khác hay không; có lẽ tôi sẽ viết lại cái này từ đầu. "
Kiểm tra đơn vị làm giảm tất cả các công việc làm thêm trong những trường hợp này. Cách tốt nhất để khiến họ vui vẻ là đảm bảo rằng mọi người hiểu tất cả các công việc mà họ đang thay thế, và sự linh hoạt thêm đến từ việc biết mỗi đoạn mã phải làm gì. Ở một mức độ nào đó, mọi người cần có thêm một chút kinh nghiệm với việc viết và duy trì một cơ sở mã lớn để hiểu thử nghiệm đơn vị quan trọng như thế nào; nếu tất cả mã của họ là thứ họ viết một lần và vứt đi, họ sẽ không bao giờ có được nó.
Và các bài kiểm tra đơn vị không nên được viết sau khi thực tế, như một việc vặt thêm một khi bạn có mã mà bạn "biết" đã hoạt động. Các bài kiểm tra đơn vị nên được viết trước, hoặc ít nhất (vì đôi khi bạn quên viết chúng trước) ngay sau khi viết mã trong câu hỏi. Đây được gọi là phát triển thử nghiệm điều khiển, và nó có thể giúp làm cho các API của bạn tốt hơn; nếu bạn viết các bài kiểm tra thực hiện API trước, bạn sẽ biết API sử dụng ở đâu trước khi bạn viết mã và có thể thiết kế lại dễ dàng hơn nhiều so với việc bạn chỉ thêm các bài kiểm tra sau đó.
MbUnitthư viện đã thay đổi cuộc đời tôi. Kiểm tra tự động là quan trọng. Kiểm tra tự động tiết kiệm thời gian. Kiểm tra tự động tiết kiệm tiền. Kiểm tra tự động có thể cứu sống. Kiểm tra tự động là cách duy nhất. Tự động kiểm tra là một mạng lưới an toàn khác. Khi tôi là một trong 50 người làm việc trên một kiến trúc khổng lồ, tôi cảm thấy như một viên gạch khác trong một bức tường. Với các bài kiểm tra đơn vị tôi đang kiểm soát.