Özel bir kurucuya test kapsamı nasıl eklenir?

Kod bu:

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

Bu test:

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

İyi çalışıyor, sınıf test edildi. Ancak Cobertura, sınıfın özel kurucusunun sıfır kod kapsamı olduğunu söylüyor. Böyle özel bir kurucuya nasıl test kapsamı ekleyebiliriz?

Pekala, potansiyel olarak yansımayı kullanabileceğiniz yollar var - ama buna gerçekten değer mi? Bu asla çağrılmaması gereken bir kurucu , değil mi?

Cobertura'nın çağrılmayacağını anlamasını sağlamak için sınıfa ekleyebileceğiniz bir not veya benzeri bir şey varsa, bunu yapın: Yapay olarak kapsama eklemek için çemberlerden geçmeye değeceğini sanmıyorum.

DÜZENLEME: Bunu yapmanın bir yolu yoksa, sadece biraz azaltılmış kapsama alanıyla yaşayın. Kapsamın sizin için yararlı olan bir şey olduğunu unutmayın - tam tersi değil, araçtan siz sorumlu olmalısınız.

Jon Skeet'e tamamen katılmıyorum. Bence, kapsama alanı sağlamak ve haber raporunuzdaki gürültüyü gidermek için kolay bir kazanç elde edebiliyorsanız, o zaman yapmalısınız. Ya kapsama aracınıza kurucuyu görmezden gelmesini söyleyin ya da idealizmi bir kenara bırakın ve aşağıdaki testi yazın ve onunla bitirin:

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

Kapsam için zorunlu olmasa da, yardımcı program sınıfının iyi tanımlandığını ve biraz da kapsama aldığını doğrulamak için bu yöntemi yarattı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);
        }
    }
}

Tam kodu ve örnekleri https://github.com/trajano/maven-jee6/tree/master/maven-jee6-test'e yerleştirdim

CheckStyle'ı tatmin etmek için, statik fayda fonksiyonları sınıfımın yapıcısı özel yaptım. Ama orijinal afiş gibi, Cobertura da testten şikayet etti. İlk başta bu yaklaşımı denedim, ancak bu, kapsama raporunu etkilemiyor çünkü kurucu aslında hiçbir zaman çalıştırılmıyor. Yani gerçekten tüm bu testler, kurucunun gizli kalmasıdır - ve bu, sonraki testteki erişilebilirlik kontrolü tarafından gereksiz hale getirilir.

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

Javid Jamae'nin önerisiyle gittim ve yansımayı kullandım, ancak test edilen sınıfla uğraşan herkesi yakalamak için iddialar ekledim (ve testi Yüksek Seviyelerde Kötüyü belirtmek için adlandırdım).

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

Bu çok abartılı, ancak% 100 yöntem kapsamının sıcak bulanık hissini sevdiğimi itiraf etmeliyim.

Java 8 ile başka bir çözüm bulmak mümkün.

Birkaç public static yöntemle fayda sınıfı oluşturmak istediğinizi varsayıyorum. Java 8 kullanabiliyorsanız, interfaceonun yerine kullanabilirsiniz .

package com.XXX;

public interface Foo {

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

Yapıcı yok ve Cobertura'dan şikayetçi yok. Şimdi yalnızca gerçekten önem verdiğiniz satırları test etmeniz gerekiyor.

Hiçbir şey yapmayan kodu test etmenin ardındaki mantık,% 100 kod kapsamına ulaşmak ve kod kapsamının ne zaman düştüğünü fark etmektir. Aksi takdirde kişi her zaman şöyle düşünebilirdi, hey artık% 100 kod kapsamım yok ama MUHTEMELEN özel kurucularımdan dolayı. Bu, sadece özel bir kurucu olup olmadığını kontrol etmek zorunda kalmadan test edilmemiş yöntemleri tespit etmeyi kolaylaştırır. Kod tabanınız büyüdükçe, aslında% 99 yerine% 100'e bakarak güzel bir sıcaklık hissedeceksiniz.

IMO burada yansımayı kullanmak en iyisidir, çünkü aksi takdirde ya bu oluşturucuları yok sayan daha iyi bir kod kapsama aracı edinmeniz ya da bir şekilde kod kapsama aracına yöntemi görmezden gelmesini söylemeniz gerekir (belki bir Ek Açıklama veya bir yapılandırma dosyası) çünkü o zaman takılıp kalırsınız belirli bir kod kapsama aracı ile.

Kusursuz bir dünyada tüm kod kapsama araçları, son bir sınıfa ait olan özel kurucuları yok sayar çünkü kurucu orada "güvenlik" olarak başka hiçbir şeyi ölçmez :)
Bu kodu kullanırdım:

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

