Làm cách nào để thêm phạm vi kiểm tra vào một phương thức khởi tạo riêng?

Đây là mã:

package com.XXX;
public final class Foo {
  private Foo() {
    // intentionally empty
  }
  public static int bar() {
    return 1;
  }
}

Đây là bài kiểm tra:

package com.XXX;
public FooTest {
  @Test 
  void testValidatesThatBarWorks() {
    int result = Foo.bar();
    assertEquals(1, result);
  }
  @Test(expected = java.lang.IllegalAccessException.class)
  void testValidatesThatClassFooIsNotInstantiable() {
    Class cls = Class.forName("com.XXX.Foo");
    cls.newInstance(); // exception here
  }
}

Hoạt động tốt, lớp đã được kiểm tra. Nhưng Cobertura nói rằng không có vùng phủ mã nào của phương thức khởi tạo riêng của lớp. Làm thế nào chúng ta có thể thêm phạm vi kiểm tra vào một phương thức khởi tạo riêng như vậy?

Chà, có nhiều cách bạn có thể sử dụng phản chiếu, v.v. - nhưng nó có thực sự đáng giá không? Đây là một hàm tạo không bao giờ được gọi , phải không?

Nếu có một chú thích hoặc bất cứ điều gì tương tự mà bạn có thể thêm vào lớp để làm cho Cobertura hiểu rằng nó sẽ không được gọi, hãy làm điều đó: Tôi không nghĩ rằng việc thêm phạm vi phủ sóng một cách giả tạo là không đáng.

CHỈNH SỬA: Nếu không có cách nào làm điều đó, chỉ cần sống với phạm vi phủ sóng giảm nhẹ. Hãy nhớ rằng phạm vi bảo hiểm có nghĩa là một cái gì đó hữu ích cho bạn - bạn nên phụ trách công cụ này, chứ không phải ngược lại.

Tôi không hoàn toàn đồng ý với Jon Skeet. Tôi nghĩ rằng nếu bạn có thể giành được một chiến thắng dễ dàng để cung cấp cho bạn phạm vi bảo hiểm và loại bỏ nhiễu trong báo cáo mức độ phù hợp của bạn, thì bạn nên làm điều đó. Hoặc yêu cầu công cụ bao phủ của bạn bỏ qua hàm tạo, hoặc gạt chủ nghĩa lý tưởng sang một bên và viết bài kiểm tra sau và thực hiện với nó:

@Test
public void testConstructorIsPrivate() throws NoSuchMethodException, IllegalAccessException, InvocationTargetException, InstantiationException {
  Constructor<Foo> constructor = Foo.class.getDeclaredConstructor();
  assertTrue(Modifier.isPrivate(constructor.getModifiers()));
  constructor.setAccessible(true);
  constructor.newInstance();
}

Mặc dù nó không nhất thiết phải dành cho phạm vi bảo hiểm, nhưng tôi đã tạo phương thức này để xác minh rằng lớp tiện ích được xác định rõ và cũng thực hiện một chút phạm vi bảo hiểm.

/**
 * Verifies that a utility class is well defined.
 * 
 * @param clazz
 *            utility class to verify.
 */
public static void assertUtilityClassWellDefined(final Class<?> clazz)
        throws NoSuchMethodException, InvocationTargetException,
        InstantiationException, IllegalAccessException {
    Assert.assertTrue("class must be final",
            Modifier.isFinal(clazz.getModifiers()));
    Assert.assertEquals("There must be only one constructor", 1,
            clazz.getDeclaredConstructors().length);
    final Constructor<?> constructor = clazz.getDeclaredConstructor();
    if (constructor.isAccessible() || 
                !Modifier.isPrivate(constructor.getModifiers())) {
        Assert.fail("constructor is not private");
    }
    constructor.setAccessible(true);
    constructor.newInstance();
    constructor.setAccessible(false);
    for (final Method method : clazz.getMethods()) {
        if (!Modifier.isStatic(method.getModifiers())
                && method.getDeclaringClass().equals(clazz)) {
            Assert.fail("there exists a non-static method:" + method);
        }
    }
}

Tôi đã đặt mã đầy đủ và ví dụ trong https://github.com/trajano/maven-jee6/tree/master/maven-jee6-test

Tôi đã đặt private là phương thức khởi tạo của lớp hàm tiện ích tĩnh của tôi, để đáp ứng CheckStyle. Nhưng giống như tấm áp phích gốc, tôi đã yêu cầu Cobertura phàn nàn về bài kiểm tra. Lúc đầu, tôi đã thử cách tiếp cận này, nhưng điều này không ảnh hưởng đến báo cáo phạm vi bởi vì hàm tạo không bao giờ thực sự được thực thi. Vì vậy, thực sự tất cả các thử nghiệm này là nếu phương thức khởi tạo vẫn còn riêng tư - và điều này được thực hiện dư thừa bởi kiểm tra khả năng tiếp cận trong thử nghiệm tiếp theo.

