2012-06-25 31 views
5

Thật dễ dàng để xác minh rằng tương tác cụ thể (gọi phương thức cụ thể) xảy ra trên một đối tượng giả trong Mockito, và có verifyZeroInteractions() để kiểm tra xem không có tương tác nào xảy ra. Giả sử tôi đang thử nghiệm một giao diện như giao diện của trình ghi nhật ký, với các phương thức như info(), warn(), error() v.v. Trong một trường hợp cụ thể, tôi biết một trong những phương pháp này nên được gọi, nhưng tôi không thực sự quan tâm đến phương thức nào. Có cách nào nhỏ gọn để kiểm tra xem có bất kỳ tương tác nào với đối tượng giả đã xảy ra mà không cần chỉ rõ phương pháp chính xác nào nên được gọi? Hoặc có lẽ một cơ chế như vậy là không cần thiết bởi vì "cách Mockito" của thử nghiệm này sẽ khác với những gì tôi tưởng tượng?Có thể xác minh tương tác tùy ý bằng Mockito một cách nhỏ gọn không?

Trả lời

1

Nếu bạn có thể tạo ra đối tượng logger từ lớp đang thử nghiệm, không có lý do gì bạn không thể thực hiện kiểm tra của riêng mình đối với Giao diện Đăng nhập sẽ ghi lại phương thức nào đã được thực hiện và tiêm nó như một phần của thiết lập thử nghiệm của bạn.

Thư viện giả làm rất tốt, nhưng đôi khi có trường hợp góc như bạn đã tìm thấy nơi chúng có thể không đáp ứng nhu cầu của bạn.

Nếu bạn viết thực hiện của riêng bạn để thử nghiệm như thế này, và tiêm nó vào lớp thử nghiệm yourt dưới kiểm tra, sau đó bạn có thể khẳng định trên getCount() > 0

public class LoggerTestSupportImpl implements ILogger { 

    private int count = 0; 

    @Override 
    public int getCount() { 
     return count; 
    } 

    @Override 
    public void info(String message) { 
     count++;  
    } 

    @Override 
    public void warn(String message) { 
     count++;  
    } 
} 
+1

Đây chính là làm thế nào tôi đã được thử nghiệm lớp học của tôi cho đến nay, Tôi chỉ tự hỏi liệu Mockito có thể tha cho tôi từ việc viết những triển khai tầm thường cho tất cả các phương pháp. –

+0

Tôi muốn nói rằng bạn đã làm điều hợp lý Michal. Mockito không hỗ trợ loại thử nghiệm này. Lựa chọn duy nhất của bạn là đi xuống con đường 'ArgumentCaptor' như đã đề cập bởi Kevin, nhưng điều này dẫn đến rất nhiều" tiếng ồn "trong các lớp thi của bạn. – Brad

+0

Đồng ý rằng nó hơi ồn ào, nhưng phần lớn nhiễu được bản địa hoá thành khai báo và phương thức Before, và bạn thậm chí có thể thêm Captor vào khai báo mức lớp nếu nó được sử dụng trên nhiều phương thức Test (thậm chí không cần thiết nếu không truy cập vào msg) . Điều tuyệt vời khi sử dụng Mockito là bạn đã có quyền truy cập vào API ghi nhật ký đầy đủ. Để làm như vậy trong ví dụ của bạn, bạn phải mở rộng khả năng của mô hình được cuộn bằng tay của bạn (chụp/truy xuất số lượng thông điệp đã đăng nhập, v.v.) Nhưng đối với nhu cầu đơn giản, cách của bạn có vẻ đơn giản hơn, sạch hơn, * và * có thể tái sử dụng, một số điểm cộng cho cách tiếp cận của bạn. –

2

Với log4j, để kiểm tra các logger tôi làm việc thiết lập sau:

@Mock private Appender log4jAppender; 
private Logger logger; 

@Before 
public void setup() { 
    MockitoAnnotations.initMocks(this); 

    Logger root = Logger.getRootLogger(); 
    if (!root.getAllAppenders().hasMoreElements()) { 
     // No appenders means log4j is not initialized! 
     BasicConfigurator.configure(); 
    } 
    logger = Logger.getLogger(MyClassWhichLogs.class); 
    logger.addAppender(log4jAppender); 
} 

và sau đó trong thử nghiệm của tôi, tôi làm như sau:

verifyZeroInteractions(log4jAppender); 

hoặc

verify(log4jAppender).doAppend(any(LoggingEvent.class); 

Nếu bạn cần phải kiểm tra các giá trị được ghi lại, bạn có thể cung cấp một trình cho phép thay thế:

ArgumentCaptor<LoggingEvent> logCaptor = ArgumentCaptor.forClass(LoggingEvent.class); 
verify(log4jAppender).doAppend(logCaptor.capture()); 
assertTrue(logCaptor.getValue().contains("my text to match"); 

Mặc dù điều này không nhất thiết phải trả lời câu hỏi tổng quát (Tôi không nghĩ những gì bạn đang tìm kiếm tồn tại), nó có thể giải quyết vấn đề cụ thể này để kiểm tra đăng nhập.

Các vấn đề liên quan