2009-01-30 5 views
7

Nếu một dự án có một thử nghiệm được thực hiện như là một phần của quy trình xây dựng trên máy xây dựng, nếu một bộ kiểm tra thất bại, toàn bộ quá trình xây dựng có bị lỗi không?
Những điều bạn nên cân nhắc khi trả lời câu hỏi đó là gì? Có vấn đề gì mà các thử nghiệm không thành công?Các thử nghiệm thất bại có nên khiến việc xây dựng liên tục không thành công?


Thông tin cơ bản đã thúc đẩy câu hỏi này:

Hiện nay tôi đang làm việc trên một dự án mà có NUnit bài kiểm tra được thực hiện như một phần của quá trình xây dựng và được thực hiện trên của chúng tôi cruise control .net build máy.

Dự án được sử dụng để thiết lập sao cho nếu có bất kỳ thử nghiệm nào bị lỗi, bản dựng không thành công. Lý do là nếu các kiểm tra thất bại, điều đó có nghĩa là sản phẩm không hoạt động/không hoàn thành/nó là một thất bại của một dự án, và do đó việc xây dựng sẽ thất bại.

Chúng tôi đã thêm một số thử nghiệm mặc dù chúng không thành công, chúng không quan trọng đối với dự án (xem bên dưới để biết thêm chi tiết). Vì vậy, nếu những thử nghiệm đó thất bại, dự án không phải là một thất bại hoàn toàn, và chúng tôi vẫn muốn nó được xây dựng.

Một trong các kiểm tra vượt qua xác minh rằng các đối số không chính xác dẫn đến ngoại lệ, nhưng kiểm tra không vượt qua là kiểm tra tất cả các đối số được phép làm không dẫn đến ngoại lệ. Vì vậy, lớp loại bỏ tất cả các trường hợp không hợp lệ, nhưng cũng có một số trường hợp hợp lệ. Đây không phải là vấn đề đối với dự án, vì các đối số hợp lệ bị từ chối là các trường hợp rìa, mà trên đó ứng dụng sẽ không dựa vào.

Trả lời

15

Nếu có bất kỳ cách nào có thể thực hiện được, hãy thực hiện. Nó làm giảm đáng kể số broken-window-problem:

Trong một hệ thống không có lỗi (có thể nhìn thấy), việc giới thiệu một lỗ hổng nhỏ thường được xem là một ý tưởng rất tồi. Vì vậy, nếu bạn có dự án với trạng thái xanh (không có kiểm tra đơn vị nào bị lỗi) và bạn giới thiệu bài kiểm tra lỗi đầu tiên, thì bạn (và/hoặc các đồng nghiệp của bạn) sẽ có động lực để khắc phục sự cố.

Nếu, ở phía bên kia, có các phép thử không thành công, sau đó thêm một thử nghiệm bị hỏng khác được xem là giữ nguyên trạng thái.

Vì vậy, bạn nên luôn cố gắng giữ tất cả các thử nghiệm đang chạy (và không chỉ là "hầu hết trong số chúng"). Và xử lý mọi thử nghiệm thất bại đơn lẻ là lý do cho việc không xây dựng đi một chặng đường dài hướng tới mục tiêu đó.

+0

+1: "Trường hợp rìa" không phải là lý do. Sửa mã hoặc sửa thử nghiệm. –

+0

"Sự cố cửa sổ bị hỏng" - một liên kết rất hữu ích – legesh

4

Nếu kiểm tra đơn vị không thành công, một số mã không hoạt động như mong đợi. Vì vậy, mã không nên được phát hành.

Mặc dù bạn có thể tạo bản dựng cho mục đích thử nghiệm/sửa lỗi.

2

Nếu bạn cảm thấy rằng một trường hợp đủ quan trọng để viết kiểm tra, thì nếu kiểm tra đó không thành công, phần mềm sẽ không thành công. Dựa trên đó một mình, có, nó nên xem xét việc xây dựng một thất bại và không tiếp tục. Nếu bạn không sử dụng lý do đó, thì ai quyết định thử nghiệm nào không quan trọng? Trường hợp là dòng giữa "nếu điều này không thành công nó, nhưng nếu điều đó không thành công nó không phải là"? Thất bại là thất bại.

1

Tôi nghĩ rằng một thiết lập tốt đẹp như của bạn nên luôn luôn xây dựng thành công, bao gồm tất cả các bài kiểm tra đơn vị được thông qua.

Giống như Gamecat đã nói, bản thân bản dựng đã thành công, nhưng mã này không bao giờ được đưa vào sản xuất.

Hãy tưởng tượng một trong các thành viên trong nhóm của bạn giới thiệu lỗi trong mã mà kiểm tra đơn vị đó (luôn bị lỗi) bao gồm. Nó sẽ không được phát hiện bởi các thử nghiệm kể từ khi bạn cho phép một thử nghiệm luôn thất bại.

Trong nhóm của chúng tôi, chúng tôi có một chính sách đơn giản: nếu tất cả các bài kiểm tra không vượt qua, chúng tôi không chuyển sang sản xuất bằng mã. Điều này cũng rất đơn giản để hiểu cho người quản lý dự án của chúng tôi.

0

Theo ý kiến ​​của tôi, nó thực sự phụ thuộc vào bài kiểm tra đơn vị của bạn, ... nếu bài kiểm tra đơn vị của bạn thực sự là bài kiểm tra UNIT (như họ nên => "tham khảo sách vô tận;)") bởi vì một cái gì đó không hoạt động như ...

nhưng thường xuyên nhất (không may thường thấy), trong rất nhiều dự án, các bài kiểm tra đơn vị này chỉ bao gồm một số 'cạnh' và/hoặc là các bài kiểm tra tích hợp. (vâng, đây là câu trả lời chủ quan;)

viết tắt: bạn có biết các bài kiểm tra đơn vị là tốt: không; khác: xây dựng trên

0

Vấn đề thực sự là với các thử nghiệm không thành công của bạn. Bạn không nên có một bài kiểm tra đơn vị mà nó OK để thất bại vì nó là một trường hợp cạnh. Quyết định xem các trường hợp cạnh là quan trọng hay không - nếu không thì xóa các bài kiểm tra đơn vị; nếu có thì hãy sửa mã.

Giống như một số câu trả lời khác ngụ ý, nó chắc chắn là một mùi mã khi kiểm tra đơn vị thất bại. Nếu bạn sống với mùi thì bạn ít có khả năng để phát hiện các vấn đề tiếp theo

0

Tất cả các câu trả lời đã được tuyệt vời, đây là những gì tôi đã quyết định làm:

Làm các bài kiểm tra (hoặc nếu cần thiết được chia một thử nghiệm thất bại) mà không quan trọng được bỏ qua bởi NUnit (tôi nhớ tính năng này sau khi đặt câu hỏi). Điều này cho phép:

  • Việc xây dựng có thể thất bại nếu bất kỳ thử nghiệm thất bại, do đó làm giảm smelliness
  • Các bài kiểm tra được bỏ qua phải được bênh vực cho người quản lý (bất cứ ai chịu trách nhiệm)
  • Bất kỳ bài kiểm tra mà là dự án bị bỏ qua được đánh dấu theo cách đặc biệt

Tôi nghĩ đó là sự thỏa hiệp tốt nhất, buộc mọi người phải sửa các bài kiểm tra, nhưng không nhất thiết phải ngay lập tức (nhưng họ phải bảo vệ quyết định của họ không sửa nó ngay bây giờ vì mọi người đều biết Họ đã làm).


Điều tôi thực sự đã làm: cố định các bài kiểm tra bị hỏng.