@Test(expected=IllegalAccessException.class)
public void testConstructorPrivate() throws Exception {
    MyUtilityClass.class.newInstance();
    fail("Utility class constructor should be private");
}

Tôi đã theo gợi ý của Javid Jamae và sử dụng phản xạ, nhưng thêm các xác nhận để bắt bất kỳ ai gây rối với lớp đang được kiểm tra (và đặt tên cho bài kiểm tra để chỉ Mức độ Ác cao).

@Test
public void evilConstructorInaccessibilityTest() throws Exception {
    Constructor[] ctors = MyUtilityClass.class.getDeclaredConstructors();
    assertEquals("Utility class should only have one constructor",
            1, ctors.length);
    Constructor ctor = ctors[0];
    assertFalse("Utility class constructor should be inaccessible", 
            ctor.isAccessible());
    ctor.setAccessible(true); // obviously we'd never do this in production
    assertEquals("You'd expect the construct to return the expected type",
            MyUtilityClass.class, ctor.newInstance().getClass());
}

Điều này là quá mức cần thiết, nhưng tôi phải thừa nhận rằng tôi thích cảm giác mờ ảo ấm áp của phương pháp bao phủ 100%.

Với Java 8 , có thể tìm ra giải pháp khác.

Tôi giả sử rằng bạn chỉ muốn tạo một lớp tiện ích với một vài phương thức tĩnh công khai. Nếu bạn có thể sử dụng Java 8, thì bạn có thể sử dụng interfacethay thế.

package com.XXX;

public interface Foo {

  public static int bar() {
    return 1;
  }
}

Không có nhà xây dựng và không có phàn nàn từ Cobertura. Bây giờ bạn chỉ cần kiểm tra những dòng bạn thực sự quan tâm.

Lý do đằng sau việc kiểm tra mã không làm được gì là để đạt được độ phủ mã 100% và để ý khi độ phủ mã giảm xuống. Nếu không, người ta luôn có thể nghĩ, này, tôi không có phạm vi bảo hiểm mã 100% nữa nhưng nó RẤT HẤP DẪN vì các hàm tạo riêng của tôi. Điều này giúp bạn dễ dàng phát hiện các phương thức chưa được kiểm tra mà không cần phải kiểm tra xem nó có phải là một phương thức khởi tạo riêng hay không. Khi cơ sở mã của bạn phát triển, bạn sẽ thực sự cảm thấy một cảm giác ấm áp dễ chịu khi nhìn vào 100% thay vì 99%.

IMO tốt nhất nên sử dụng phản chiếu ở đây vì nếu không bạn sẽ phải có một công cụ bao phủ mã tốt hơn để bỏ qua các hàm tạo này hoặc bằng cách nào đó yêu cầu công cụ bao phủ mã bỏ qua phương thức (có thể là Chú thích hoặc tệp cấu hình) vì khi đó bạn sẽ bị mắc kẹt với một công cụ bao phủ mã cụ thể.

Trong một thế giới hoàn hảo, tất cả các công cụ bao phủ mã sẽ bỏ qua các hàm tạo riêng thuộc về lớp cuối cùng vì hàm tạo ở đó như một biện pháp "bảo mật" không có gì khác :)
Tôi sẽ sử dụng mã này:

    @Test
    public void callPrivateConstructorsForCodeCoverage() throws SecurityException, NoSuchMethodException, IllegalArgumentException, InstantiationException, IllegalAccessException, InvocationTargetException
    {
        Class<?>[] classesToConstruct = {Foo.class};
        for(Class<?> clazz : classesToConstruct)
        {
            Constructor<?> constructor = clazz.getDeclaredConstructor();
            constructor.setAccessible(true);
            assertNotNull(constructor.newInstance());
        }
    }

Các phiên bản mới hơn của Cobertura có hỗ trợ tích hợp để bỏ qua getters / setters / constructors tầm thường:

https://github.com/cobertura/cobertura/wiki/Ant-Task-Reference#ignore-trivial

Bỏ qua tầm thường

Bỏ qua tầm thường cho phép khả năng loại trừ các hàm tạo / phương thức chứa một dòng mã. Một số ví dụ bao gồm lệnh gọi chỉ một trình tạo siêu, các phương thức getter / setter, v.v. Để bao gồm đối số tầm thường bỏ qua, hãy thêm phần sau:

<cobertura-instrument ignoreTrivial="true" />

