2012-04-12 49 views
5

Hỏi: cách phát hiện phạm vi kiểm tra thực tế?Mức độ phù hợp với mã có thể truy cập

Tôi đã nhận thấy một vấn đề với chỉ số bao phủ mã và chất lượng thử nghiệm: phạm vi mã 100% không có nghĩa là mã thực sự được kiểm tra.

Đôi khi kiểm tra cho phép mức độ phù hợp 100% ngay cả khi nó không bao gồm mọi thứ. Vấn đề đặt ở định nghĩa vùng phủ sóng, chúng tôi giả định mức độ phù hợp == mã có thể truy cập.

Nhưng điều đó không đúng, mã có thể đạt 100% nhưng không được kiểm tra 100%. Hãy xem xét ví dụ, thử nghiệm này cung cấp mức độ phù hợp 100% (EMMA), nhưng trên thực tế nó không bao gồm các giá trị sẽ được chuyển đến mô hình dịch vụ. Vì vậy, nếu giá trị sẽ được thay đổi, kiểm tra sẽ không thành công.

Ví dụ:

public class User { 
    public static final int INT_VALUE = 1; 
    public static final boolean BOOLEAN_VALUE = false; 
    public static final String STRING_VALUE = ""; 
    private Service service; 

    public void setService(Service service) { 
     this.service = service; 
    } 

    public String userMethod() { 
     return service.doSomething(INT_VALUE, BOOLEAN_VALUE, STRING_VALUE); 
    } 
} 

Và kiểm tra cho nó:

public class UserTest { 

    private User user; 
    private Service easyMockNiceMock; 

    @Before 
    public void setUp() throws Exception { 
     user = new User(); 
     easyMockNiceMock = EasyMock.createNiceMock(Service.class); 
    } 

    @Test 
    public void nonCoverage() throws Exception { 
     // given 
     user.setService(easyMockNiceMock); 
     expect(easyMockNiceMock.doSomething(anyInt(), anyBoolean(), (String) anyObject())).andReturn(""); 
     replay(easyMockNiceMock); 
     // when 
     user.userMethod(); 
     // then 
     verify(easyMockNiceMock); 
    } 
} 

Trả lời

4

Hãy xem Jester, mà thực hiện mutation testing. Từ trang web:

Jester tìm mã không được kiểm tra. Jester thực hiện một số thay đổi mã số , chạy thử nghiệm của bạn và nếu các thử nghiệm vượt qua Jester hiển thị thông báo cho biết điều gì đã thay đổi. Jester bao gồm một tập lệnh để tạo các trang web hiển thị các thay đổi đã không gây ra các thử nghiệm không thành công.

Jester khác với các công cụ bảo vệ mã, vì nó có thể tìm mã được thực hiện bằng cách chạy thử nghiệm nhưng không thực sự được kiểm tra. Cách tiếp cận của Jester được gọi là thử nghiệm đột biến hoặc lỗi tự động gieo hạt. Tuy nhiên, Jester không có nghĩa là thay thế cho các công cụ bảo hiểm mã số , chỉ đơn thuần là một cách tiếp cận bổ sung.

+0

Một điều đáng tiếc là nó không hoạt động đối với phiên bản hiện tại của .net. Có thể đã yêu thích điều này cho một spin. – Gishu

+0

Tôi đã cố gắng để google về khuôn khổ đột biến nhưng không phải của họ đã tích hợp với IDE (tốt hơn IDEA). –

+0

Jester mất một cách tiếp cận khá ngây thơ để thử nghiệm đột biến và do đó băng hà chậm. Nếu bạn đang tìm kiếm thử nghiệm đột biến, bạn có thể muốn thử một hệ thống hiện đại hơn như http://pitest.org hoặc javalanche – henry

2

Mức độ phù hợp 100% chưa bao giờ có nghĩa là 100% được kiểm tra và bất kỳ ai khẳng định nó đã không hiểu hoặc đang nói dối bạn. Đo lường mức độ phù hợp chỉ đơn giản là đo lường mã sản phẩm nào đã được thực thi trong khi thử nghiệm. Có hàng chục cách để viết các bài kiểm tra tạo ra mức độ phù hợp 100% và sau đó không kiểm tra đầy đủ mã của bạn.

Cách đơn giản nhất là viết một thử nghiệm gọi hàm sản phẩm, và sau đó không bao giờ đưa ra bất kỳ xác nhận nào về giá trị trả lại!

Đây là bài đăng trên blog mà tôi đã viết về chủ đề này: Flaws in Coverage Measurement, đó là Python-centric, nhưng các khái niệm đều giống nhau.

+1

Mức độ phù hợp cho bạn biết chính xác một điều: những gì _ không được kiểm tra. Khi nhìn vào một biểu đồ phủ sóng, tôi không quan tâm đến màu xanh lá cây, tôi quan tâm đến màu đỏ. –

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