Bagaimana cara menambahkan cakupan pengujian ke konstruktor pribadi?

Ini kodenya:

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

Inilah ujiannya:

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
  }
}

Berfungsi dengan baik, kelas telah diuji. Tetapi Cobertura mengatakan bahwa tidak ada cakupan kode dari konstruktor privat kelas. Bagaimana kita bisa menambahkan cakupan tes ke konstruktor pribadi seperti itu?

Nah, ada cara-cara yang berpotensi Anda gunakan refleksi dll - tetapi apakah itu benar-benar layak? Ini adalah konstruktor yang tidak boleh dipanggil , bukan?

Jika ada anotasi atau sesuatu yang serupa yang dapat Anda tambahkan ke kelas untuk membuat Cobertura mengerti bahwa itu tidak akan dipanggil, lakukan itu: Saya rasa tidak ada gunanya melalui rintangan untuk menambahkan liputan secara artifisial.

EDIT: Jika tidak ada cara untuk melakukannya, jalani saja dengan cakupan yang sedikit berkurang. Ingatlah bahwa pertanggungan dimaksudkan untuk menjadi sesuatu yang berguna bagi Anda - Anda harus bertanggung jawab atas alat tersebut, bukan sebaliknya.

Saya tidak sepenuhnya setuju dengan Jon Skeet. Saya pikir jika Anda bisa mendapatkan kemenangan mudah untuk memberi Anda liputan dan menghilangkan gangguan dalam laporan liputan Anda, maka Anda harus melakukannya. Beri tahu alat cakupan Anda untuk mengabaikan konstruktor, atau kesampingkan idealisme dan tulis tes berikut dan selesaikan dengannya:

@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();
}

Meskipun belum tentu untuk cakupan, saya membuat metode ini untuk memverifikasi bahwa kelas utilitas didefinisikan dengan baik dan melakukan sedikit cakupan juga.