Cobertura'nın daha yeni sürümleri, önemsiz alıcıları / ayarlayıcıları / kurucuları yok saymak için yerleşik desteğe sahiptir:

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

Önemsizliği Yoksay

Önemsizliği yoksay, bir satır kod içeren yapıcıları / yöntemleri dışlama yeteneğine izin verir. Bazı örnekler yalnızca bir süper yorumcunun çağrısını, alıcı / ayarlayıcı yöntemlerini vb. İçerir. Önemsiz yok sayma bağımsız değişkenini dahil etmek için aşağıdakileri ekleyin:

<cobertura-instrument ignoreTrivial="true" />

veya bir Gradle yapısında:

cobertura {
    coverageIgnoreTrivial = true
}

Yapma. Boş bir kurucuyu test etmenin amacı nedir? Cobertura 2.0, bu tür önemsiz durumları (ayarlayıcılar / alıcılarla birlikte) göz ardı etme seçeneği olduğundan, cobertura maven eklentisine yapılandırma bölümü ekleyerek maven'de etkinleştirebilirsiniz:

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

Alternatif kullanabilirsiniz Kapsama Ek Açıklamalar : @CoverageIgnore.

Sonunda bir çözüm var!

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

Cobertura hakkında bilgim yok ama Clover kullanıyorum ve bu, desen eşleştirme istisnaları ekleme yoluna sahip. Örneğin, apache-commons-logging satırlarını kapsam dışında bırakan desenlerim var.

Diğer bir seçenek, aşağıdaki koda benzer bir statik başlatıcı oluşturmaktır.

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

  // real ops
}

Bu şekilde özel kurucu test edilmiş sayılır ve çalışma zamanı ek yükü temelde ölçülemez. Bunu EclEmma kullanarak% 100 kapsama elde etmek için yapıyorum, ancak muhtemelen her kapsama aracı için işe yarıyor. Bu çözümün dezavantajı, elbette, üretim kodunu (statik başlatıcı) yalnızca test amacıyla yazmanızdır.

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

Bazen Cobertura, yürütülmesi amaçlanmayan kodu 'kapsam dışı' olarak işaretler, bunda yanlış bir şey yoktur. Neden 99%bunun yerine teminat almakla ilgileniyorsunuz 100%?

Teknik olarak, yine de bu kurucuyu yansıma ile çağırabilirsiniz, ancak bu bana çok yanlış geliyor (bu durumda).

Sorunuzun amacını tahmin etseydim derdim:

1. Gerçek iş yapan özel müteahhitler için makul kontroller istiyorsunuz ve
2. Clover'ın kullanım sınıfları için boş kurucuları dışlamasını istiyorsunuz.

1 için, tüm başlatmanın fabrika yöntemleriyle yapılmasını istediğiniz açıktır. Bu gibi durumlarda, testleriniz kurucunun yan etkilerini test edebilmelidir. Bu, normal özel yöntem testi kategorisine girmelidir. Yöntemleri küçültün, böylece yalnızca sınırlı sayıda belirleyici şey (ideal olarak, yalnızca bir şey ve bir şey iyi) yapın ve sonra onlara dayanan yöntemleri test edin.

