Thay thế cho chỉ số Pass Pass / Broken build?

Khi có một tích hợp liên tục thực hiện các thử nghiệm ở mỗi lần xác nhận, một cách tốt nhất phổ biến là luôn có tất cả các thử nghiệm vượt qua (hay còn gọi là "không phá vỡ bản dựng").

Tôi tìm thấy một số vấn đề với điều đó:

Ví dụ, người ta không thể giúp một dự án nguồn mở bằng cách tạo các thử nghiệm tương ứng với vé. Tôi biết nếu tôi đề xuất Yêu cầu kéo đối với dự án nguồn mở chứa thử nghiệm thất bại, bản dựng sẽ được đánh dấu là không thành công và dự án sẽ không muốn hợp nhất vào kho lưu trữ của nó vì nó sẽ "phá vỡ bản dựng".

Và tôi không tin rằng việc thử nghiệm thất bại trong repo của bạn là một điều tồi tệ , nó giống như có vấn đề mở trong trình theo dõi của bạn. Đây chỉ là những điều chờ đợi để được sửa chữa.

Điều tương tự cũng xảy ra trong một công ty. Nếu bạn làm việc với TDD, bạn không thể viết bài kiểm tra, cam kết và sau đó viết mã logic hoàn thành bài kiểm tra. Điều đó có nghĩa là nếu tôi đã viết 4-5 bài kiểm tra trên máy tính xách tay của mình, tôi không thể cam kết chúng trước khi đi nghỉ. Không ai có thể lấy lại công việc của tôi. Tôi thậm chí không thể "chia sẻ" chúng với đồng nghiệp trừ khi gửi chúng qua email chẳng hạn. Nó cũng ngăn cản làm việc với một người viết các bài kiểm tra, người còn lại viết mô hình.

Tất cả điều đó để nói, tôi đang lạm dụng / hiểu sai quá trình xây dựng / tích hợp liên tục? Dường như với tôi rằng "vượt qua" / "không vượt qua" là một chỉ số quá hẹp.

Có cách nào để tích hợp liên tục và tương thích TDD không?

Có lẽ có một giải pháp / thực hành tiêu chuẩn để phân biệt "các thử nghiệm mới" (có thể thất bại) và "thử nghiệm hồi quy" ( không nên thất bại vì chúng đã từng làm việc)?

Tôi thấy bạn đang ở đâu, nhưng những loại vấn đề này thường được giải quyết theo những cách khác. Có một lý do tốt tại sao đây là giao thức tiêu chuẩn. Nếu ai đó gửi mã không biên dịch, mọi người cập nhật mã của họ sẽ có chương trình không biên dịch . Điều đó bao gồm các lập trình viên hiện đang làm việc trên một cái gì đó hoàn toàn khác biệt và bằng cách nào đó thấy mình trong một tình huống mà họ cần phải chờ đợi trước khi họ có thể biên dịch và kiểm tra những gì họ đang làm việc.

Giao thức chuẩn là bạn có thể cam kết thay đổi ngay cả đối với công việc hoàn thành hoặc thậm chí không hoàn thành, miễn là nó biên dịch để lập trình viên có thể cập nhật mã của họ mỗi ngày nếu cần thiết.

Tuy nhiên, tôi vẫn thấy những gì bạn đang nhận được. Đôi khi bạn muốn cam kết chỉ đơn giản là lưu mã của bạn. Đối với điều này, hầu hết các kho nguồn hỗ trợ phân nhánh. Điều này cho phép bạn tạo một nhánh riêng, làm việc trên nó mà không làm phiền người khác, sau đó hợp nhất vào thân cây khi công việc hoàn thành. Điều này cho phép bạn cam kết khi bạn muốn mà không có bất kỳ phản ứng dữ dội nào liên quan đến việc khiến bản dựng bị phá vỡ.

Nếu điều đó không phù hợp, GIT cho phép bạn cam kết (đẩy) các kho lưu trữ trên máy cục bộ của mình, nhưng có thể hình dung kho lưu trữ có thể ở bất cứ đâu. Bạn có thể tạo một kho lưu trữ cho công việc có khả năng một phần / chưa hoàn thành và một kho lưu trữ khác cho công việc đã hoàn thành và trên kho lưu trữ đó bạn có thể thêm một bản dựng hàng đêm.

