Kiểm tra khoảng cách giữa đơn vị và tích hợp: Tích hợp trong các thử nghiệm tích hợp nhỏ, thành phần, đơn vị


9

Trong vài tuần qua tôi đã nghiên cứu và nghiên cứu cách lấp đầy khoảng trống trong phương pháp thử nghiệm của chúng tôi. Nói một cách đơn giản, các bài kiểm tra đơn vị là quá nhỏ và các bài kiểm tra tích hợp truyền thống là quá lớn.

Một kịch bản thường xuyên xuất hiện ở đâu ABcả hai sử dụng thành phần C. Tuy nhiên ABcó các yêu cầu hơi khác nhau cho, và đưa ra các giả định hơi khác nhau về C. Nếu tôi là nhà phát triển về Acách thức và nơi tôi kiểm tra các giả định của mình về C?

Rõ ràng thử nghiệm đơn vị Avới các giả định bị chế giễu Clà tốt để thử nghiệm Ariêng rẽ, nhưng nó không tự kiểm tra các giả định đó.

Một khả năng khác là thêm các bài kiểm tra đơn vị cho C. Tuy nhiên điều này không lý tưởng bởi vì, trong khi Ađang trong quá trình phát triển, việc thay đổi các bài kiểm tra Cvới các giả định phát triển từ đó Asẽ quá vụng về. Thật vậy A, nhà phát triển thậm chí có thể không có quyền truy cập đầy đủ vào các bài kiểm tra đơn vị của C(ví dụ: thư viện bên ngoài).

Để đóng khung này với một ví dụ cụ thể hơn: Giả sử rằng đây là một ứng dụng nút. ABphụ thuộc vào Cviệc đọc một tệp (trong số những thứ khác) và lưu trữ nội dung tệp trong đối tượng được truyền tới C. Lúc đầu, tất cả các tệp Cxử lý đều nhỏ và có thể được đọc đồng bộ mà không bị chặn đáng kể. Tuy nhiên, nhà phát triển Bnhận ra rằng các tệp của mình đang trở nên rất lớn và cần phải chuyển sang Cđọc không đồng bộ. Điều này dẫn đến một lỗi đồng bộ hóa lẻ tẻ A, vẫn giả sử Cđang đọc các tệp đồng bộ.

Đây là loại lỗi rất khó theo dõi từ các thử nghiệm tích hợp đầy đủ và có thể không bị bắt trong các thử nghiệm tích hợp. Nó cũng không bị bắt bởi Acác bài kiểm tra đơn vị vì các Agiả định của s bị chế giễu. Tuy nhiên, nó có thể dễ dàng bị bắt bởi một bài kiểm tra tích hợp "mini" chỉ thực hiện AC.

Tôi chỉ tìm thấy một vài tài liệu tham khảo về loại thử nghiệm này. Tích hợp trong thử nghiệm tích hợp nhỏ , thành phần , thử nghiệm tích hợp đơn vị . Nó cũng liên quan phần nào đến hướng thử nghiệm của BDD hơn là thử nghiệm đơn vị TDD chính thức.

Làm thế nào để tôi lấp đầy khoảng trống thử nghiệm này? Cụ thể - nơi tôi đặt các bài kiểm tra như vậy? Làm cách nào để tôi chế nhạo các đầu vào ACcho các thử nghiệm tích hợp "mini"? Và cần bao nhiêu nỗ lực để phân tách mối quan tâm kiểm tra giữa các bài kiểm tra này và bài kiểm tra đơn vị? Hoặc có cách nào tốt hơn để lấp đầy khoảng trống thử nghiệm?


1
Bạn đã xem xét phiên bản của các mô-đun AC và sử dụng một số hình thức quản lý phụ thuộc chưa?
miraculixx


1
@gnat Cảm ơn vì tiền boa. Tôi làm cho câu hỏi bớt mơ hồ.
mjhm