Örneğin, [private] kurucum sınıfımın örnek alanlarını aiçin ayarlarsa 5. O zaman test edebilirim (veya daha doğrusu test etmeliyim):

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

2 için, Util sınıfları için belirlenmiş bir adlandırma modeliniz varsa, clover'ı Util oluşturucularını hariç tutacak şekilde yapılandırabilirsiniz. Örneğin, kendi projemde buna benzer bir şey kullanıyorum (çünkü tüm Util sınıflarının isimlerinin Util ile bitmesi gerektiği kuralına uyuyoruz):

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

Ben kasıtlı olarak dışarı bırakmış .*aşağıdaki) çünkü bu tür kurucular istisnalar atmak anlamına gelmez (hiçbir şey yapmaları amaçlanmamıştır).

Elbette, fayda sınıfı olmayan bir sınıf için boş bir kurucuya sahip olmak isteyebileceğiniz üçüncü bir durum olabilir. Bu gibi durumlarda, methodContextkurucunun tam imzasıyla bir koymanızı tavsiye ederim .

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

Bu kadar çok istisnai sınıfınız varsa, önerdiğim genelleştirilmiş özel kurucu reg-ex'i değiştirmeyi ve kaldırmayı seçebilirsiniz. Util ondan . Bu durumda, kurucunuzun yan etkilerinin hala test edildiğinden ve sınıfınızdaki / projenizdeki diğer yöntemlerle kaplandığından emin olmanız gerekecektir.

<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, özel oluşturucunuzu içeren kaynak dosyanızdır

Aşağıdakiler, otomatik olarak özel bir kurucu ekleyen Lombok ek açıklaması @UtilityClass ile oluşturulan bir sınıfta çalıştı.

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

Constructor.setAccessible (true), özel kurucu manuel olarak yazıldığında çalışmasına rağmen, Lombok ek açıklaması onu zorladığından çalışmaz. Constructor.newInstance () aslında yapıcının çağrıldığını test eder ve bu, oluşturucunun kendi kapsamını tamamlar. AssertThrows ile testin başarısız olmasını engellersiniz ve istisnayı yönetirsiniz çünkü tam olarak beklediğiniz hata budur. Bu bir geçici çözüm olmasına ve "kapsama alanı" ile "işlevsellik / davranış kapsamı" kavramını takdir etmeme rağmen, bu testte bir anlam bulabiliriz. Aslında, Fayda Sınıfının aslında reflaction yoluyla da çağrıldığında bir istisnayı doğru şekilde atan özel bir Kurucuya sahip olduğundan eminsiniz. Bu yardımcı olur umarım.

2019'da tercih ettiğim seçenek: lombok kullan.

Özellikle, @UtilityClassek açıklama . (Yazma sırasında ne yazık ki yalnızca "deneysel", ancak gayet iyi çalışıyor ve olumlu bir görünümü var, bu nedenle yakında kararlı hale getirilmesi muhtemel.)

Bu açıklama, başlatmayı önlemek için özel kurucuyu ekleyecek ve sınıfı son hale getirecektir. lombok.addLombokGeneratedAnnotation = trueIn ile birleştirildiğinde lombok.config, hemen hemen tüm test çerçeveleri, test kapsamını hesaplarken otomatik olarak oluşturulan kodu göz ardı ederek, otomatik olarak oluşturulan kodun kapsamını hiçbir hack veya yansıma olmadan atlamanıza olanak tanır.

Yapamazsın.

Görünüşe göre, yalnızca statik yöntemler içermesi amaçlanan bir sınıfın somutlaştırılmasını önlemek için özel oluşturucuyu oluşturuyorsunuz. Bu kurucunun kapsamını almaya çalışmak yerine (bu, sınıfın somutlaştırılmasını gerektirir), ondan kurtulmalı ve geliştiricilerinizin sınıfa örnek yöntemleri eklemeyeceğine güvenmelisiniz.