Trong thử nghiệm tích hợp, có thay đổi không khi sử dụng quy trình Async với quy trình Đồng bộ để kiểm tra?

Question

Trong các thử nghiệm tích hợp, các quá trình không đồng bộ (các phương thức, các dịch vụ bên ngoài) tạo ra một mã kiểm tra rất khó khăn. Nếu thay vào đó, tôi tính ra phần không đồng bộ và tạo ra một sự phụ thuộc và thay thế nó bằng một phần đồng bộ để thử nghiệm, đó có phải là một "điều tốt" không?

Bằng cách thay thế quy trình không đồng bộ bằng một quy trình đồng bộ, tôi có không thử nghiệm trong tinh thần thử nghiệm tích hợp không? Tôi đoán tôi giả định rằng thử nghiệm tích hợp đề cập đến thử nghiệm gần với điều thực.

Answer 1

Chúng tôi có một số kiểm tra đơn vị tự động gửi yêu cầu không đồng bộ và cần kiểm tra kết quả/kết quả. Cách chúng ta xử lý nó là thực sự thực hiện tất cả các thử nghiệm như thể nó là một phần của ứng dụng thực tế, nói cách khác các yêu cầu không đồng bộ vẫn không đồng bộ. Nhưng việc kiểm tra hoạt động đồng bộ: Nó gửi đi yêu cầu không đồng bộ, ngủ [lên đến] một khoảng thời gian (tối đa mà chúng ta mong đợi kết quả được tạo ra), và nếu vẫn không có kết quả, thì thử nghiệm đã thất bại. Có callback, vì vậy trong hầu hết các trường hợp, kiểm tra được đánh thức và tiếp tục chạy trước khi hết thời gian chờ, nhưng timeout có nghĩa là lỗi (hoặc thay đổi hiệu năng mong đợi) sẽ không dừng/tạm dừng toàn bộ bộ kiểm thử.

này có một vài ưu điểm:

• Các đơn vị kiểm tra là rất gần với patters gọi thực tế của ứng dụng
• Không có mã/khai mới là cần thiết để làm cho mã ứng dụng (mã đang được thử nghiệm) chạy đồng bộ
• hiệu suất được kiểm tra ngầm: Nếu xét nghiệm ngủ trong một thời gian quá ngắn, sau đó một số đặc tính hiệu suất đã thay đổi, và rằng cần nhìn vào để

Điểm cuối cùng có thể cần một lượng nhỏ giải thích. Kiểm tra hiệu suất là quan trọng và thường bị bỏ sót khỏi kế hoạch kiểm tra. Cách các thử nghiệm đơn vị này được chạy, chúng sẽ mất nhiều thời gian hơn (thời gian chạy) hơn là nếu chúng tôi đã sắp xếp lại mã để làm mọi thứ đồng bộ. Tuy nhiên theo cách này, hiệu suất được kiểm tra ngầm, và các bài kiểm tra trung thành hơn với cách sử dụng của chúng trong ứng dụng. Ngoài ra, tất cả cơ sở hạ tầng xếp hàng đợi của chúng tôi đều được kiểm tra "miễn phí" trên đường đi.

Sửa: Thêm lưu ý về callbacks

Answer 2

bạn đang thử nghiệm gì? Các hành vi của lớp học của bạn để đáp ứng với kích thích nhất định? Trong trường hợp nào không phù hợp mocks làm công việc?

Class Orchestrator implements AsynchCallback { 

    TheAsycnhService myDelegate; // initialised by injection 

    public void doSomething(Request aRequest){ 
      myDelegate.doTheWork(aRequest, this) 
    } 

    public void tellMeTheResult(Response aResponse) { 
      // process response 
    } 
} 

thử nghiệm của bạn có thể làm điều gì đó như

Orchestrator orch = new Orchestrator(mockAsynchService); 

orch.doSomething(request); 

// assertions here that the mockAsychService received the expected request 

// now either the mock really does call back 
// or (probably more easily) make explicit call to the tellMeTheResult() method 

// assertions here that the Orchestrator did the right thing with the response 

Lưu ý rằng không có asynch xử lý đúng ở đây, và các mô hình riêng của mình cần không có logic nào khác ngoài việc cho phép xác minh kể từ khi nhận được yêu cầu chính xác. Đối với một bài kiểm tra đơn vị của dàn nhạc này là đủ.

Tôi đã sử dụng this biến thể trên ý tưởng khi thử nghiệm quy trình BPEL trong Máy chủ quy trình WebSphere.

Answer 3

Câu hỏi hay.

Trong thử nghiệm đơn vị, phương pháp này có ý nghĩa nhưng đối với thử nghiệm tích hợp, bạn nên thử nghiệm hệ thống thực vì nó sẽ hoạt động trong thực tế.Điều này bao gồm bất kỳ hoạt động không đồng bộ nào và bất kỳ tác dụng phụ nào mà chúng có thể có - đây là nơi có nhiều khả năng xảy ra nhất và có thể là nơi bạn nên tập trung kiểm tra của mình không phải là yếu tố xuất hiện.

Tôi thường sử dụng phương thức "waitFor" trong đó tôi thăm dò ý kiến ​​để xem câu trả lời đã được nhận chưa và thời gian chờ sau một thời gian nếu không. Việc triển khai tốt mẫu này, mặc dù java cụ thể bạn có thể nhận được ý chính, là JUnitConditionRunner. Ví dụ:

conditionRunner = new JUnitConditionRunner(browser, WAIT_FOR_INTERVAL, WAIT_FOR_TIMEOUT); 

protected void waitForText(String text) { 
    try { 
     conditionRunner.waitFor(new Text(text)); 
    } catch(Throwable t) { 
     throw new AssertionFailedError("Expecting text " + text + " failed to become true. Complete text [" + browser.getBodyText() + "]"); 
    } 
}