Chúng ta có nên luôn kiểm tra lỗi đơn vị khi sửa chúng không?

Khi sửa lỗi, trước tiên tôi nên viết một bài kiểm tra không thành công với lỗi đã cho, sau đó sửa mã cho đến khi kiểm tra vượt qua. Điều này tuân theo các thực tiễn TDD, và được cho là thực hành tốt, nhưng tôi nhận thấy nó có xu hướng tạo ra các bài kiểm tra mật mã thực sự gần với việc thực hiện.

Chẳng hạn, chúng tôi gặp vấn đề khi một công việc được gửi đi, đạt đến một trạng thái nhất định, bị hủy bỏ và thử lại. Để tái tạo lỗi này, một bài kiểm tra lớn đã được viết với sự đồng bộ hóa luồng trong đó, rất nhiều lời chế giễu và công cụ ... Nó đã thực hiện được, nhưng bây giờ tôi đang cấu trúc lại mã, tôi thấy rất khó để loại bỏ con voi ma mút này, vì nó thực sự sẽ đòi hỏi rất nhiều công việc (một lần nữa) để phù hợp với thiết kế mới. Và nó chỉ thử nghiệm một tính năng nhỏ trong một trường hợp cụ thể.

Do đó, câu hỏi của tôi: làm thế nào để bạn kiểm tra các lỗi khó sinh sản? Làm thế nào để bạn tránh tạo ra những thứ kiểm tra việc thực hiện, và làm tổn thương tái cấu trúc và khả năng đọc?

Vâng, nói chung bạn nên . Như với tất cả các hướng dẫn, bạn sẽ cần sử dụng phán đoán tốt nhất của mình khi chúng chạy ngược lại các hướng dẫn khác. Đối với kịch bản này, mức độ nghiêm trọng của lỗi cần phải được cân nhắc với công việc cần thiết để thực hiện thử nghiệm và chất lượng của thử nghiệm đó khi nhắm vào vấn đề kinh doanh và nắm bắt hồi quy trạng thái của lỗi.

Tôi có xu hướng ủng hộ các bài kiểm tra viết hơn là không, vì các gián đoạn để chạy các lỗi có xu hướng có nhiều chi phí hơn là chỉ đơn giản là phát triển và duy trì một bài kiểm tra đơn vị.

Tôi nghĩ rằng cách thực hành tốt nhất - tôi cảm thấy xấu hổ khi thừa nhận mình không thường xuyên làm theo - là tạo ra một thử nghiệm hệ thống hoặc tích hợp thể hiện vấn đề quan sát được trong sản xuất, sau đó nghiên cứu để tìm (các) đơn vị chịu trách nhiệm cho vấn đề này, và sau đó viết bài kiểm tra đơn vị cho những đơn vị thể hiện vấn đề ở cấp độ đơn vị . Khi bạn có các bài kiểm tra đơn vị, sửa chữa các đơn vị và chạy tất cả các bài kiểm tra. Tại thời điểm này, có thể nên thận trọng loại bỏ thử nghiệm ban đầu - bởi vì nó có thể dễ vỡ và / hoặc chậm - nhưng hãy giữ các thử nghiệm đơn vị trong bộ tự động của bạn để phục hồi và bảo hiểm.

Việc thực hành viết một bài kiểm tra để xác định lỗi là một ý tưởng tốt, vì nó cho phép bạn xác định chính xác các bước cần thiết để tái tạo lỗi và xác minh rằng nó đã được sửa. Ngoài ra, các thử nghiệm này có thể được chạy như một phần của thử nghiệm khói hoặc thử nghiệm hồi quy để đảm bảo rằng các thay đổi sau này không giới thiệu lại một khiếm khuyết cũ vào hệ thống.

Điều đầu tiên cần xem xét là mức độ thử nghiệm cần thiết. Có lẽ thử nghiệm để xác minh sửa chữa sẽ phù hợp hơn ở cấp độ hệ thống hoặc thậm chí có thể là thử nghiệm chấp nhận được thực hiện thủ công. Tôi nghĩ điều quan trọng hơn là phải có một bài kiểm tra được ghi lại và quản lý, bất kể nó được thực hiện cụ thể như thế nào.

Theo như cách tái cấu trúc ảnh hưởng đến các bài kiểm tra, nó phụ thuộc vào các đặc điểm cụ thể. Trong một số trường hợp, tái cấu trúc (hoặc bất kỳ loại công việc nào, chẳng hạn như các tính năng mới) có thể làm cho các bài kiểm tra không còn cần thiết nữa. Vấn đề, như nó ban đầu xảy ra, có thể không còn có thể. Trong trường hợp đó, có thể là khôn ngoan khi loại bỏ thử nghiệm khỏi các thử nghiệm có thể để làm cho quá trình thử nghiệm của bạn (tự động hoặc thủ công) gọn gàng hơn. Trong các trường hợp khác, có nhiều phương pháp thực hiện kiểm tra và xác minh tính năng ở một mức độ khác nhau có thể phù hợp hơn. Nếu tính năng này là nhỏ, có lẽ thử nghiệm không còn cần thiết nữa.

Bạn cũng có thể xem xét không chỉ dựa vào thử nghiệm, mà còn đăng nhập. Ví dụ: nắm bắt thông tin trong thời gian chạy (với mức độ chi tiết khác nhau tùy thuộc vào môi trường - dài dòng hơn trong quá trình thử nghiệm, ít dài dòng hơn trong khi triển khai), định hình ứng dụng, nắm bắt các trạng thái hiện tại của hệ thống. Nếu bạn có thể tìm thấy các tác nhân phổ biến cho vấn đề, bạn có thể sử dụng nó để hướng dẫn kiểm tra ở tất cả các cấp.

Vâng, bạn nên.

Viết kiểm tra đơn vị cho cơ sở mã hiện có. Khi sửa lỗi, bạn cần đảm bảo rằng bài kiểm tra đơn vị của bạn không thành công - điều này sẽ giúp bạn tự tin rằng bạn thực sự đang làm việc với một lỗi. Sau đó, bạn cần phải xác định lại và thực hiện kiểm tra vượt qua bằng cách sửa lỗi.

Đây không phải là một thực hành TDD mặc dù. Trong các bài kiểm tra TDD điều khiển thiết kế của bạn, nhưng trong trường hợp của bạn, thiết kế đã được quyết định.