@miraclixx Cảm ơn lời đề nghị của bạn. Bạn có thể giải thích? Nếu bạn có ý gì đó như blog.nodejitsu.com/package-dependencies-done-right - Tôi nghĩ rằng điều này giải quyết một vấn đề khác với những gì tôi đang hỏi. Các thành phần mà tôi đang đề cập thường quá nhỏ so với phiên bản độc lập dưới dạng mô-đun nút - ví dụ: tệp thành phần Mô hình hoặc Trình điều khiển. Ngoài ra phiên bản chỉ đưa ra gợi ý về an toàn và nguồn gốc của sự cố, thay vì kiểm tra rõ ràng cho các vấn đề cụ thể.
mjhm

Câu trả lời:


6

Tôi thấy rằng bạn có một vấn đề cơ bản với các thành phần của bạn.

C nên làm những gì C cần làm, và được kiểm tra, ghi lại và thiết kế để làm việc đó. Khi bạn gặp tình huống C được thiết kế để "làm những gì B muốn", bạn có một mối quan hệ lạm dụng, một mối quan hệ trở nên rất rõ ràng khi A đến và muốn C làm điều gì đó hơi khác.

Những gì bạn không nên làm là kiểm tra đơn vị C trong ngữ cảnh của A và đặc biệt không phải là A trong ngữ cảnh của C - bạn kiểm tra A một cách độc lập và bạn cung cấp kết quả của một C bị chế giễu thành A. Nếu phiên bản trong thế giới thực của C không cung cấp các kết quả tương tự, sau đó bạn có một lỗi hoặc lỗi thiết kế trong C sẽ bị bắt khi bạn thực hiện các bài kiểm tra tích hợp lớn của mình. Kiểm tra đơn vị luôn theo cách này - bạn không thể kiểm tra một đơn vị bằng cách kiểm tra đơn vị khác cùng một lúc. Kiểm thử đơn vị không được thiết kế để làm điều đó.

Kiểm tra tích hợp không phải là "toàn bộ chương trình", mặc dù chúng thường được thiết lập theo cách đó. Chúng có thể là một thiết bị thử nghiệm chạy A và C cùng nhau mà không chạy phần còn lại của chương trình (hoặc ít nhất là nó có thể thoát khỏi). Tại thời điểm này tôi không thể tư vấn thêm vì nó phụ thuộc vào những gì các thành phần này làm và cách chúng tương tác với phần còn lại của chương trình của bạn, nhưng thông thường bạn có thể viết một thiết bị thử nghiệm cung cấp phạm vi kiểm tra của cả hai thành phần. Liệu nó có xứng đáng với nỗ lực để làm điều đó hay không, liệu có hiệu quả hơn khi kiểm tra tích hợp toàn bộ chương trình như một (ngay cả khi bạn chạy một tập hợp con của các bài kiểm tra tích hợp) là điều bạn chỉ có thể trả lời. Hầu hết các bài kiểm tra tích hợp bao gồm nhiều phần, vì vậy, hy vọng bạn chỉ có thể chạy những phần có liên quan đến 2 thành phần này (và nếu không,


Vâng, đó là những gì tôi đang nghĩ. Điều này là vượt quá phạm vi và mục đích của thử nghiệm đơn vị. Thật không may, tôi không sống trong một thế giới phần mềm nơi các thành phần phụ thuộc được thiết kế, kiểm tra và ghi lại một cách hoàn hảo. Và những thử nghiệm tích hợp nhỏ mà chúng tôi có thường là đầu cuối và được xử lý bởi các chuyên gia QA, thay vì các nhà phát triển nguồn. Như bạn có thể đoán có những vấn đề về quản lý và tổ chức.
mjhm

Tôi đoán bạn sẽ phải thêm các xét nghiệm hội nhập của riêng bạn, nhưng gọi cho họ kiểm tra đơn vị, "Chúng tôi đơn vị thử nghiệm module đăng nhập của khách hàng" như bạn chạy lên dưa chuột hoặc selen.
gbjbaanb
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.