Cuộc thi thử nghiệm đơn vị

Chủ lao động của tôi điều hành một cuộc thi ngày thử nghiệm đơn vị hàng tháng. Cả một ngày dành riêng cho việc viết bài kiểm tra đơn vị - rõ ràng chúng tôi làm nhiều bài kiểm tra hơn trong suốt tháng, nhưng đây là cả một ngày - và "người chiến thắng" của cuộc thi được trao giải thưởng. Tuy nhiên, chúng tôi thấy thật khó để xác định ai là người chiến thắng.

Chúng tôi đã chỉ định điểm cho từng trường hợp thử nghiệm. Vì vậy, nếu bạn đã viết một bài kiểm tra đơn vị như thế này ...

for (int i = 0; i < 100; i++) {
  assertTrue(i*i, square(i));
}

bạn sẽ được 100 điểm. Rõ ràng đây là một ví dụ đơn giản nhưng nó cho thấy các vấn đề với việc gán "điểm" cho từng trường hợp thử nghiệm.

Chúng tôi chủ yếu là một cửa hàng Java & Javascript. Vì vậy, tôi đề nghị đếm số nhánh mã được thử nghiệm dưới dạng số liệu. Chúng ta có thể dễ dàng đếm các nhánh được kiểm tra thông qua một công cụ bao phủ mã (như EclEmma). Tuy nhiên, không chắc chắn làm thế nào chúng tôi sẽ làm điều này với các thử nghiệm Selen của chúng tôi và nhận được phạm vi bảo hiểm mã trên các nguồn Javascript (có ý tưởng nào không?)

Có ai có bất cứ đề nghị nào về cách chúng tôi có thể xác định tốt hơn người chiến thắng của cuộc thi này không?

Biên tập

Tôi biết cách viết bài kiểm tra đơn vị, tôi biết cách viết bài kiểm tra đơn vị hiệu quả, tôi không cần trợ giúp để xác định bài kiểm tra nào. Tôi không kiểm soát được cuộc thi này - cuộc thi sẽ tiếp tục. Vì vậy, hoặc tôi thêm một số đầu vào để làm cho nó tốt hơn hoặc tiếp tục chơi thử nghiệm (vâng, tôi chơi chúng. Tất nhiên tôi chơi chúng. Có giải thưởng để giành chiến thắng)

Biên tập

Câu hỏi này ở đây rõ ràng không phải là một bản sao, mặc dù nó chứa thông tin hữu ích về cách tìm các trường hợp kiểm tra tốt, nó không cung cấp bất kỳ số liệu hữu ích nào để đánh giá sự cạnh tranh.

Có ai có bất cứ đề nghị nào về cách chúng tôi có thể xác định tốt hơn người chiến thắng của cuộc thi này không?

Điều duy nhất có ý nghĩa với tôi là bằng cách bỏ phiếu - mỗi nhà phát triển có thể chỉ định một số điểm cho mọi thử nghiệm của nhà phát triển khác (ngoại trừ chính mình). Có thể 3 điểm cho bài kiểm tra mà anh cho rằng đó là điểm "hiệu quả nhất", 2 điểm cho lần thứ hai và một điểm cho lần thứ ba. Bài kiểm tra có nhiều điểm nhất sẽ thắng. Nó có thể cho kết quả tốt hơn khi việc gán điểm được thực hiện mà không biết trước ai đã viết bài kiểm tra cụ thể.

Như một phần thưởng, bạn sẽ nhận được tất cả các bài kiểm tra của bạn được xem xét.

Vì vậy, nếu bạn đã viết một bài kiểm tra đơn vị như thế này ...

for (int i = 0; i < 100; i++) {
 assertTrue(i*i, square(i));
}

bạn sẽ được 100 điểm.

Tôi sẽ cho người này 0 điểm (ngay cả khi bài kiểm tra đang kiểm tra thứ gì đó thực sự có liên quan), bởi vì các xác nhận trong một vòng lặp có ý nghĩa rất nhỏ và các bài kiểm tra với nhiều khẳng định (đặc biệt là ở dạng vòng lặp hoặc bản đồ) rất khó để làm việc.

Vấn đề cơ bản là có một số liệu không thể [dễ dàng] bị lừa. Một số liệu chỉ dựa trên số lượng xác nhận hoàn toàn giống với các nhà phát triển trả tiền cho mỗi LỘC được viết. Như với pay-by-LỘC dẫn đến mã lớn và không thể duy trì mã, chính sách công ty thực tế của bạn dẫn đến các bài kiểm tra viết vô ích và có thể xấu.