/**
 * 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);
        }
    }
}

Saya telah menempatkan kode lengkap dan contoh di https://github.com/trajano/maven-jee6/tree/master/maven-jee6-test

Saya telah menjadikan private sebagai konstruktor kelas fungsi utilitas statis saya, untuk memenuhi CheckStyle. Tapi seperti poster aslinya, Cobertura mengeluh tentang ujian itu. Awalnya saya mencoba pendekatan ini, tetapi ini tidak mempengaruhi laporan cakupan karena konstruktor tidak pernah benar-benar dijalankan. Jadi sebenarnya semua pengujian ini adalah jika konstruktor tetap bersifat pribadi - dan ini dibuat berlebihan oleh pemeriksaan aksesibilitas di pengujian berikutnya.

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

Saya mengikuti saran Javid Jamae dan menggunakan refleksi, tetapi menambahkan pernyataan untuk menangkap siapa pun yang mengotak-atik kelas yang sedang diuji (dan menamai tes tersebut untuk menunjukkan Tingkat Kejahatan Tinggi).

@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());
}

Ini sangat berlebihan, tetapi saya harus mengakui bahwa saya menyukai perasaan hangat kabur dari cakupan metode 100%.

Dengan Java 8 , Anda dapat menemukan solusi lain.

Saya berasumsi bahwa Anda hanya ingin membuat kelas utilitas dengan beberapa metode statis publik. Jika Anda dapat menggunakan Java 8, Anda dapat menggunakan interfacesebagai gantinya.

package com.XXX;

public interface Foo {

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

Tidak ada konstruktor dan tidak ada keluhan dari Cobertura. Sekarang Anda hanya perlu menguji garis yang benar-benar Anda pedulikan.

Alasan di balik kode pengujian yang tidak melakukan apa pun adalah untuk mencapai cakupan kode 100% dan untuk memperhatikan ketika cakupan kode turun. Kalau tidak, orang selalu bisa berpikir, hei saya tidak memiliki cakupan kode 100% lagi tetapi MUNGKIN karena konstruktor pribadi saya. Ini membuatnya mudah untuk menemukan metode yang belum diuji tanpa harus memeriksa bahwa itu hanya konstruktor pribadi. Saat basis kode Anda tumbuh, Anda benar-benar akan merasakan perasaan hangat yang menyenangkan melihat 100%, bukan 99%.

IMO lebih baik menggunakan refleksi di sini karena jika tidak, Anda harus mendapatkan alat cakupan kode yang lebih baik yang mengabaikan konstruktor ini atau entah bagaimana memberi tahu alat cakupan kode untuk mengabaikan metode (mungkin Anotasi atau file konfigurasi) karena Anda akan terjebak dengan alat cakupan kode tertentu.

Dalam dunia yang sempurna, semua alat cakupan kode akan mengabaikan konstruktor privat yang termasuk dalam kelas akhir karena konstruktor ada di sana sebagai ukuran "keamanan", tidak ada yang lain :)
Saya akan menggunakan kode ini:

    @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());
        }
    }

Versi Cobertura yang lebih baru memiliki dukungan bawaan untuk mengabaikan pengambil / penyetel / konstruktor sepele:

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

Abaikan Sepele

Abaikan sepele memungkinkan kemampuan untuk mengecualikan konstruktor / metode yang berisi satu baris kode. Beberapa contoh termasuk panggilan ke konstruktor super saja, metode pengambil / penyetel, dll. Untuk menyertakan argumen abaikan sepele, tambahkan berikut ini:

<cobertura-instrument ignoreTrivial="true" />

atau dalam build Gradle:

cobertura {
    coverageIgnoreTrivial = true
}

Jangan. Apa gunanya menguji konstruktor kosong? Karena cobertura 2.0 ada opsi untuk mengabaikan kasus sepele seperti itu (bersama dengan setter / getter), Anda dapat mengaktifkannya di maven dengan menambahkan bagian konfigurasi ke plugin cobertura maven:

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

Atau Anda dapat menggunakan Cakupan Penjelasan : @CoverageIgnore.

Akhirnya, ada solusinya!

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

Saya tidak tahu tentang Cobertura tetapi saya menggunakan Clover dan ini memiliki cara untuk menambahkan pengecualian pencocokan pola. Misalnya, saya memiliki pola yang mengecualikan baris apache-commons-logging sehingga tidak dihitung dalam cakupan.

Pilihan lainnya adalah membuat penginisialisasi statis yang mirip dengan kode berikut

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

  // real ops
}

Dengan cara ini konstruktor pribadi dianggap telah diuji, dan overhead waktu proses pada dasarnya tidak dapat diukur. Saya melakukan ini untuk mendapatkan cakupan 100% menggunakan EclEmma, ​​tetapi kemungkinan itu berhasil untuk setiap alat cakupan. Kelemahan dari solusi ini, tentu saja, adalah Anda menulis kode produksi (penginisialisasi statis) hanya untuk tujuan pengujian.

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

Terkadang Cobertura menandai kode yang tidak dimaksudkan untuk dieksekusi sebagai 'tidak tercakup', tidak ada yang salah dengan itu. Mengapa Anda lebih khawatir dengan 99%cakupan daripada 100%?

Secara teknis, Anda masih bisa memanggil konstruktor itu dengan refleksi, tetapi kedengarannya sangat salah bagi saya (dalam kasus ini).

Jika saya harus menebak maksud pertanyaan Anda, saya akan mengatakan:

1. Anda ingin pemeriksaan yang wajar untuk konstruktor pribadi yang melakukan pekerjaan aktual, dan
2. Anda ingin semanggi mengecualikan konstruktor kosong untuk kelas util.

Untuk 1, jelas Anda ingin semua inisialisasi dilakukan melalui metode pabrik. Dalam kasus seperti itu, pengujian Anda harus dapat menguji efek samping konstruktor. Ini harus termasuk dalam kategori pengujian metode privat normal. Buat metode menjadi lebih kecil sehingga mereka hanya melakukan sejumlah hal yang menentukan (idealnya, hanya satu hal dan satu hal dengan baik) dan kemudian uji metode yang mengandalkannya.

Misalnya, jika konstruktor [pribadi] saya menyiapkan bidang instance kelas saya ake 5. Lalu saya bisa (atau lebih tepatnya harus) mengujinya:

@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
}

Untuk 2, Anda dapat mengonfigurasi clover untuk mengecualikan konstruktor Util jika Anda memiliki pola penamaan yang ditetapkan untuk kelas Util. Misalnya, dalam proyek saya sendiri, saya menggunakan sesuatu seperti ini (karena kami mengikuti konvensi bahwa nama untuk semua kelas Util harus diakhiri dengan Util):

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

Saya sengaja meninggalkan .*berikut )karena konstruktor tersebut tidak dimaksudkan untuk memberikan pengecualian (mereka tidak dimaksudkan untuk melakukan apa pun).

Tentu saja ada kasus ketiga di mana Anda mungkin ingin memiliki konstruktor kosong untuk kelas non-utilitas. Dalam kasus seperti itu, saya akan merekomendasikan agar Anda meletakkan a methodContextdengan tanda tangan konstruktor yang tepat.

<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>

Jika Anda memiliki banyak kelas luar biasa seperti itu, Anda dapat memilih untuk memodifikasi reg-ex konstruktor privat umum yang saya sarankan dan menghapusnya Util. Dalam kasus ini, Anda harus memastikan secara manual bahwa efek samping konstruktor Anda masih diuji dan dicakup oleh metode lain di kelas / proyek Anda.

<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 adalah file sumber Anda, yang memiliki konstruktor pribadi Anda

Yang berikut ini bekerja pada saya di kelas yang dibuat dengan penjelasan Lombok @UtilityClass, yang secara otomatis menambahkan konstruktor pribadi.

@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
}

Meskipun konstruktor.setAccessible (true) seharusnya berfungsi ketika konstruktor privat ditulis secara manual, dengan anotasi Lombok tidak berfungsi, karena ia memaksanya. Constructor.newInstance () sebenarnya menguji bahwa konstruktor dipanggil dan ini melengkapi cakupan costructor itu sendiri. Dengan assertThrows Anda mencegah pengujian gagal dan Anda mengelola pengecualian karena persis seperti kesalahan yang Anda harapkan. Meskipun ini adalah solusi dan saya tidak menghargai konsep "cakupan garis" vs "cakupan fungsionalitas / perilaku", kami dapat menemukan pengertiannya pada tes ini. Bahkan Anda yakin bahwa Kelas Utilitas sebenarnya memiliki Pembuat pribadi yang dengan benar melontarkan pengecualian saat dipanggil juga melalui refleksi. Semoga ini membantu.

Pilihan yang saya sukai di 2019: Gunakan lombok.

Secara khusus, @UtilityClassanotasi . (Sayangnya hanya "eksperimental" pada saat penulisan, tetapi berfungsi dengan baik dan memiliki pandangan positif, sehingga kemungkinan akan segera ditingkatkan ke stabil.)

Anotasi ini akan menambahkan konstruktor privat untuk mencegah pembuatan instance dan membuat kelas menjadi final. Saat digabungkan dengan lombok.addLombokGeneratedAnnotation = truein lombok.config, hampir semua framework pengujian akan mengabaikan kode yang dibuat secara otomatis saat menghitung cakupan pengujian, memungkinkan Anda untuk melewati cakupan dari kode yang dibuat secara otomatis tanpa peretasan atau refleksi.

Tidak boleh.

Tampaknya Anda sedang membuat konstruktor pribadi untuk mencegah pembuatan instance kelas yang dimaksudkan untuk hanya berisi metode statis. Daripada mencoba mendapatkan cakupan konstruktor ini (yang mengharuskan kelas dibuat instance-nya), Anda harus membuangnya dan mempercayai developer Anda untuk tidak menambahkan metode instance ke kelas.