Một lần nữa, tôi không thể nhấn mạnh tầm quan trọng đủ. Đừng phạm mã bị hỏng vào thân cây bao giờ! Đóng góp của bạn không thể tác động đến công việc của các lập trình viên khác.

Biên tập

Tôi thấy rằng bạn dự định thử nghiệm bị hỏng, nhưng theo ý kiến ​​khiêm tốn của tôi, có rất ít sự khác biệt. Toàn bộ quan điểm của một bài kiểm tra là xác định xem một khía cạnh cụ thể của chương trình vượt qua hay thất bại. Nếu nó luôn luôn thất bại và bạn không làm gì, thì thử nghiệm, trong cách sử dụng thử nghiệm đơn vị truyền thống, không phục vụ gì cả. Nếu bạn sử dụng nó để thực hiện một số số liệu khác không nhất thiết phải đưa ra một cam kết "không thành công" nếu một thử nghiệm như vậy thất bại, thì tôi thực sự khuyên bạn nên tìm một cách khác để làm điều tương tự.

Mặt khác, bạn có nguy cơ rằng bài kiểm tra không bao giờ được xem xét hoặc nếu nó khiến bản dựng của bạn thất bại, thì các lập trình viên đồng nghiệp của bạn bỏ qua các bản dựng không thành công. Điều quan trọng hơn là các lập trình viên nhận ra khi họ phá vỡ một bản dựng hơn là thực hiện một bài kiểm tra không cung cấp cái nhìn sâu sắc thực sự và chỉ có thể dẫn đến các thực tiễn xấu.

Đưa ra một nhánh chính với các thử nghiệm thất bại, làm thế nào bạn có thể chắc chắn - mà không so sánh danh sách đó với các bản dựng trước - mà bạn chưa giới thiệu các lỗi?

Đơn giản chỉ cần theo dõi số lượng thử nghiệm thất bại là không đủ: bạn có thể sửa một thử nghiệm và phá vỡ một thử nghiệm khác. Và nếu bạn đang trong kỳ nghỉ, sẽ không rõ ràng cho những người khác nhìn vào bản dựng thất bại.

Giữ chi nhánh chính của bạn sạch sẽ và màu xanh lá cây mọi lúc. Làm việc trong một chi nhánh. Giữ chi nhánh dưới CI, trong một công việc riêng biệt và có các bài kiểm tra thất bại đối với nội dung trái tim của bạn. Đừng phá vỡ chủ.

Có người đánh giá của chi nhánh chỉ hợp nhất chi nhánh của bạn nếu nó vượt qua tất cả các bài kiểm tra. (Mạnh mẽ hơn: yêu cầu người đánh giá chỉ có thể hợp nhất chi nhánh của bạn nếu kết quả của việc hợp nhất chi nhánh thành chủ vượt qua tất cả các bài kiểm tra!)

Có nhiều cách để giải quyết vấn đề của bạn mà không vứt bỏ những thực tiễn được hiểu và chấp nhận về tích hợp liên tục.

Tôi sẽ bắt đầu với vấn đề cam kết 'thử nghiệm hỏng' tương ứng với một vé. Một giải pháp là tạo một hoặc nhiều kiểm tra phá vỡ phơi bày vấn đề, sau đó thực sự khắc phục sự cố , để chúng có thể được hợp nhất trở lại dòng mã chính cùng nhau. Giải pháp thứ hai là có các bài kiểm tra bị hỏng, nhưng sử dụng một số loại cờ bỏ qua để chúng không thực sự chạy và phá vỡ bản dựng. Có thể thêm một bình luận hoặc một chú thích đặc biệt làm cho nó rất rõ ràng rằng đây là một bài kiểm tra bị hỏng cho Ticket#N. Cũng đính kèm một ghi chú cho vé tự nó liên quan tới các cuộc thử nghiệm đã tạo được chờ đợi để được unignored và ran. Điều này sẽ giúp một người sửa vé, nhưng cũng không phải là cờ đỏ cho ai đó đi qua bài kiểm tra.

