Kiểm tra tích hợp, nhưng bao nhiêu?


8

Một cuộc tranh luận gần đây trong nhóm của tôi làm tôi tự hỏi. Chủ đề cơ bản là chúng ta sẽ chi trả bao nhiêu và những gì với các bài kiểm tra chức năng / tích hợp (chắc chắn, chúng không giống nhau nhưng ví dụ là giả khi không quan trọng).

Giả sử bạn có một lớp "trình điều khiển" giống như:

public class SomeController {
    @Autowired Validator val;
    @Autowired DataAccess da;
    @Autowired SomeTransformer tr;
    @Autowired Calculator calc;

    public boolean doCheck(Input input) {
        if (val.validate(input)) {
             return false;
        }

        List<Stuff> stuffs = da.loadStuffs(input);
        if (stuffs.isEmpty()) {
             return false;
        }

        BusinessStuff businessStuff = tr.transform(stuffs);
        if (null == businessStuff) {
            return false;
        }

       return calc.check(businessStuff);
    }
}

Chúng tôi cần rất nhiều thử nghiệm đơn vị để chắc chắn (ví dụ: nếu xác thực không thành công hoặc không có dữ liệu trong DB, ...), đó là điều không thể.

Vấn đề chính của chúng tôi và về những gì chúng tôi không thể đồng ý là có bao nhiêu bài kiểm tra tích hợp sẽ bao gồm nó :-)

Tôi đứng về phía chúng ta sẽ nhắm đến các thử nghiệm tích hợp ít hơn (kim tự tháp thử nghiệm). Những gì tôi sẽ trình bày từ đây chỉ là một con đường hạnh phúc - không vui khi thực thi trở lại từ dòng cuối cùng, chỉ để xem nếu tôi đặt những thứ này lại với nhau thì nó sẽ không nổ tung.

Vấn đề là không dễ để biết tại sao thử nghiệm lại cho kết quả sai và điều đó khiến một số kẻ cảm thấy khó chịu về nó (ví dụ: nếu chúng ta chỉ kiểm tra giá trị trả về, thì ẩn rằng thử nghiệm có màu xanh lá cây bởi vì ai đó đã thay đổi xác nhận và nó trả về false). Chắc chắn, vâng, chúng tôi có thể bao gồm tất cả các trường hợp nhưng đó sẽ là một imho quá mức cần thiết.

Có ai có một quy tắc tốt cho loại vấn đề này? Hoặc một đề nghị? Đọc hiểu? Nói chuyện? Bài viết trên blog? Bất cứ điều gì về chủ đề này?

Cảm ơn rất nhiều trước!

PS: Sry cho ví dụ xấu xí nhưng thật khó để dịch một phần mã cụ thể thành một ví dụ. Vâng, người ta có thể tranh luận về việc ném ngoại lệ / sử dụng loại trả lại khác / v.v. nhưng bàn tay của chúng ta ít nhiều bị ràng buộc vì sự phụ thuộc bên ngoài.

PS2: Tôi đã chuyển chủ đề này từ SO ở đây (câu hỏi ban đầu, được đánh dấu tạm dừng )

Câu trả lời:


6

Có một trường phái suy nghĩ nghiêm túc đặt câu hỏi về giá trị của các bài kiểm tra tích hợp.

Tôi nghi ngờ bạn sẽ nhận được một loạt các câu trả lời ở đây, nhưng theo tôi, bạn chỉ nên sử dụng chúng khi chúng mang lại giá trị rõ ràng.

Đầu tiên, bạn nên viết càng nhiều bài kiểm tra đơn vị càng tốt, vì a) chúng rẻ và b) chúng có thể là các bài kiểm tra duy nhất chạy trên máy chủ bản dựng (nếu bạn có bài kiểm tra).

Thật hấp dẫn khi viết các bài kiểm tra phía máy khách để xác minh cơ sở dữ liệu hoặc một số lớp khác nhưng những điều này thực sự sẽ xảy ra ở mức thích hợp nếu có thể thay vì thực hiện kiểm tra tích hợp. Điều này tất nhiên có thể yêu cầu một số nền tảng dưới dạng giao diện, vv để có được chế giễu và tương tự làm việc.

Cũng xem xét phạm vi thử nghiệm của bạn. Nếu bạn chỉ đơn giản viết một bài kiểm tra tích hợp để che giấu những gì xảy ra dù sao khi bộ của bạn đang chạy hoặc sao chép một bài kiểm tra khói, thì điều này có giá trị hạn chế. Ngoài ra, hãy suy nghĩ về việc đăng nhập nhiều hơn vào những nơi thích hợp sẽ là một lựa chọn tốt hơn thay vì nhận được một thông điệp tối nghĩa từ hàng tá các thành phần được kết nối với nhau và phải theo dõi nó.

