Kiểm tra đơn vị cũ / cũ

Tôi làm việc cho một công ty lớn và tôi chịu trách nhiệm cho một ứng dụng java lớn với hàng ngàn bài kiểm tra. Kể từ khi tôi chuyển sang vai trò này, đã có 200-300 bài kiểm tra bị hỏng (có thể bị hỏng trong nhiều năm). Các bài kiểm tra đã cũ và dễ vỡ và chúng là một mớ hỗn độn của các phụ thuộc spaghetti thường kết thúc bằng dữ liệu hộp cát trực tiếp.

Mục tiêu của tôi là 100% vượt qua các bài kiểm tra để chúng tôi có thể phá vỡ bản dựng trên các bài kiểm tra đơn vị, nhưng tôi không thể làm điều đó cho đến khi tôi giải quyết các bài kiểm tra bị hỏng. Tôi có rất ít ngân sách vì ngân sách bảo trì chủ yếu dành cho hỗ trợ, nhưng nhóm của tôi đã xác định và khắc phục các thử nghiệm trái cây treo thấp (chủ yếu là các vấn đề về cấu hình / tài nguyên cục bộ) và chúng tôi giảm xuống còn 30-40 thử nghiệm thực sự xấu xí.

Một số ý kiến ​​về thực hành tốt nhất là gì? Tôi không nghĩ các bài kiểm tra là có giá trị, nhưng tôi cũng không biết những gì họ đang kiểm tra hoặc tại sao chúng không hoạt động mà không đào sâu, điều này làm mất thời gian và tiền bạc mà chúng ta có thể không có.

Tôi nghĩ rằng chúng ta nên ghi lại trạng thái của các bài kiểm tra bị hỏng bằng bất cứ điều gì chúng ta biết, sau đó xóa hoặc bỏ qua hoàn toàn các bài kiểm tra bị hỏng và nhập một mục công việc / lỗi ưu tiên thấp hơn để điều tra và sửa chúng. Sau đó, chúng tôi sẽ ở mức 100% và bắt đầu nhận được giá trị thực từ các thử nghiệm khác và nếu chúng tôi có một cơn gió bảo trì / tái cấu trúc, chúng tôi sẽ có thể lấy lại chúng.

Điều gì sẽ là cách tiếp cận tốt nhất?

Chỉnh sửa: Tôi nghĩ rằng đây là một câu hỏi khác với câu hỏi này bởi vì tôi có một hướng rõ ràng cho các bài kiểm tra mà chúng ta nên viết trong tương lai, nhưng tôi đã thừa hưởng các bài kiểm tra thất bại để giải quyết trước khi các bài kiểm tra lớn hiện nay có ý nghĩa.

Những gì tôi sẽ làm trước tiên là vô hiệu hóa các bài kiểm tra thất bại và luôn luôn thất bại.

Làm cho nó một thử nghiệm thất bại vấn đề.

Khi bạn điều tra, bạn có thể hỏi những người đã ở với công ty của bạn lâu hơn về họ, có thể có rất nhiều kiến ​​thức của bộ lạc về họ mà bạn có thể ghi lại / nắm bắt. Có thể từ nhật ký VCS của bạn. "Ồ, bài kiểm tra đó đã luôn thất bại kể từ khi chúng tôi nâng cấp lên X" hoặc thông tin khác có thể hữu ích.

Khi bạn biết chức năng đang được thử nghiệm là gì, bạn có thể xác định:

• Chúng tôi có quan tâm đến việc này đang được thử nghiệm không
• Điều này quan trọng như thế nào để được kiểm tra

Và sau đó lập danh sách ưu tiên.

Có khả năng không có gì trong danh sách này đủ quan trọng để có thêm thời gian sau đó vì nó đã bị bỏ qua trong nhiều năm. Vì vậy, tôi sẽ không dành quá nhiều thời gian / tài liệu tài liệu và phân tích tất cả các bài kiểm tra bị hỏng này.

Tôi sẽ làm như sau:

1. Cố gắng xác định chính xác những gì các bài kiểm tra thất bại đang cố gắng xác nhận.

