Tôi có nên cố tình phá vỡ bản dựng khi phát hiện thấy lỗi trong sản xuất không?

Đối với tôi, có vẻ hợp lý rằng nếu người dùng cuối tìm thấy một lỗi nghiêm trọng trong sản xuất, một thử nghiệm đơn vị bị lỗi phải được thêm vào để khắc phục lỗi đó, do đó cố tình phá vỡ bản dựng cho đến khi lỗi được khắc phục. Lý do của tôi cho điều này là việc xây dựng nên đã thất bại hoàn toàn , nhưng không phải do phạm vi kiểm tra tự động không đầy đủ.

Một số đồng nghiệp của tôi đã không đồng ý nói rằng không nên kiểm tra thử nghiệm đơn vị thất bại. Tôi đồng ý với quan điểm này về mặt thực hành TDD thông thường, nhưng tôi nghĩ rằng các lỗi sản xuất nên được xử lý khác nhau - sau tất cả lý do tại sao bạn muốn cho phép một bản dựng để thành công với những khiếm khuyết đã biết?

Có ai khác đã chứng minh chiến lược để xử lý kịch bản này? Tôi hiểu việc cố tình phá vỡ bản dựng có thể gây rối cho các thành viên khác trong nhóm, nhưng điều đó hoàn toàn phụ thuộc vào cách bạn sử dụng các chi nhánh.

Chiến lược của chúng tôi là:

Kiểm tra trong một bài kiểm tra thất bại, nhưng chú thích nó với @Ignore("fails because of Bug #1234").

Bằng cách đó, bài kiểm tra ở đó, nhưng bản dựng không bị hỏng.

Tất nhiên bạn lưu ý kiểm tra bị bỏ qua trong lỗi db, do đó, @Ignorekiểm tra sẽ bị xóa sau khi kiểm tra được sửa. Điều này cũng phục vụ như là một kiểm tra dễ dàng để sửa lỗi.

Điểm phá vỡ sự xây dựng trong các bài kiểm tra thất bại không phải là bằng cách nào đó khiến nhóm chịu áp lực - đó là để cảnh báo họ về một vấn đề. Khi vấn đề được xác định và đưa vào lỗi DB, sẽ không có vấn đề gì trong việc chạy thử cho mọi bản dựng - bạn biết rằng nó sẽ thất bại.

Tất nhiên, lỗi vẫn phải được sửa. Nhưng lên lịch sửa lỗi là một quyết định kinh doanh và do đó không thực sự là mối quan tâm của nhà phát triển ... Đối với tôi, một khi lỗi được gửi trong lỗi DB, đó không còn là vấn đề của tôi nữa, cho đến khi khách hàng / chủ sở hữu sản phẩm nói với tôi rằng họ muốn sửa .

Tại sao bạn muốn cho phép một bản dựng thành công với các lỗi đã biết?

Bởi vì đôi khi, bạn có những hạn chế về thời gian. Hoặc lỗi nhỏ đến mức không thực sự đáng để trì hoãn việc vận chuyển sản phẩm trong vài ngày cần thiết để kiểm tra và sửa chữa nó.

Ngoài ra, điểm quan trọng trong việc phá vỡ bản dựng mỗi khi bạn tìm thấy lỗi là gì? Nếu bạn tìm thấy nó, hãy sửa nó (hoặc gán nó cho người sẽ sửa nó), mà không làm phiền cả nhóm của bạn. Nếu bạn muốn nhớ sửa lỗi, thì bạn cần đánh dấu nó là rất quan trọng trong hệ thống theo dõi lỗi của bạn.

Các thử nghiệm ở đó để đảm bảo rằng bạn không (giới thiệu lại) vấn đề. Danh sách các bài kiểm tra không thành công không thay thế cho hệ thống theo dõi lỗi. Có một số giá trị trong POV rằng các thử nghiệm thất bại không chỉ là dấu hiệu của lỗi, chúng còn là dấu hiệu của sự thất bại trong quá trình phát triển (từ sự bất cẩn đến sự phụ thuộc được xác định xấu).

"Phá vỡ công trình" có nghĩa là ngăn chặn việc xây dựng hoàn thành thành công . Một bài kiểm tra thất bại không làm điều đó. Đó là một dấu hiệu cho thấy bản dựng có khuyết điểm đã biết, điều này hoàn toàn chính xác.

Hầu hết các máy chủ xây dựng theo dõi trạng thái của các thử nghiệm theo thời gian và sẽ chỉ định một phân loại khác cho một thử nghiệm thất bại vì nó được thêm vào so với hồi quy (thử nghiệm được sử dụng để vượt qua và không còn nữa), và cũng phát hiện sửa đổi trong đó hồi quy đã diễn ra.