Và vào vấn đề tiếp theo của bạn với TDD. TDD là về việc viết một bài kiểm tra nhỏ và sau đó viết một đoạn mã nhỏ để thực hiện bài kiểm tra đó . Sau đó tiếp tục lặp đi lặp lại cho đến khi bạn có một mô-đun chức năng nhỏ. Tôi cảm thấy rằng nếu bạn viết 4-5 bài kiểm tra, sau đó bạn đi nghỉ, bạn có thể đã làm sai. Bạn có thể ghép chương trình với ai đó theo cách mà một trong hai bạn viết bài kiểm tra, mã kia tương ứng. Tuy nhiên, bạn không nên sử dụng kho lưu trữ dòng mã chính để chia sẻ mã này giữa hai bạn trước khi mô-đun hoàn thành sẵn sàng để được cam kết. Như những người khác đề xuất, một chi nhánh được chia sẻ sẽ giải quyết vấn đề của bạn ở đó.

Cố gắng phá vỡ thần chú tích hợp liên tục có thể dẫn đến những con đường bất ngờ và đáng sợ. Ví dụ, phạm vi bảo hiểm mã có nghĩa là gì trong loại môi trường này ? Làm thế nào các nhà phát triển không cảm thấy rằng hệ thống có nhiều " Windows bị hỏng " ? Làm thế nào một người có thể thay đổi, chạy thử nghiệm và biết liệu họ thực sự đang phá vỡ bất cứ điều gì mới, hay đó chỉ là những thứ cũ?

Tôi nghĩ vấn đề cơ bản của bạn là bạn đang bao gồm KẾT QUẢ kiểm tra như một phần của bản dựng. Trong khi rõ ràng một số người đồng ý với bạn, những người khác thì không. Phá vỡ bản dựng xảy ra khi nó không xây dựng. Không phải khi nó không xây dựng mà không có lỗi.

Hãy xem xét một dự án lớn như Windows hoặc Linux, hoặc thậm chí một cái gì đó như Firefox - bạn có nghĩ rằng chúng không có lỗi không? Dĩ nhiên là không. Bây giờ các dự án này không thực hiện TDD, nhưng điều đó thực sự không liên quan - TDD không thay đổi hai sự thật cơ bản: lỗi tồn tại và cần có thời gian để khắc phục chúng. Thời gian mà một dự án (nguồn mở hoặc không) không thể lãng phí cho các lỗi ưu tiên thấp. KDE gần đây đã có một lỗi đã được sửa hơn một thập kỷ. Lần cuối cùng bạn nghe ai đó nói "Tôi rất vui vì chúng tôi đã đợi một thập kỷ để giao dự án của mình"?

TDD, theo một cách nào đó, có lẽ làm cho nó dễ dàng hơn khi xuất xưởng với các lỗi - bởi vì bạn hiểu rõ hơn về lỗ hổng là gì. Nếu bạn có thể xác định chính xác nguyên nhân gây ra lỗi, bạn có một cơ sở tuyệt vời để cân nhắc chi phí sửa lỗi.

Đề nghị của tôi là tìm một dự án không bận tâm đến màu đỏ.

 > a common best practice is to have all the tests passing (green) at all times.

Tôi thích có tất cả các bài kiểm tra không thất bại (không phải màu đỏ).

Với định nghĩa hơi khác này, bạn cũng có thể xác định các bài kiểm tra

• chưa được triển khai (màu xám trong nunit nếu có NotIm HiệnedException)
• được biết là thất bại = "cần phải làm" bằng cách đánh dấu / chú thích kiểm tra là bỏ qua (màu vàng)

Tôi bạn kiểm tra chúng vào kho lưu trữ bản dựng liên tục của bạn không bị hỏng và do đó hợp lệ.

Bạn có thể xem xét hai khái niệm xây dựng CI khác nhau.

1. Xây dựng CI thường xuyên. Bản dựng CI thông thường sẽ biên dịch và chỉ chạy các thử nghiệm mà mã đã được viết để vượt qua, do đó các báo cáo CI về vượt qua / thất bại là một chỉ báo hồi quy rõ ràng, rõ ràng đối với trạng thái được chấp nhận trước đó của mã.