hoặc trong bản dựng Gradle:

cobertura {
    coverageIgnoreTrivial = true
}

Đừng. Điểm mấu chốt trong việc kiểm tra một hàm tạo rỗng là gì? Vì cobertura 2.0 có một tùy chọn để bỏ qua những trường hợp nhỏ nhặt như vậy (cùng với setters / getters), bạn có thể bật nó trong maven bằng cách thêm phần cấu hình vào plugin cobertura maven:

<configuration>
  <instrumentation>
    <ignoreTrivial>true</ignoreTrivial>                 
  </instrumentation>
</configuration>

Hoặc bạn có thể sử dụng Bảo hiểm Chú thích : @CoverageIgnore.

Cuối cùng, có giải pháp!

public enum Foo {;
  public static int bar() {
    return 1;
  }
}

Tôi không biết về Cobertura nhưng tôi sử dụng Clover và nó có một phương tiện để thêm các loại trừ phù hợp với mẫu. Ví dụ: tôi có các mẫu loại trừ các dòng ghi nhật ký apache-commons để chúng không được tính trong phạm vi bảo hiểm.

Một tùy chọn khác là tạo bộ khởi tạo tĩnh tương tự như đoạn mã sau

class YourClass {
  private YourClass() {
  }
  static {
     new YourClass();
  }

  // real ops
}

Bằng cách này, phương thức khởi tạo riêng được coi là đã được kiểm tra và chi phí thời gian chạy về cơ bản là không thể đo lường được. Tôi làm điều này để có được độ che phủ 100% bằng cách sử dụng EclEmma, ​​nhưng có khả năng nó hoạt động cho mọi công cụ che phủ. Tất nhiên, hạn chế của giải pháp này là bạn viết mã sản xuất (trình khởi tạo tĩnh) chỉ cho mục đích thử nghiệm.

ClassUnderTest testClass = Whitebox.invokeConstructor (ClassUnderTest.class);

Đôi khi Cobertura đánh dấu mã không dự định được thực thi là 'không được bảo vệ', không có gì sai với điều đó. Tại sao bạn quan tâm đến việc có 99%bảo hiểm thay vì100% ?

Mặc dù vậy, về mặt kỹ thuật, bạn vẫn có thể gọi phương thức khởi tạo đó với sự phản chiếu, nhưng tôi nghe có vẻ rất sai (trong trường hợp này).

Nếu tôi đoán được mục đích câu hỏi của bạn, tôi sẽ nói:

1. Bạn muốn kiểm tra hợp lý đối với các trình tạo riêng hoạt động thực tế và
2. Bạn muốn cỏ ba lá loại trừ các hàm tạo trống cho các lớp sử dụng.

Đối với 1, rõ ràng là bạn muốn tất cả khởi tạo được thực hiện thông qua các phương thức gốc. Trong những trường hợp như vậy, các bài kiểm tra của bạn sẽ có thể kiểm tra các tác dụng phụ của hàm tạo. Điều này sẽ thuộc loại thử nghiệm phương pháp tư nhân thông thường. Làm cho các phương pháp nhỏ hơn để chúng chỉ làm một số việc xác định hạn chế (lý tưởng là chỉ một việc và một việc tốt) và sau đó kiểm tra các phương pháp dựa vào chúng.

Ví dụ: nếu phương thức khởi tạo [private] của tôi thiết lập các trường cá thể của lớp tôi athành 5. Sau đó, tôi có thể (hoặc đúng hơn là phải) kiểm tra nó:

@Test
public void testInit() {
    MyClass myObj = MyClass.newInstance(); //Or whatever factory method you put
    Assert.assertEquals(5, myObj.getA()); //Or if getA() is private then test some other property/method that relies on a being 5
}

Đối với 2, bạn có thể định cấu hình cỏ ba lá để loại trừ các hàm tạo Util nếu bạn có một mẫu đặt tên cho các lớp Util. Ví dụ: trong dự án của riêng tôi, tôi sử dụng một cái gì đó như thế này (vì chúng tôi tuân theo quy ước rằng tên cho tất cả các lớp Util phải kết thúc bằng Util):

<clover-setup initString="${build.dir}/clovercoverage.db" enabled="${with.clover}">
    <methodContext name="prvtCtor" regexp="^private *[a-zA-Z0-9_$]+Util *( *) *"/>
</clover-setup>

Tôi đã cố tình bỏ qua một phần .*sau) bởi vì các hàm tạo như vậy không có nghĩa là để ném các ngoại lệ (chúng không có nghĩa là để làm bất cứ điều gì).