2. Triage - nếu một số bài kiểm tra đang cố kiểm tra những thứ không quan trọng như (một trạng thái cũ) của thế giới, hãy xóa chúng. Nếu bạn nhận ra rằng một số trong số họ đang cố gắng xác nhận một cái gì đó quan trọng, hãy thử xác định xem những thử nghiệm đó có đang thực hiện đúng không. Nếu họ đang kiểm tra không chính xác, hãy làm cho họ kiểm tra chính xác.

3. Khắc phục bất cứ điều gì sai với mã sản xuất của bạn bây giờ khi bạn có các bài kiểm tra tốt.

Hãy nhớ kế toán, mỗi dòng mã là một khoản nợ, nhưng có thể được định giá không chính xác như một tài sản. Các deletequan trọng có thể tạo ra rất nhiều giá trị cho công ty của bạn.

200-300 bài kiểm tra bị hỏng (có thể bị hỏng trong nhiều năm).

Ôi! Tôi đã phải đối mặt với một tình huống tương tự một lần nhưng với 7 thử nghiệm thất bại trong đó nhóm bắt đầu phớt lờ thực tế rằng họ đã thất bại trong nhiều tháng do tâm lý "luôn luôn giòn giã".

Mục tiêu của tôi là 100% vượt qua các bài kiểm tra để chúng tôi có thể phá vỡ bản dựng trên các bài kiểm tra đơn vị, nhưng tôi không thể làm điều đó cho đến khi tôi giải quyết các bài kiểm tra bị hỏng.

Tôi bị ám ảnh bởi một mục tiêu tương tự mặc dù tôi chỉ là một nhà phát triển cơ sở trong đội vì tôi đã nhận thấy một đống mà nhiều bài kiểm tra đã thất bại trong nhiều tháng. Tôi muốn chúng tôi biến những người từ "cảnh báo" thành lỗi xây dựng (có lẽ hơi đáng ghét với phần còn lại của đội).

Tôi nghĩ rằng chúng ta nên ghi lại trạng thái của các bài kiểm tra bị hỏng bằng bất cứ điều gì chúng ta biết, sau đó xóa hoặc bỏ qua hoàn toàn các bài kiểm tra bị hỏng và nhập một mục công việc / lỗi ưu tiên thấp hơn để điều tra và sửa chúng. Sau đó, chúng tôi sẽ ở mức 100% và bắt đầu nhận được giá trị thực từ các thử nghiệm khác và nếu chúng tôi có một cơn gió bảo trì / tái cấu trúc, chúng tôi sẽ có thể lấy lại chúng.

Đây là những suy nghĩ của tôi là tốt. Bạn có thể tạm thời vô hiệu hóa tất cả các bài kiểm tra bị lỗi này và từ từ truy cập chúng và sửa chúng theo thời gian. Điều quan trọng là lên lịch các bản sửa lỗi đó nếu bạn cho rằng chúng thực sự quan trọng, ngay cả khi chúng có mức độ ưu tiên thấp, vì thật dễ dàng để các mục đó không bị trộn lẫn. Ưu tiên của tôi là đảm bảo rằng không có thử nghiệm mới nào được đưa ra mà thất bại.

Giống như bất kỳ loại cảnh báo nào, nếu chúng không phá vỡ tòa nhà, chúng có xu hướng chồng chất nhanh chóng. Điều này giả định rằng loại nhóm năng động trong đó thói quen bỏ qua các cảnh báo (thử nghiệm thất bại trong trường hợp này) có thể nhanh chóng dẫn đến nhiều cảnh báo được đưa ra, và giảm sự cám dỗ để giữ những cảnh báo đó về không.

Một nhóm rất có lương tâm có thể không gặp phải những vấn đề này và tránh đưa ra những cảnh báo mới (thất bại mới trong các bài kiểm tra), nhưng chắc chắn sẽ an toàn hơn một chút và thực hiện chiến lược phòng ngừa bằng cách biến những lỗi này thành lỗi phải sửa trước quá trình hợp nhất.

