2008-09-03 15 views
6

Tôi đang làm việc trên bộ kiểm tra hồi quy tự động cho một ứng dụng mà tôi duy trì. Trong khi phát triển thử nghiệm hồi quy tự động, tôi đã chạy qua một số hành vi gần như chắc chắn là một lỗi. Vì vậy, bây giờ, tôi đã sửa đổi kiểm tra hồi quy tự động để không đăng ký lỗi - nó cố tình cho phép hành vi xấu này đi theo, ý tôi là.Tôi có nên tiếp tục đăng ký không thành công không?

Vì vậy, tôi quan tâm đến ý kiến ​​của người khác trên trang web này. Rõ ràng, tôi sẽ thêm một lỗi để theo dõi lỗi của chúng tôi để đảm bảo hành vi lỗi này được khắc phục. Nhưng có bất kỳ lý do thuyết phục (hoặc cách nào) để thay đổi kiểm tra hồi quy để liên tục chỉ ra thất bại hoặc để lại kiểm tra hồi quy bị phá vỡ và không có một thất bại cho đến khi chúng ta có thể sửa chữa hành vi khiếm khuyết? Tôi nghĩ về điều này như một 6 và một nửa tá loại câu hỏi khác nhưng tôi hỏi ở đây vì tôi nghĩ những người khác có thể thấy nó khác đi.


@ Paul Tomblin,

Chỉ cần được rõ ràng - Tôi đã không bao giờ được coi là loại bỏ các bài kiểm tra; Tôi chỉ đơn giản là xem xét sửa đổi điều kiện vượt qua/thất bại để cho phép sự thất bại mà không bị văng lên mặt tôi mỗi khi tôi chạy thử nghiệm.

Tôi hơi lo ngại về lỗi lặp đi lặp lại từ các nguyên nhân đã biết và cuối cùng được xử lý như cảnh báo trong C++. Tôi biết các nhà phát triển thấy cảnh báo trong mã C++ của họ và đơn giản bỏ qua chúng vì họ nghĩ rằng chúng chỉ là tiếng ồn vô dụng. Tôi sợ để lại một thất bại đã biết trong bộ hồi quy có thể khiến mọi người bắt đầu phớt lờ những thứ khác, có thể quan trọng hơn, thất bại.

BTW, vì sợ rằng tôi bị hiểu lầm, tôi coi các cảnh báo trong C++ là một trợ giúp quan trọng trong việc tạo mã mạnh nhưng đánh giá từ các nhà phát triển C++ khác mà tôi đã gặp.

Trả lời

1

Tôi sẽ nói "hell yeah!". Thực tế đơn giản là, nó có thất bại không? Vâng! Sau đó, nó sẽ được đăng nhập. Bạn đang khá nhiều ảnh hưởng đến thử nghiệm của bạn bằng cách cho phép một bài kiểm tra thất bại để vượt qua.

Một điều sẽ liên quan đến cá nhân tôi, đó là nếu tôi đã làm điều này, và đã đi theo một xe buýt, sau đó "vá" có thể không bị xóa, có nghĩa là ngay cả sau khi "bugfix" lỗi vẫn có thể vẫn còn.

Để lại nó vào, cập nhật ghi chú dự án của bạn, có lẽ thậm chí di chuyển mức độ nghiêm trọng xuống (nếu có thể), nhưng chắc chắn không phá vỡ điều đó là kiểm tra các điều bị hỏng;)

5

Nếu bạn ngừng thử nghiệm nó, làm thế nào bạn sẽ biết khi nó được cố định, và quan trọng hơn, làm thế nào bạn sẽ biết nếu nó bị phá vỡ một lần nữa? Tôi chống lại việc thử nghiệm, bởi vì bạn có thể quên thêm nó trở lại.

1

Nó nên vẫn là một thất bại nếu nó không làm những gì được mong đợi.

Nếu không, quá dễ bỏ qua. Giữ mọi thứ đơn giản - nó hoạt động hoặc không. Thất bại hoặc thành công :)

- Kevin Fairchild

0

Có một thử nghiệm không thành công là loại lưới. Có sự khác biệt giữa mã bị hỏng và mã chưa hoàn thành và liệu thử nghiệm có nên được giải quyết ngay lập tức hay không tùy thuộc vào trường hợp kiểm tra không thành công nào hiển thị.