Vì vậy, giả sử bạn đã quyết định viết một số, bạn cần suy nghĩ khi nào họ sẽ chạy. Nếu họ có thể bắt gặp một số vấn đề khó chịu đang diễn ra, thì điều đó thật tuyệt, nhưng điều đó trở nên khá vô nghĩa nếu các nhà phát triển không bao giờ nhớ chạy chúng.

Cuối cùng, kiểm tra tích hợp là một sự thay thế hoàn toàn không phù hợp để kiểm tra khói và kiểm tra người dùng. Nếu bạn bận tâm với họ, họ nên tạo thành một phần nhỏ của quy trình thử nghiệm được thiết kế tốt.


4
Chỉ cần một nhận xét: lưu ý rằng, ngược lại, có một trường phái suy nghĩ nghiêm túc đặt câu hỏi về giá trị của các bài kiểm tra đơn vị (DHH tuyên bố sẽ đặt câu hỏi về TDD, nhưng nếu bạn đọc bài đăng của mình, anh ta cũng đặt câu hỏi cho bài kiểm tra đơn vị). Thành thật mà nói, tôi thấy có những điều đồng ý và không đồng ý với cả hai trường phái tư tưởng cực đoan :)
Andres F.

1
Rất nhiều giáo điều xung quanh TDD xung quanh việc không viết bất cứ điều gì bạn không cần mà bất kỳ nhà phát triển dày dạn nào cũng biết qua YAGNI ...
Robbie Dee

4
Câu trả lời của bạn là tốt (+1), tuy nhiên, bài báo bạn đã trích dẫn có vấn đề mà tác giả đưa ra ấn tượng chỉ vì các bài kiểm tra tích hợp không hoạt động cho trường hợp của anh ấy , chúng sẽ không hiệu quả với bất kỳ ai khác. Trong nhóm của chúng tôi, chúng tôi đang sử dụng các thử nghiệm tích hợp ở đây cho sản phẩm của chúng tôi trong hơn 10 năm trên thực tế và chúng đã ngăn chúng tôi triển khai các lỗi nghiêm trọng nhiều lần, vì vậy tôi nghĩ rằng thực sự có thể viết các thử nghiệm tích hợp mang lại giá trị cao.
Doc Brown

Tác giả cũng viết trong một bình luận "Các thử nghiệm tích hợp (không phải" thử nghiệm tích hợp "!) [..]" - Tôi không chắc về sự khác biệt nhưng dường như có rất nhiều sắc thái liên quan đến việc thử nghiệm tích hợp có phải là hữu ích hay tốt
Carson Myers ngày

Theo kinh nghiệm của tôi, chỉ có các thử nghiệm tích hợp thực sự mang lại giá trị. Các bài kiểm tra đơn vị, đặc biệt là các bài kiểm tra sử dụng chế độ chế giễu, có nhiều rắc rối hơn giá trị. Ví dụ, trong dự án hiện tại của tôi, chúng tôi có 650 bài kiểm tra tích hợp dựa trên JUnit chạy trên mọi cam kết trên máy chủ Jenkins, với quá trình xây dựng đầy đủ chỉ mất chưa đến 10 phút. Tất nhiên, chúng tôi cũng chạy thử nghiệm trên IDE của mình, trong khi thực hiện TDD. Chúng tôi không thấy cần phải có thêm một bộ kiểm tra đơn vị - nó sẽ nỗ lực hơn rất nhiều mà không có lợi ích rõ ràng. Có lẽ lý do một số nhà phát triển tránh các thử nghiệm tích hợp chỉ đơn giản là họ chưa thực sự thử?
Rogério

8

Trái với câu trả lời này , tôi thấy việc kiểm tra ở các cấp độ khác nhau là một phần quan trọng của quy trình kiểm thử phần mềm. Đơn vị, chức năng, tích hợp, khói, chấp nhận và các loại thử nghiệm khác đang thử nghiệm những thứ khác nhau, và càng nhiều càng tốt.

Và nếu bạn quản lý để tự động hóa chúng, thì chúng có thể được thực thi như một công việc tích hợp liên tục của bạn (như jenkins). Không ai cần phải thực hiện chúng để xem nếu chúng bị hỏng, vì mọi người đều có thể xem nếu các bài kiểm tra thất bại.

Trong các thử nghiệm tích hợp của tôi, tôi không đi sâu vào chi tiết - chi tiết và các trường hợp góc dành cho các thử nghiệm đơn vị. Những gì tôi kiểm tra chỉ là chức năng chính, vượt qua tất cả các tham số chính xác. Điều đó có nghĩa là, trong ví dụ của bạn, trong các bài kiểm tra tích hợp, tôi sẽ không bao gồm các đường dẫn sai.


1
+1 Yep, nếu bạn có thể thực hiện các thử nghiệm tích hợp trong bản dựng thì càng nhiều càng tốt nhưng đây có thể là một công việc quan trọng trong các giải pháp cấp doanh nghiệp.
Robbie Dee
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.