6
Hãy tưởng tượng tôi có phương pháp sau đây cần được kiểm tra:Làm thế nào để tránh Thread.sleep trong bài kiểm tra đơn vị?
@Autowired
private RoutingService routingservice;
public void methodToBeTested() {
Object objectToRoute = initializeObjectToRoute();
if (someConditions) {
routingService.routeInOneWay(objectToRoute);
} else {
routingService.routeInAnotherWay(objectToRoute);
}
}
Trong trường hợp này RoutingService đang chạy trong thread riêng biệt, do đó trong constructor của nó, chúng tôi đã điều sau đây:
Thread thread = new Thread(this);
thread.setDaemon(true);
thread.start();
Vấn đề là RoutingService thay đổi trạng thái của objectToRoute và đây chính xác là những gì tôi muốn kiểm tra, nhưng điều này không xảy ra ngay lập tức, do đó thử nghiệm không thành công. Tuy nhiên, nếu tôi thêm Thread.sleep() thì nó hoạt động, nhưng đây là thực hành không tốt như tôi biết.
Làm cách nào để tránh Thread.sleep() trong trường hợp này?
Sử dụng 'Thread.sleep' trong một bài kiểm tra đơn vị không phải là thực hành không tốt, vì tất cả những gì bạn đang làm là bắt chước thời gian, cần thiết cho một số bài kiểm tra đơn vị. Lý do mọi người nói rằng bằng cách sử dụng 'Thread.sleep' là một thực tế tồi tệ là bởi vì nó đôi khi được sử dụng như một nỗ lực để sửa chữa điều kiện chủng tộc. Bạn chỉ sử dụng 'Thread.sleep' trong các bài kiểm tra, hoặc trong mã nguồn của bạn? –
Khi bạn đang thử nghiệm mã chuỗi, làm thế nào bạn sẽ đảm bảo kiểm tra đơn vị của bạn không flaky? Rằng họ luôn luôn thực hiện một cách xác định. Tôi nghĩ việc chế nhạo lớp Service là một opiton tốt hơn –
Tôi đang sử dụng giấc ngủ chỉ trong các bài kiểm tra, nhưng tìm thấy khá một vài nơi mà mọi người đề cập đến mà thường ngủ không phải là tốt trong các bài kiểm tra đơn vị.Ví dụ, plugin SonarLint đang phàn nàn và nói rằng nó vi phạm và đưa ra mô tả sau: "Sử dụng Thread.sleep trong một thử nghiệm chỉ là một ý tưởng tồi. Nó tạo ra các kiểm tra giòn có thể thất bại không thể đoán trước tùy thuộc vào môi trường (" máy của tôi! ") hoặc tải." – Rufi