Nếu nó bị hỏng, bạn nên sửa chữa nó sớm hơn là sau này. Nếu nó chưa hoàn thành, xử lý nó khi bạn có thời gian.

Trong cả hai trường hợp, rõ ràng bạn có thể sống với hành vi xấu (hiện tại), do đó, miễn là vấn đề được ghi lại, bạn cũng có thể không có vấn đề gì cho đến khi bạn có thời gian sửa chữa.

1

Trong khi tôi đồng ý với hầu hết những gì Paul nói, phía bên kia của cuộc tranh cãi sẽ là các bài kiểm tra hồi quy, nói đúng, phải thử nghiệm những thay đổi trong hành vi của chương trình, chứ không phải bất kỳ lỗi cũ nào. Họ đặc biệt phải nói với bạn khi bạn đã phá vỡ một cái gì đó mà được sử dụng để làm việc.

Tôi nghĩ điều này sẽ tóm tắt những loại thử nghiệm khác được chạy trên ứng dụng này. Nếu bạn có một số loại hệ thống thử nghiệm đơn vị, có lẽ đó sẽ là một nơi thích hợp hơn cho thử nghiệm này, chứ không phải là trong thử nghiệm hồi quy (ít nhất là cho đến khi lỗi được sửa). Tuy nhiên, nếu các bài kiểm tra hồi quy là các thử nghiệm duy nhất của bạn, tôi có thể sẽ rời khỏi thử nghiệm tại chỗ.

4

Chúng tôi đã thêm tính năng 'báo lại' vào các bài kiểm tra đơn vị của chúng tôi. Điều này cho phép một bài kiểm tra được chú thích với một thuộc tính về cơ bản đã nói 'bỏ qua thất bại trong X tuần kể từ ngày này'. Các nhà phát triển có thể chú thích một bài kiểm tra mà họ biết sẽ không được khắc phục trong một khoảng thời gian, nhưng nó không yêu cầu bất kỳ sự can thiệp nào trong tương lai để kích hoạt lại nó một cách thủ công.

1

Mặc dù tốt nhất là thử nghiệm không thành công khi có lỗi, nhưng đây thường là lựa chọn không thực tế. Khi lần đầu tiên thêm thử nghiệm vào một khu vực, nó đặc biệt dễ bị sa lầy trong các lỗi phát hiện và do đó không hoàn thành mục tiêu chính. Ngoài ra, các kiểm tra thất bại lâu dài trở nên quá nhiều tiếng ồn, dễ dàng hơn và dễ bỏ qua hơn.

Viết các kiểm tra lỗi là một phần của việc sửa lỗi và chỉ thực sự quan trọng khi sửa các lỗi đó là quan trọng. Điều này cần được xác định bởi các ưu tiên về chất lượng và sản phẩm hiện tại của bạn. Nếu bạn xảy ra để tạo ra các xét nghiệm như là một tác dụng phụ của một số nỗ lực khác, đó là tốt đẹp nhưng không được phép làm sao lãng bạn khỏi những ưu tiên thực sự của bạn.

Tôi khuyên bạn nên tạo bất kỳ lỗi nào được phát hiện trong khi cải thiện thử nghiệm thành cảnh báo và gửi lỗi chống lại chúng. Đó là một cách tiếp cận rộng rãi đầu tiên sẽ giúp bạn vượt qua nhiệm vụ hiện tại trong khi cũng thực sự sử dụng những gì bạn học. Các bài kiểm tra sau đó có thể dễ dàng được thực hiện thành thất bại thực sự khi các lỗi được lên kế hoạch sửa lỗi.

Không giống như những người trả lời khác, tôi nghĩ rằng thất bại cũng dễ bỏ qua như cảnh báo, và chi phí đào tạo nhóm của bạn để bỏ qua lỗi là quá cao để cho nó xảy ra. Nếu bạn tạo ra các thử nghiệm không thành công như là một phần của nỗ lực này, bạn sẽ phá hủy tiện ích của bộ kiểm thử hồi quy của bạn khi nhiệm vụ được cải thiện.