Tôi sẽ lập luận rằng bài kiểm tra thất bại nên được thêm vào, nhưng không rõ ràng là "một bài kiểm tra thất bại".

Như @BenVoigt chỉ ra trong câu trả lời của mình , một bài kiểm tra thất bại không nhất thiết là "phá vỡ bản dựng". Tôi đoán thuật ngữ có thể thay đổi từ nhóm này sang nhóm khác, nhưng mã vẫn biên dịch và sản phẩm vẫn có thể xuất xưởng với một bài kiểm tra thất bại.

Những gì bạn nên tự hỏi mình trong tình huống này là,

Các bài kiểm tra có nghĩa là gì để hoàn thành?

Nếu các thử nghiệm ở đó chỉ để làm cho mọi người cảm thấy tốt về mã, thì việc thêm một thử nghiệm thất bại chỉ để làm cho mọi người cảm thấy tồi tệ về mã không có vẻ hiệu quả. Nhưng sau đó, làm thế nào hiệu quả là các bài kiểm tra ở nơi đầu tiên?

Khẳng định của tôi là các bài kiểm tra nên phản ánh các yêu cầu kinh doanh . Vì vậy, nếu một "lỗi" đã được tìm thấy cho thấy một yêu cầu không được đáp ứng đúng, thì đó cũng là một dấu hiệu cho thấy các thử nghiệm không phản ánh đúng hoặc đầy đủ các yêu cầu kinh doanh.

Đó là lỗi cần sửa trước. Bạn không "thêm một bài kiểm tra thất bại." Bạn đang sửa các bài kiểm tra để phản ánh chính xác hơn các yêu cầu kinh doanh. Nếu mã sau đó không vượt qua các thử nghiệm đó, đó là một điều tốt. Nó có nghĩa là các bài kiểm tra đang làm công việc của họ.

Ưu tiên của việc sửa mã là được xác định bởi doanh nghiệp. Nhưng cho đến khi các bài kiểm tra được cố định, ưu tiên đó có thực sự được xác định không? Doanh nghiệp nên được trang bị kiến ​​thức về chính xác những gì đang thất bại, làm thế nào nó thất bại và tại sao nó thất bại để đưa ra quyết định ưu tiên của họ. Các xét nghiệm nên chỉ ra điều này.

Có những bài kiểm tra không vượt qua hoàn toàn không phải là một điều xấu. Nó tạo ra một tạo tác lớn của các vấn đề đã biết được ưu tiên và xử lý tương ứng. Tuy nhiên, có các bài kiểm tra không kiểm tra đầy đủ là một vấn đề. Nó đặt câu hỏi về giá trị của các bài kiểm tra.

Nói cách khác ... Bản dựng đã bị hỏng. Tất cả những gì bạn quyết định là có hay không chú ý đến thực tế đó.

Trong nhóm tự động hóa thử nghiệm của chúng tôi, chúng tôi kiểm tra các thử nghiệm thất bại miễn là chúng không thành công do lỗi của sản phẩm thay vì lỗi trong thử nghiệm. Bằng cách đó, chúng tôi có bằng chứng cho đội dev rằng hey, họ đã phá vỡ nó. Việc phá vỡ bản dựng rất được tán thành, nhưng điều đó không giống như kiểm tra trong các bài kiểm tra hoàn toàn có thể biên dịch được nhưng không thành công.

Viết một bài kiểm tra mà bạn biết sẽ thất bại cho đến khi sửa lỗi là một ý tưởng hay, đó là nền tảng của TDD.

Phá vỡ các bản dựng là một ý tưởng tồi. Tại sao? Bởi vì nó có nghĩa là không có gì có thể di chuyển cho đến khi nó được cố định. Nó chủ yếu ngăn chặn tất cả các khía cạnh khác của sự phát triển.

Ví dụ 1
Điều gì xảy ra nếu ứng dụng của bạn thay đổi lớn, có nhiều thành phần? Điều gì xảy ra nếu các thành phần đó được làm việc bởi các nhóm khác với chu kỳ phát hành riêng của họ? Khó khăn! Họ phải chờ sửa lỗi của bạn!

Ví dụ 2
Điều gì xảy ra nếu lỗi đầu tiên khó sửa và bạn tìm thấy một lỗi khác có mức độ ưu tiên cao hơn? Bạn cũng phá vỡ bản dựng cho lỗi thứ hai? Bây giờ bạn không thể xây dựng cho đến khi cả hai được cố định. Bạn đã tạo ra một phụ thuộc nhân tạo.

