Phần mềm kiểm thử đơn vị có thể được sử dụng để kiểm tra đơn vị không?

QUnit tự quảng cáo trên trang web của mình như thế này:

... có khả năng kiểm tra bất kỳ mã JavaScript chung nào, bao gồm chính nó!

Bạn thực sự có thể sử dụng phần mềm kiểm tra đơn vị để kiểm tra chính nó? Sẽ không có lỗi trong phần mềm có nghĩa là kết quả không đáng tin cậy?

Vâng, nó có thể. JUnit có một bộ thử nghiệm rộng rãi để kiểm tra các tính năng của riêng nó và hỏi bất kỳ tác giả nào bạn thích - họ sẽ nói với bạn rằng đây là điều cần thiết cho năng suất của họ trong việc mở rộng dự án. Có lẽ hầu hết các công cụ kiểm tra đều làm như vậy.

Bí quyết là không có nhu cầu đặc biệt nào để kiểm tra một tính năng mới thực sự sử dụng chính tính năng mới - nó chỉ đơn thuần là phải thực hiện nó và kiểm tra kết quả. Theo cách này, sự tự tin về một phần chức năng của một hệ thống có thể được sử dụng để thiết lập sự tự tin ở một phần lớn hơn nhiều. Điều này tương tự như cách các trình biên dịch tự lưu trữ được bootstrapping và nó là một kỹ thuật cơ bản trong lý thuyết điện toán.

Cuốn sách "Thử nghiệm phát triển theo ví dụ" của Kent Beck thực hiện chính xác điều này: như một ví dụ về TDD, ông đã khởi động một khung kiểm tra ngay từ đầu được sử dụng để phát triển chính nó.

Bạn đã đúng, lỗi trong phần mềm có nghĩa là kết quả không đáng tin cậy. Tuy nhiên, có một cách để làm việc xung quanh nó, và xây dựng một bộ thử nghiệm đáng tin cậy.

Ý tưởng là xây dựng một khai thác thử nghiệm nhỏ để kiểm tra chức năng "cốt lõi" rất cơ bản của từng thành phần của hệ thống thử nghiệm (thông thường, nó bao gồm ít nhất một khung và một máy chạy). Nếu khung kiểm tra đủ linh hoạt, bạn có thể cắm trực tiếp khai thác đó vào hệ thống của mình, bằng cách triển khai giao diện hoặc bằng cách cung cấp một bộ phương thức cần thiết khi triển khai khai thác.

Phần còn lại của chức năng nên được kiểm tra chỉ dựa vào chức năng "cốt lõi", đã được kiểm tra bằng cách sử dụng khai thác. Nếu bạn chỉ sử dụng chức năng từ "lõi" để kiểm tra chức năng không cốt lõi, bạn sẽ có một bộ các bài kiểm tra mà bạn có thể tin tưởng.

Tôi không biết về qunit, nhưng tôi đã thực hiện một số dự án trong đó các phiên bản trước của giải pháp đã được sử dụng để xác thực các phiên bản sau vì vậy tôi không xem đó là một cách tiếp cận không hợp lệ.

Bất kỳ gói thử nghiệm đơn vị nào trong chân không không tích hợp hoặc thử nghiệm UAT đều sẽ dễ bị lỗ hổng trong chính gói thử nghiệm cũng như tất cả các vấn đề tích hợp thông thường mà một bộ thử nghiệm đơn vị không thể bao gồm vì vậy tôi không chắc chắn tôi sẽ đi cho đến nay, việc tự kiểm tra trên cùng một phiên bản còn thiếu sót hơn so với việc tin tưởng các thử nghiệm đơn vị mới trong bất kỳ dự án nào khác.

Từ việc đọc nhanh trang web được liên kết của dự án, có vẻ như họ đang chỉ ra rằng không có trường hợp đặc biệt nào về kịch bản thử nghiệm hoặc các mục tiêu bạn có thể kiểm tra hơn là họ đang quảng cáo rằng thư viện tự kiểm tra là một giải pháp hoàn hảo.

Không, bạn không thể tự kiểm tra phần mềm, ít nhất là không theo cách có thể chấp nhận được trong tình huống kiểm toán. Xác minh độc lập đã trở thành một tiêu chuẩn được thiết lập tốt bởi vì rất ít khả năng hai X (người, khung, công cụ) khác nhau sẽ cùng mắc một lỗi / có cùng một lỗi. Điều này không đảm bảo rằng bất cứ điều gì bạn kiểm tra là thực sự chính xác, nhưng điều đó có nghĩa là ít có khả năng vượt qua bất kỳ bài kiểm tra nào. Tự kiểm tra một cái gì đó thực sự không thể làm tăng sự tự tin của bạn rằng nó hoạt động chính xác, nhưng nó có thể hữu ích như một kiểm tra nhanh và bẩn để giảm thời gian nhận phản hồi.