Nếu số lượng khẳng định là không liên quan, thì số lượng thử nghiệm cũng không liên quan. Đây cũng là trường hợp của nhiều số liệu (bao gồm cả số liệu kết hợp) người ta có thể tưởng tượng cho loại tình huống này.

Lý tưởng nhất, bạn sẽ được áp dụng phương pháp hệ thống. Trong thực tế, điều này khó có thể làm việc trong hầu hết các công ty phát triển phần mềm. Vì vậy, tôi có thể đề xuất một vài điều khác:

1. Sử dụng đánh giá cặp cho các bài kiểm tra và có một cái gì đó tương tự với số lượng WTF mỗi phút .

2. Đo lường tác động của các thử nghiệm đó theo thời gian đối với số lượng lỗi . Điều này có một số lợi ích:

   • Có vẻ công bằng,
   • Thực sự có thể được đo nếu bạn thu thập đủ dữ liệu về báo cáo lỗi và số phận của chúng,
   • Là thực sự có giá trị nó!

3. Sử dụng phạm vi bảo hiểm chi nhánh , nhưng kết hợp nó với các số liệu khác (cũng như đánh giá). Bảo hiểm chi nhánh có lợi ích của nó, nhưng kiểm tra mã CRUD chỉ để đạt điểm cao hơn không phải là cách tốt nhất để dành thời gian của nhà phát triển.

4. Quyết định tất cả cùng nhau các số liệu bạn muốn thực thi vào lúc này (những quyết định như vậy có thể không được hoan nghênh hoặc thậm chí có thể có trong một số công ty và nhóm). Thường xuyên xem xét và thay đổi các số liệu, chọn những số liệu có liên quan hơn và đảm bảo mọi người hiểu rõ những gì được đo và làm thế nào.

Tôi cho rằng chủ nhân của bạn tổ chức ngày thử nghiệm đơn vị này để cung cấp cho bạn những người khuyến khích tìm lỗi, để đạt được phạm vi bảo hiểm mã lớn hơn và cuối cùng sẽ có nhiều thử nghiệm hơn, hữu ích mãi mãi về sau.

Vì vậy, tôi nghĩ sẽ có ý nghĩa rằng người chiến thắng nên là nhà phát triển tìm ra nhiều lỗi nhất hoặc nhà phát triển có các thử nghiệm đạt được mức tăng lớn nhất trong phạm vi bảo hiểm mã.

Một bài kiểm tra sẽ kiếm cho bạn một điểm nếu nó khiến một mục mới được mở trong hệ thống theo dõi vấn đề / lỗi / lỗi của bạn. Nếu một mục đã được mở cho vấn đề đó, nó không được tính. Ngoài ra, như được đề xuất trong các nhận xét, lỗi trong mã của riêng bạn không được tính; chỉ có lỗi trong mã của người khác. Thật không may, cách tiếp cận này không mang lại sự hài lòng ngay lập tức vì có thể mất vài ngày cho đến khi tất cả các thử nghiệm thất bại được sàng lọc và các vấn đề tương ứng được mở ra. Ngoài ra, điều này có thể không luôn luôn hoạt động; khi hệ thống của bạn trưởng thành, nó có thể bắt đầu trở nên cực kỳ hiếm khi phát hiện ra lỗi bằng cách thêm các bài kiểm tra.

Sự gia tăng độ bao phủ mã có thể cung cấp một phép đo khách quan hơn về sự cải thiện được thể hiện bằng các thử nghiệm mới. Đầu tiên, tổng phạm vi bảo hiểm sẽ phải được ghi lại vào ngày trước cuộc thi. Sau đó, mỗi nhà phát triển sẽ cần bằng cách nào đó hiển thị mức tăng độ bao phủ mã, kết quả từ các thử nghiệm của họ, mà không tính đến sự gia tăng độ bao phủ mã do các thử nghiệm được viết bởi các nhà phát triển khác. Điều này có nghĩa là bạn có thể sẽ cần một trọng tài sẽ đến từng máy của nhà phát triển và ghi lại phạm vi bảo hiểm mã mới trước khi bất kỳ thử nghiệm nào được thực hiện.

Ngẫu nhiên, xem xét bảo hiểm mã cung cấp phần thưởng công bằng cho những người viết bài kiểm tra thực tế, thay vì làm những điều ngớ ngẩn như ví dụ mà bạn cung cấp trong câu hỏi.