Không có lý do hợp lý tại sao thất bại một bài kiểm tra nên dừng một bản dựng. Đây là một quyết định mà nhóm phát triển cần đưa ra (có lẽ với thảo luận về quản lý) cân nhắc những ưu và nhược điểm của việc phát hành một bản dựng với các lỗi đã biết. Điều này rất phổ biến trong phát triển phần mềm, khá nhiều phần mềm chính được phát hành với ít nhất một số vấn đề đã biết.

Nó phụ thuộc vào vai trò của các bài kiểm tra được cho là đóng và cách kết quả của chúng được cho là ảnh hưởng đến hệ thống / quy trình xây dựng được thông qua. Sự hiểu biết của tôi về việc phá vỡ bản dựng cũng giống như của Ben, đồng thời chúng ta không nên cố ý kiểm tra mã phá vỡ các bài kiểm tra hiện có. Nếu những bài kiểm tra đó đến "sau", có thể "không sao" bỏ qua chúng chỉ để làm cho nó bớt gây khó chịu cho người khác, nhưng tôi thấy thực tế này bỏ qua các bài kiểm tra thất bại (để chúng có vẻ vượt qua) khá đáng lo ngại (đặc biệt là như vậy đối với các thử nghiệm đơn vị), trừ khi có một cách để chỉ ra các thử nghiệm như không đỏ cũng không phải xanh.

Tất nhiên, nó phụ thuộc vào lỗi, nhưng nói chung, nếu có lỗi xảy ra mà không được xác định trong quá trình kiểm tra thủ công hoặc tự động, thì điều đó có nghĩa là có một khoảng cách trong phạm vi bảo hiểm của bạn. Tôi chắc chắn sẽ khuyến khích tìm ra nguyên nhân gốc rễ và tát một trường hợp thử nghiệm đơn vị lên trên vấn đề.

Nếu đó là sự cố sản xuất được lên kế hoạch khắc phục nóng từ chi nhánh bảo trì, bạn cũng cần đảm bảo rằng bản sửa lỗi hoạt động trên tuyến chính và nhà phát triển không thể thổi bay sửa lỗi với giải pháp xung đột hợp nhất quá nhiệt tình .

Ngoài ra, tùy thuộc vào chính sách phát hành của bạn, sự hiện diện của các thử nghiệm đơn vị mới được cập nhật có thể giúp xác nhận rằng nhà phát triển đã thực sự khắc phục sự cố, thay vì chỉ thay đổi nó [(sự cố hoặc thử nghiệm?)], Mặc dù điều này phụ thuộc vào việc đã mã hóa yêu cầu chính xác trong các bài kiểm tra đơn vị mới.

Một vấn đề với việc thêm một bài kiểm tra biết thất bại vào bản dựng là nhóm của bạn có thể có thói quen bỏ qua các bài kiểm tra thất bại vì họ cho rằng bản dựng bị lỗi. Nó phụ thuộc vào hệ thống xây dựng của bạn, nhưng nếu một bài kiểm tra thất bại không phải lúc nào cũng có nghĩa là "một cái gì đó vừa bị hỏng" thì thật dễ dàng để ý ít hơn đến các bài kiểm tra thất bại.

Bạn không muốn giúp nhóm của bạn đi vào suy nghĩ đó.

Vì vậy, tôi đồng ý với sleske rằng bạn nên thêm thử nghiệm, nhưng đánh dấu nó là 'bị bỏ qua' cho mục đích xây dựng tự động, cho đến khi lỗi được khắc phục.

Mặc dù tôi nghĩ rằng theo một cách nào đó, bạn nên 'kiểm tra' lỗi dưới dạng thử nghiệm, để khi bạn sửa nó, nó không xảy ra nữa và theo một cách nào đó, hãy ưu tiên nó, tôi nghĩ tốt nhất không nên phá vỡ bản dựng (/ các thử nghiệm) . Lý do là các cam kết phá vỡ xây dựng sau đó sẽ bị ẩn đằng sau bài kiểm tra bị hỏng của bạn. Vì vậy, bằng cách kiểm tra một thử nghiệm bị hỏng cho lỗi này, bạn yêu cầu cả nhóm đặt công việc của họ sang một bên để sửa lỗi này. Nếu điều đó không xảy ra, bạn có thể sẽ phá vỡ các cam kết không thể truy nguyên như vậy.

Do đó, tôi muốn nói rằng tốt hơn hết là cam kết thử nghiệm dưới dạng chờ xử lý và ưu tiên trong nhóm của bạn không có các thử nghiệm đang chờ xử lý.

Một tùy chọn khác là kiểm tra thử nghiệm thất bại vào một nhánh riêng trong hệ thống kiểm soát nguồn của bạn. Tùy thuộc vào thực tiễn của bạn, điều này có thể khả thi hay không. Đôi khi chúng tôi mở một chi nhánh mới cho công việc đang diễn ra, chẳng hạn như sửa một lỗi không tầm thường.