Xóa trò lừa đảo kiểm tra tích hợp trên mạng - Tìm hiểu về cộng tác và kiểm tra hợp đồng [đã đóng]


8

Gần đây tôi đã xem Các bài kiểm tra tích hợp là một trò lừa đảo của JB Rainsberger và hiện đang tìm kiếm thêm tài liệu về chủ đề này. Tôi phải nói rằng, tôi bị sốc bởi chúng ta đã làm sai bao nhiêu, (tức là kiểm tra tích hợp khi chúng ta nên kiểm tra đơn vị), bị thu hút bởi các khái niệm được mô tả bởi Rainsberger nhưng cũng bối rối về cách áp dụng chúng. Tôi muốn có thêm các bài kiểm tra hợp tác được mô tả và kiểm tra hợp đồng nhưng tôi không biết bắt đầu từ đâu.

Điều duy nhất bị mắc kẹt trong tâm trí tôi là 4 câu hỏi mà các bài kiểm tra cần đặt ra:

Bên một:

Do I ask the right question?
Can I deal with the answer?

Bên B:

Can I answer a question?
Do I answer correctly?

Nhưng làm thế nào để tôi áp dụng điều này cho một số phương thức ngẫu nhiên trong ngăn xếp ứng dụng của tôi?

Có một cuốn sách hoặc một hướng dẫn hoặc ví dụ ngoài đó lấy một ví dụ trong thế giới thực và áp dụng những ý tưởng của các bài kiểm tra vi mô bị cô lập? Lý tưởng nhất là ví dụ sử dụng Java, Spring + PowerMock / Mockito / EasyMoock

Bất kỳ tài liệu nào liên quan đến các khái niệm này nói chung và giúp tôi hiểu chúng tốt hơn sẽ được đánh giá cao.

Ngoài ra nếu có các diễn đàn ngoài đó, nơi tôi có thể đặt câu hỏi chi tiết hơn về cách tiến hành kiểm tra đơn vị chính xác và thậm chí có thể tái cấu trúc mã hiện tại và các ví dụ bài đăng sẽ rất hay.

Cảm ơn!


Chỉnh sửa - một số suy nghĩ bổ sung:

Có một quy tắc chung, khi nào nên sử dụng một bản giả và khi nào còn sơ khai để cô lập một lớp đang thử nghiệm với các cộng tác viên của nó? Nó có thể được áp dụng cho 4 câu hỏi không?

Các khung mô phỏng tốt nhất dường như là PowerMock, cho phép tôi xác định chính xác cho mỗi bài kiểm tra mà tôi muốn chế giễu và lớp nào sẽ trả về hoặc có điều gì tốt hơn mà bạn đã sử dụng để hỏi các câu hỏi trên không? Có những hướng dẫn tốt ngoài kia sử dụng PowerMock để áp dụng một số hoặc tất cả các nguyên tắc nhất định cho một phần của ngăn xếp ứng dụng trong thế giới thực, nói DAO hoặc GUI?


Chỉnh sửa 2 - một ví dụ

Chỉ là một số ví dụ về loại phương pháp tôi muốn kiểm tra và suy nghĩ của tôi ..

Tôi có một dịch vụ web tiết kiệm đơn hàng. Ở giai đoạn này, chúng tôi không quá lo lắng về bảo mật tốt nhất, vì vậy để có một số dịch vụ, dịch vụ cũng sẽ lấy tên người dùng và mật khẩu để xác thực yêu cầu lưu. Sau khi xác thực, OrderManagerđược gọi để lưu Order. Trong nội bộ người quản lý quyết định nếu đó là một đơn đặt hàng mới để nó phải được tạo ra hoặc một đơn hàng hiện có phải được cập nhật. (Điều đó không quan trọng với WebSerice, phải không?)

@WebService
public class OrderService {
    @Inject
    private AuthenticationManager authenticationManager;

    @Inject
    private OrderManager orderManager;