Tất nhiên có thể có trường hợp thứ ba mà bạn có thể muốn có một phương thức khởi tạo trống cho một lớp không phải tiện ích. Trong những trường hợp như vậy, tôi khuyên bạn nên đặt một methodContextvới chữ ký chính xác của hàm tạo.

<clover-setup initString="${build.dir}/clovercoverage.db" enabled="${with.clover}">
    <methodContext name="prvtCtor" regexp="^private *[a-zA-Z0-9_$]+Util *( *) *"/>
    <methodContext name="myExceptionalClassCtor" regexp="^private MyExceptionalClass()$"/>
</clover-setup>

Nếu bạn có nhiều lớp đặc biệt như vậy thì bạn có thể chọn sửa đổi phương thức khởi tạo riêng tổng quát reg-ex mà tôi đã đề xuất và xóa Utilkhỏi nó. Trong trường hợp này, bạn sẽ phải tự đảm bảo rằng các tác dụng phụ của phương thức khởi tạo vẫn được kiểm tra và bao phủ bởi các phương thức khác trong lớp / dự án của bạn.

<clover-setup initString="${build.dir}/clovercoverage.db" enabled="${with.clover}">
    <methodContext name="prvtCtor" regexp="^private *[a-zA-Z0-9_$]+ *( *) .*"/>
</clover-setup>

@Test
public void testTestPrivateConstructor() {
    Constructor<Test> cnt;
    try {
        cnt = Test.class.getDeclaredConstructor();
        cnt.setAccessible(true);

        cnt.newInstance();
    } catch (Exception e) {
        e.getMessage();
    }
}

Test.java là tệp nguồn của bạn, có hàm tạo riêng của bạn

Phần sau đã làm việc với tôi trên một lớp được tạo bằng Lombok annotation @UtilityClass, lớp này tự động thêm một phương thức khởi tạo riêng.

@Test
public void testConstructorIsPrivate() throws IllegalAccessException, InvocationTargetException, InstantiationException, NoSuchMethodException {
    Constructor<YOUR_CLASS_NAME> constructor = YOUR_CLASS_NAME.class.getDeclaredConstructor();
    assertTrue(Modifier.isPrivate(constructor.getModifiers())); //this tests that the constructor is private
    constructor.setAccessible(true);
    assertThrows(InvocationTargetException.class, () -> {
        constructor.newInstance();
    }); //this add the full coverage on private constructor
}

Mặc dù constructor.setAccessible (true) sẽ hoạt động khi phương thức khởi tạo riêng được viết theo cách thủ công, với chú thích Lombok không hoạt động, vì nó bắt buộc. Constructor.newInstance () thực sự kiểm tra xem phương thức khởi tạo có được gọi hay không và điều này hoàn thành phạm vi bảo hiểm của chính trình cấu trúc chi phí. Với khẳng định, bạn ngăn chặn việc kiểm tra không thành công và bạn đã quản lý ngoại lệ vì đó chính xác là lỗi mà bạn mong đợi. Mặc dù đây là một cách giải quyết và tôi không đánh giá cao khái niệm "phạm vi đường truyền" so với "phạm vi chức năng / hành vi", chúng tôi có thể tìm thấy ý nghĩa trong thử nghiệm này. Trên thực tế, bạn chắc chắn rằng Lớp tiện ích thực sự có một Constructor riêng tư ném chính xác một ngoại lệ khi được gọi cũng thông qua phản ứng lại. Hi vọng điêu nay co ich.

Lựa chọn ưa thích của tôi trong năm 2019: Sử dụng lombok.

Cụ thể, @UtilityClasschú thích . (Đáng buồn là nó chỉ là "thử nghiệm" tại thời điểm viết bài, nhưng nó hoạt động tốt và có triển vọng tích cực, vì vậy có khả năng sớm được nâng cấp lên ổn định.)

Chú thích này sẽ thêm phương thức khởi tạo riêng để ngăn việc khởi tạo và sẽ làm cho lớp cuối cùng. Khi được kết hợp với lombok.addLombokGeneratedAnnotation = truein lombok.config, hầu hết các khuôn khổ thử nghiệm sẽ bỏ qua mã được tạo tự động khi tính toán phạm vi kiểm tra, cho phép bạn bỏ qua phạm vi của mã được tạo tự động đó mà không bị hack hoặc phản ánh.

Bạn không thể.

Rõ ràng bạn đang tạo phương thức khởi tạo riêng để ngăn chặn việc khởi tạo một lớp chỉ chứa các phương thức tĩnh. Thay vì cố gắng tìm hiểu về hàm tạo này (sẽ yêu cầu lớp phải được khởi tạo), bạn nên loại bỏ nó và tin tưởng các nhà phát triển của bạn không thêm các phương thức cá thể vào lớp.