Kiểm thử đơn vị chương trình KHÔNG nên làm gì

Question

Câu hỏi này là về mức độ kiểm tra đơn vị.

Tôi đã viết một chương trình điển hình cập nhật cơ sở dữ liệu với thông tin đến trong các tin nhắn XML. Tôi nghĩ về các bài kiểm tra đơn vị nó cần thiết. Chương trình chèn hoặc cập nhật các bản ghi theo các quy tắc phức tạp, sinh ra nhiều trường hợp khác nhau. Lúc đầu, tôi đã quyết định để kiểm tra một số điều kiện sau đây cho từng trường hợp:

• Số cần thiết của hồ sơ bổ sung
• Các lĩnh vực ghi chèn và cập nhật được điền một cách chính xác
• Không có dữ liệu hiện có, nhưng không liên quan đến dữ liệu đã tải lên đã được thay đổi

Nó đã cho tôi thấy loại thử nghiệm thứ ba thực sự có ý nghĩa. Nhưng chẳng mấy chốc tôi thấy rằng điều này không dễ thực hiện, bởi vì bạn thực sự cần phải gõ snapshot cơ sở dữ liệu và sau đó so sánh nó với cái đã sửa đổi. Tôi nhanh chóng bắt đầu cảm thấy khó chịu vì thực tế tôi cần phải viết các bài kiểm tra này cho các trường hợp sửa đổi cơ sở dữ liệu khác nhau, trong khi các bài kiểm tra này không có giá trị và nhiều thông tin về đặc điểm kỹ thuật và thiết kế mã sản xuất.

Sau đó, tôi nghĩ, có thể, tôi đang thử nghiệm quá nhiều? Và nếu không, vì vậy nếu tôi kiểm tra xem chương trình KHÔNG sửa đổi hồ sơ không thích hợp, thì tại sao tôi không thử nghiệm nó:

• không sửa đổi cơ sở dữ liệu khác
• không xóa các tập tin trên đĩa
• KHÔNG gửi e-mail đến Santa Klaus?

Tôi hoàn toàn bối rối khi vẽ đường biên giới. Bạn sẽ vẽ nó ở đâu?

CẬP NHẬT

Tôi đọc nhiều gợi ý hữu ích trong các câu trả lời và đánh dấu một như các giải pháp, bởi vì nó có những ý tưởng hữu ích hơn đối với tôi, nhưng vẫn còn đó là không rõ ràng đối với tôi làm thế nào để kiểm tra đúng cách cập nhật cơ sở dữ liệu. Liệu nó có kiểm tra ý nghĩa rằng chương trình doen't thay đổi quá nhiều? Và nếu có, thì làm thế nào triệt để?

Answer 1

Nếu ai có một số lượng vô hạn của thời gian và nguồn lực (và không có gì tốt hơn để làm với họ :-), nó sẽ là tốt (mặc dù vẫn còn khá nhàm chán chủ yếu) để kiểm tra tất cả mọi thứ mà có thể để kiểm tra. Tuy nhiên, chúng ta sống trong cuộc sống thực, nơi chúng ta có thời gian và áp lực tài nguyên, do đó chúng ta phải ưu tiên những nỗ lực thử nghiệm của mình. Kent Beck tóm tắt độc đáo như "kiểm tra mọi thứ có thể có thể phá vỡ".

Lưu ý rằng điều này cũng đúng với hội nhập/system/chấp nhận thử nghiệm một mức độ nào, nhưng sự khác biệt là kiểm tra đơn vị được kiểm tra hộp màu trắng, vì vậy bạn có nghĩa vụ phải biết cả hai

• gì mã của bạn nên làm và
• những gì bạn thực sự đã viết.

Điều này cho phép bạn tập trung nỗ lực thử nghiệm đơn vị của mình vào các vấn đề thực sự. Phương thức của bạn có ghi dữ liệu vào luồng đầu ra không? Vâng? Sau đó, nó làm cho cảm giác hoàn hảo để kiểm tra những gì là (không) được viết ở đó. Phương pháp của bạn có liên quan gì đến việc gửi thư không? Không? Sau đó, không có điểm kiểm tra rằng nó không gửi thư cho ông già Noel.

System/nghiệm thu là khác nhau ở chỗ

• họ kiểm tra hộp đen, do đó các tester (nên) làm cho không có giả định về cách thức chương trình được thực sự triển khai và
• họ kiểm tra toàn bộ một phức tạp chương trình nơi có nhiều cơ hội hơn mà các phần khác nhau tương tác với các cách bất ngờ (và có khả năng không mong muốn).

Do đó có ý nghĩa hơn khi tạo một mạng lưới kiểm tra rộng hơn, để kiểm tra nhiều trường hợp "điên" hơn và xác minh thêm những điều mà chương trình cần không.

Answer 2

Bạn vẽ đường tại điểm thử nghiệm ngừng hữu ích và không còn cho bạn biết điều gì đó về số mã của bạn.

Có ích khi biết rằng phần mềm của bạn không gửi email cho ông già Noel? Không. Vậy thì đừng kiểm tra điều đó.

Biết rằng lớp truy cập dữ liệu đang làm điều đúng là hữu ích - rằng các cập nhật phù hợp đang diễn ra.

Answer 3

Sẽ dễ dàng hơn khi kiểm tra những gì cần làm, sau đó không nên làm gì. Một vài ngoại lệ:

• Bảo mật: người dùng có quyền truy cập "quản trị cục bộ" sẽ không thể xem trang "quản trị toàn cầu".
• Trường hợp cạnh: ngày 30 tháng 2 không được phân tích cú pháp là 2011-02-30
• Nội dung rõ ràng trong thông số/phân tích của bạn "Người dùng có thể xem xếp hạng trung bình chứ không phải bản ghi riêng lẻ".

Answer 4

Tôi nghĩ rằng một bài kiểm tra đơn vị tốt là bài kiểm tra tất cả các dòng mã của một hàm và tất cả các yêu cầu/ca sử dụng mà nó bao hàm.

Đối với các chức năng đơn giản, nó thường có nghĩa là kiểm tra chức năng chính xác và lỗi mà nó xử lý và xác minh rằng đó là hành vi mong đợi.

Tôi sẽ vẽ một đường ở đó để kiểm tra đơn vị, tôi cũng sẽ ghi nhớ các mối quan tâm khác mà bạn có và chăm sóc chúng trong thử nghiệm hệ thống hoặc tích hợp. Điều đó có nghĩa là thử nghiệm ứng dụng trong bất kỳ số lượng kịch bản nào và sau đó kiểm tra xem cơ sở dữ liệu vẫn chính xác, không có tệp nào bị xóa và santa không nhận được bất kỳ email nào. Bạn có thể kiểm tra bất kỳ số lượng khả năng nào, tất nhiên những điều không hợp lý hơn bạn thử nghiệm, bạn càng lãng phí thời gian.