Vì vậy, đề xuất của tôi giống như của bạn (mặc dù chỉ là một ý kiến ​​mạnh mẽ - có thể phần nào có thể sao lưu điều này bằng các số liệu và một câu trả lời khoa học hơn). Vô hiệu hóa các bài kiểm tra cũ và đưa nó vào lịch trình để cuối cùng sửa chúng. Ưu tiên hàng đầu là đảm bảo rằng vấn đề này không chồng chất và bắt đầu trở nên tồi tệ hơn bằng cách đảm bảo các bài kiểm tra hiện tại thành công cuối cùng sẽ không bị bỏ qua nếu chúng bắt đầu thất bại.

Theo một cách nào đó, bạn may mắn. Tốt hơn là nên thực hiện các bài kiểm tra thất bại và không nên (chúng đưa ra cảnh báo cho bạn ít nhất là có gì đó không đúng) so với các bài kiểm tra vượt qua và không nên (điều này mang lại cho bạn cảm giác an toàn sai lầm).
Tất nhiên nếu bạn có cái trước thì rất có thể bạn cũng có cái sau (vì vậy các bài kiểm tra đã vượt qua nhưng sẽ thất bại).

Như đã nêu, hiện tại hãy vô hiệu hóa các bài kiểm tra thất bại đó nhưng để chúng in một thông báo trong nhật ký kiểm tra của bạn như một lời nhắc nhở liên tục về chúng.
Nhưng bạn chắc chắn nên tìm các tài nguyên để đi qua toàn bộ bộ kiểm tra của mình để tìm và loại bỏ các bài kiểm tra vượt qua và không nên, bởi vì mỗi trong số chúng có nghĩa là có một lỗi trong mã của bạn mà hiện tại bạn không phát hiện ra chu kỳ kiểm tra.

Sử dụng đám mây đen đó treo trên cơ sở mã, bạn có thể có được một số ngân sách để đánh giá đầy đủ các bài kiểm tra của mình, nếu bạn chơi đúng và không chỉ nói với họ rằng bạn nên xem xét một số bài kiểm tra vì chúng dường như thất bại khi họ không nên, nhưng bạn không tin tưởng rằng các thử nghiệm của bạn đang phát hiện lỗi trong mã của bạn một cách chính xác, rằng bộ thử nghiệm không thể được tin cậy để thực hiện công việc của nó.
Khi tôi làm điều đó tại một công ty trước đây, tôi đã làm việc cho một đánh giá như vậy thấy rằng hàng trăm bài kiểm tra được viết với các giả định không chính xác về những gì mã NÊN làm, dẫn đến mã (được viết bằng các giả định không chính xác) đã vượt qua các bài kiểm tra khi thực sự nó không nên có Việc sửa lỗi này đã giải quyết được nhiều lỗi trường hợp góc khó chịu mà (trong khi hầu hết không nghiêm trọng) có thể đã làm sập một số hệ thống quan trọng.

Bất kỳ thử nghiệm đơn vị không thành công sẽ làm cho việc xây dựng bị phá vỡ. Tốt cho bạn để nhận ra nó và thiết lập mục tiêu đó. Tâm trí con người khó có thể bỏ qua bất cứ điều gì hoàn toàn hơn nguồn gốc của một báo động sai lầm dai dẳng .

Vứt những bài kiểm tra này đi và đừng nhìn lại. Nếu họ đã thất bại trong nhiều năm và không được giải quyết cho đến bây giờ thì họ không phải là một ưu tiên.

Đối với kiến ​​thức của bộ lạc, nếu những người có kiến ​​thức về bộ lạc vẫn ở xung quanh thì họ đã sửa các bài kiểm tra thất bại ngay bây giờ. Nếu không, sau đó một lần nữa, đây không phải là một ưu tiên.

Nếu không có kiến ​​thức bộ lạc, bạn và nhóm của bạn phải có quyền sở hữu logic. Các bài kiểm tra thất bại có thể gây hiểu lầm nhiều hơn là hữu ích - thế giới có thể đã tiến lên.

Tạo các thử nghiệm mới có liên quan và tiếp tục viết mã tuyệt vời.