    public void save(String username, String password, Order order) {
        authenticationManager.authenticate(username, password);
        try {
            orderManager.save(orde);
        } finally {
            authenticationManager.logout();
        }
    }

Bây giờ tôi tự hỏi: chính xác những gì tôi đang thử nghiệm ở đây? Tôi nghĩ nên có những thử nghiệm để xác thực thành công và thất bại và để tiết kiệm thành công và thất bại.

Nhưng làm thế nào tôi có thể chia nó thành 4 câu hỏi? Lớp học của tôi dưới Test rõ ràng là OrderService(HĐH) và các cộng tác viên là OrderManager(OM) và AuthenticationManager. (AM) Vì vậy, tôi có các bài kiểm tra sau, xin vui lòng sửa cho tôi ở đây, tôi chỉ đang suy nghĩ lớn:

Hệ điều hành <-> OM

  • Hệ điều hành yêu cầu OM lưu một đơn đặt hàng (loại thử nghiệm nào khác mà tôi kiểm tra ở đây? nullOrder? Có vấn đề gì nếu Orderđược khởi tạo chính xác không?)
  • OM trả lời cuộc gọi lưu bằng cách gọi một số phương thức nội bộ khác, kiểm tra II nếu phương thức đó được gọi?!
  • Hệ điều hành không nên thất bại nếu OM không bị lỗi
  • Hệ điều hành sẽ bị lỗi nếu OM bị lỗi

... Còn gì nữa không?

Và dĩ nhiên, hệ điều hành <-> AM :

  • Hệ điều hành yêu cầu AM xác thực - Tôi đoán tôi kiểm tra xem AM phản ứng thế nào với các loại tên người dùng / mật khẩu khác nhau?
  • ...

Bây giờ kết luận đầu tiên của tôi :

Theo như các WebSerice là có liên quan tôi chỉ có thể kiểm tra 2 trong số 4 câu hỏi sau: A. Side Bây giờ tôi phải nhìn vào OrderManagerAuthenticationManagervà xem họ có thể trả lời các câu hỏi của bên B. Phải không?

Thứ hai - truy cập cơ sở dữ liệu:

Xác thực và đặt hàng vẫn tồn tại rõ ràng đòi hỏi một số dữ liệu trong cơ sở dữ liệu trong môi trường sản xuất. Tuy nhiên, đối với các bài kiểm tra đơn vị của tôi, tôi sẽ không cần chúng vì vậy tôi sẽ chỉ chế giễu các cuộc gọi để trả về kết quả mong muốn, phải không? Nhưng làm thế nào để tôi chế nhạo điều này?

Tôi không cần phải AuthenticationManager.authenticatelàm gì nhiều, vì trong trường hợp xác thực thất bại, nó sẽ ném Exception, nếu không nó có kiểu trả về void. Làm thế nào để tôi nói với tôi OrderService.save()để sử dụng chế giễu của tôi AuthenticationManager.authenticate()?

Và làm thế nào để tôi thiết lập AuthenticationManagerkhông làm gì hoặc ném ngoại lệ?

Tôi có thể bảo Spring tiêm một thứ nhạo báng AuthenticationManagersẽ không làm gì / ném Exceptionvào OrderServicebài kiểm tra của tôi không?


Xin chào Pete, trong khi có vẻ như bạn đã nhận được những gì bạn đang tìm kiếm từ câu trả lời của DXM, trong tương lai, vui lòng giữ nó cho một vấn đề cụ thể cho mỗi câu hỏi: các câu hỏi cực kỳ rộng và bao quát không phù hợp với phong cách Stack Exchange hỏi đáp

Tôi hiểu rồi. Sẽ cố gắng bám vào một câu hỏi và đi đến điểm trong tương lai. Tôi nghĩ rằng tôi chỉ có quá nhiều câu hỏi về chủ đề nói chung và không biết hỏi họ ở đâu ...
Pete

Câu trả lời:


2

Đó là một câu hỏi thực sự dài và tôi xin lỗi nhưng tôi chỉ lướt qua những phần suy nghĩ bổ sung.

Tôi có thể giới thiệu hai cuốn sách tuyệt vời:

Họ không sử dụng các khung chính xác mà bạn đã đề cập nhưng lời khuyên họ đưa ra cho bạn rất có giá trị và dễ dàng áp dụng cho bất kỳ kịch bản nào với OOD. Cả hai đều đi sâu vào chi tiết về cách thiết lập các thử nghiệm đơn vị để cô lập chỉ thành phần đang được thử nghiệm và cách thiết lập các đối tượng giả / giả / gốc cho các phụ thuộc từ xa.

CẬP NHẬT (Trả lời bình luận bên dưới):

Câu trả lời này là để đáp lại OP:

  • "Tôi muốn có nhiều thử nghiệm cộng tác được mô tả và thử nghiệm hợp đồng" - thử nghiệm hợp đồng là thử nghiệm đơn vị vì OP muốn loại bỏ thử nghiệm tích hợp, và thay vào đó, thử nghiệm các thành phần riêng lẻ với giao diện được xác định rõ cho thành phần đó. Đó là thử nghiệm đơn vị và chính xác những gì những cuốn sách nói về.
  • "... nơi tôi có thể hỏi những câu hỏi chi tiết hơn về cách tiến hành kiểm tra đơn vị chính xác và thậm chí có thể tái cấu trúc mã hiện có"
  • "Có một quy tắc chung, khi nào nên sử dụng một bản giả và khi nào còn sơ khai để cô lập một lớp đang thử nghiệm với các cộng tác viên của nó?" - Cả hai cuốn sách đó đều xử lý rất nhiều với việc thiết lập các đối tượng giả và sử dụng chúng đúng cách
  • "Có một cuốn sách hoặc một hướng dẫn hoặc ví dụ nào đó lấy một ví dụ trong thế giới thực và áp dụng những ý tưởng của các bài kiểm tra vi mô bị cô lập không?" - Vâng, đây được gọi là Kiểm tra đơn vị và hai cuốn sách tôi liệt kê rất hay trong việc giải thích điều này.

Như OP đã chỉ ra, các bài kiểm tra tích hợp gây ra nhiều vấn đề vì chúng có xu hướng trở nên rất phức tạp và khó viết rất nhanh, thay thế tốt là kiểm tra đơn vị và kiểm tra từng lớp một cách riêng biệt với các giao diện công cộng của chúng. Ngoài các bài kiểm tra đơn vị, cả hai cuốn sách này cũng thảo luận về kiểm thử tích hợp và đề cập đến nơi nên và không nên sử dụng.

Hơn nữa, sau khi lướt qua câu hỏi của OP một lần nữa, có vẻ như rất nhiều điều không chắc chắn xoay quanh việc sử dụng các đối tượng giả và cả hai cuốn sách đó thực sự tập trung vào cách sử dụng các đối tượng giả (mặc dù chúng không đề cập đến Spring hoặc các khung giả cụ thể )


1
Ông không hỏi về các bài kiểm tra đơn vị, mà về các bài kiểm tra tích hợp. Vì vậy, tôi không nghĩ rằng bạn đã trả lời câu hỏi
BЈовић

@VJovic: phản hồi của tôi là trong bản cập nhật câu trả lời.
DXM

Cảm ơn câu trả lời chi tiết. Đặt mua xUnit Book trước đó. Hy vọng nó tốt như bạn phát ra âm thanh;) @VJovic: Câu hỏi có thực sự giống như tôi đang hỏi về các bài kiểm tra tích hợp ngay từ cái nhìn đầu tiên không? Bởi vì thực sự tôi đang hỏi về các bài kiểm tra đơn vị và tôi chỉ tham khảo video hội nghị có tên "Kiểm thử tích hợp là lừa đảo" có nghĩa là: kiểm tra tích hợp (hầu hết thời gian) không chỉ không hữu ích và giải quyết vấn đề mà còn nguy hiểm. Xin vui lòng cho tôi biết, nơi chính xác bạn tìm thấy bài viết sai lệch.
Pete

btw Tôi đã không downvote (ngược lại, tôi +1). @Pete Xóa bài kiểm tra tích hợp các trò lừa đảo khác - Tìm hiểu về cộng tác và kiểm tra hợp đồng - đây là tiêu đề của bạn. Tôi có thể đã hiểu nhầm bởi vì bạn đã nói về các bài kiểm tra tích hợp, và sau đó hỏi một số câu hỏi kiểm tra đơn vị.
BЈовић
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.