2. Xây dựng CI "tương lai". Bản dựng này biên dịch và chỉ chạy các thử nghiệm mà không có mã nào được viết riêng để làm cho chúng vượt qua. Có thể có một số lý do để có một bài kiểm tra như vậy:

   • Các thử nghiệm có thể được thêm vào cho các trường hợp lỗi cụ thể từ trình theo dõi sự cố mà chưa có bản sửa lỗi nào được thử. Rõ ràng rất hữu ích khi đã có một bài kiểm tra được mã hóa, đang chạy cho một vấn đề ngay cả khi không có cách khắc phục.

   • Các thử nghiệm được thêm cho chức năng cần thiết mới chưa được thực hiện.

   • Thông thường, dễ dàng biết cách kiểm tra lỗi hoặc tính năng hơn là biết cách triển khai tính năng hoặc sửa lỗi và tách hai bước bằng cách cam kết kiểm tra với kiểm soát nguồn có thể hữu ích để đảm bảo không có thông tin nào bị mất.

Như trong CI "tiêu chuẩn", trong chế độ phát triển thường xuyên, nhóm sẽ chỉ xem xét kết quả xây dựng hàng ngày của bản dựng thông thường.

Nhóm cũng có thể theo dõi sự phát triển của các trường hợp thử nghiệm từ bản dựng CI "tương lai" - đặc biệt để xem liệu có bất kỳ thay đổi nào đối với CI thông thường thực sự khắc phục các sự cố từ bản dựng "tương lai" hay không, có thể là dấu hiệu quan trọng vấn đề cơ bản hoặc cải tiến thiết kế.

Cuối cùng, nếu một thành viên trong nhóm có thêm thời gian trong tay, họ có thể xem xét khắc phục một trong những vấn đề từ "tương lai" và nếu họ thành công di chuyển nó thành "thông thường" (trong khi cập nhật trạng thái theo dõi vấn đề).

Và tôi không tin rằng việc thử nghiệm thất bại trong repo của bạn là một điều tồi tệ, nó giống như có vấn đề mở trong trình theo dõi của bạn. Đây chỉ là những điều chờ đợi để được sửa chữa.

Vấn đề không phải là thất bại trong các bài kiểm tra, đó là một chỉ báo hồi quy đơn giản, ít bối cảnh. Aka: là một nhà phát triển, tôi có thể kiểm tra một chỉ báo duy nhất và biết nếu tôi đã giới thiệu hồi quy hoặc phá mã.

Khoảnh khắc bạn giới thiệu khái niệm về lỗi 'mềm' (không sao, chúng tôi đang làm việc với nó / chưa được triển khai / chúng tôi đang chờ phiên bản mới / nó sẽ qua một lần nữa khi bản dựng khác này được sửa), bạn yêu cầu mọi người có thể chạy hoặc nhìn vào bài kiểm tra để biết trạng thái dự kiến. Mà trong một nhóm đủ lớn sẽ thay đổi theo giờ: chỉ số của bạn trở nên vô nghĩa. Trong một bối cảnh nhỏ hơn (ví dụ thử nghiệm tích hợp riêng tư nhóm), thì tôi nghĩ nó giống như nợ kỹ thuật và vẫn ổn - chỉ cần được quản lý.

Cách mà hầu hết địa chỉ công cụ là 'xanh / chuyển' phản ánh kết quả mong đợi là gì - không phải là mã đang hoạt động:

• Thể hình có khái niệm về sự thất bại dự kiến.
• JUnit có @Ignored / @Test (mong đợi =)
• Dưa chuột có trạng thái 'chưa được triển khai' (hoặc bất cứ điều gì nó được gọi là)

Những vấn đề đi kèm với các vấn đề của riêng họ (làm thế nào để bạn phân biệt giữa 'có, chúng tôi biết nó bị hỏng, làm việc với nó' và 'hành vi đúng là một ngoại lệ') - nhưng chúng giúp ích.

Tôi sử dụng các bài kiểm tra bỏ qua.

Trong khung thử nghiệm đơn vị cụ thể mà tôi sử dụng, tôi có thể đưa ra một ngoại lệ SkipTest. Thử nghiệm không thực sự chạy và thất bại của nó sẽ không phá vỡ bản dựng. Tuy nhiên, tôi có thể thấy số lượng bài kiểm tra bị bỏ qua và xem liệu có công việc phải làm trong khu vực đó không.