Özel bir işlevi veya özel yöntemleri, alanları veya iç sınıfları olan bir sınıfı nasıl test edebilirim?

Dahili özel yöntemleri, alanları veya iç içe sınıfları olan bir sınıfı nasıl test edebilirim (xUnit kullanarak)? Veya iç bağlantıya sahip ( staticC / C ++ 'da) veya özel ( anonim ) bir ad alanında bulunan özel bir işlev mi?

Yalnızca bir test çalıştırabilmek için bir yöntem veya işlevin erişim değiştiricisini değiştirmek kötü görünüyor.

Güncelleme:

Daha sonra belki özel bir yöntem veya herhangi ulaşılmaz üyesini sınamanın en iyi yolu yaklaşık 10 yıl, yoluyladır @Jailbreakgelen Manifold çerçeve.

@Jailbreak Foo foo = new Foo();
// Direct, *type-safe* access to *all* foo's members
foo.privateMethod(x, y, z);
foo.privateField = value;

Bu şekilde, kodunuz güvenli ve okunabilir kalır. Tasarımdan ödün vermez, testler için fazla pozlama yöntemleri ve alanları yoktur.

Biraz eski bir Java uygulamanız varsa ve yöntemlerinizin görünürlüğünü değiştirmenize izin verilmiyorsa, özel yöntemleri test etmenin en iyi yolu yansıma kullanmaktır .

Dahili olarak çağırmak ve yöntemler privateile private staticdeğişkenleri almak / ayarlamak için yardımcıları kullanıyoruz . Aşağıdaki modeller, özel yöntemler ve alanlarla ilgili hemen hemen her şeyi yapmanıza izin verecektir. Tabii ki, yansıma yoluyla değişkenleri değiştiremezsiniz .privateprivate staticprivate static final

Method method = TargetClass.getDeclaredMethod(methodName, argClasses);
method.setAccessible(true);
return method.invoke(targetObject, argObjects);

Ve alanlar için:

Field field = TargetClass.getDeclaredField(fieldName);
field.setAccessible(true);
field.set(object, value);

Notlar:
1. yöntemlere TargetClass.getDeclaredMethod(methodName, argClasses)bakmanızı sağlar private. Aynı şey için de geçerlidir getDeclaredField.
2. Bu setAccessible(true)haklar ile oynamak için gereklidir.

Özel bir yöntemi test etmenin en iyi yolu başka bir genel yöntemdir. Bu yapılamazsa, aşağıdaki koşullardan biri doğrudur:

1. Özel yöntem ölü koddur
2. Sınıfta test ettiğiniz bir tasarım kokusu var
3. Test etmeye çalıştığınız yöntem özel olmamalıdır

Bir sınıfta özel yöntemleri doğrudan test etme ihtiyacını hissettiğim kadar karmaşık olan özel yöntemlere sahip olduğumda, bu bir kod kokusudur: sınıfım çok karmaşık.

Bu tür sorunları ele almak için her zamanki yaklaşımım, ilginç bitleri içeren yeni bir sınıf çıkarmaktır. Genellikle, bu yöntem ve etkileşime girdiği alanlar ve belki başka bir yöntem veya iki yeni bir sınıfa çıkarılabilir.

Yeni sınıf bu yöntemleri 'genel' olarak ortaya koyar, böylece birim testi için erişilebilir olurlar. Yeni ve eski sınıflar artık orijinal sınıftan daha basit, bu benim için harika (işleri basit tutmam gerekiyor ya da kayboluyorum!).

İnsanların beyinlerini kullanmadan sınıflar oluşturmasını önermediğimi unutmayın! Buradaki nokta, iyi yeni sınıflar bulmanıza yardımcı olmak için birim test güçlerini kullanmaktır.

Geçmişte Java için bunu yapmak için yansıma kullandım ve bence bu büyük bir hataydı.

Belirtmek gerekir gerektiğini, konuşan değil , doğrudan özel yöntemler test birim testleri yazma. Test etmeniz gereken şey, sınıfın diğer nesnelerle sahip olduğu kamu sözleşmesidir; bir nesnenin içini asla doğrudan test etmemelisiniz. Başka bir geliştirici, sınıfta kamu sözleşmesini etkilemeyen, sınıfta küçük bir iç değişiklik yapmak istiyorsa, çalışmasını sağlamak için yansıma tabanlı testinizi değiştirmeniz gerekir. Bunu bir proje boyunca tekrar tekrar yaparsanız, birim testleri, kod sağlığının yararlı bir ölçümü olmayı bırakır ve gelişmenin önünde bir engel olmaya ve geliştirme ekibine bir sıkıntı olmaya başlar.

Bunun yerine önerdiğim, yazdığınız birim testlerinin özel yöntemlerde kodun iyi bir şekilde kapsanmasını sağlamak için Cobertura gibi bir kod kapsama aracı kullanmaktır. Bu şekilde, özel yöntemlerin ne yaptığını dolaylı olarak test edersiniz ve daha yüksek bir çeviklik sağlarsınız.

Bu makaleden: JUnit ve SuiteRunner (Bill Venners) ile Özel Yöntemleri Test Etme , temel olarak 4 seçeneğiniz vardır:

1. Özel yöntemleri test etmeyin.
2. Yöntem paketine erişim verin.
3. Yuvalanmış bir test sınıfı kullanın.
4. Yansımayı kullanın.

Genellikle bir birim testi, bir sınıfın veya birimin genel arayüzünü kullanmak için tasarlanmıştır. Bu nedenle, özel yöntemler, açıkça test etmeyi beklemediğiniz uygulama ayrıntısıdır.

Özel bir yöntemi test etmek istediğim noktalara sadece iki örnek:

1. Şifre çözme rutinleri - Sadece test uğruna görmek için onları kimseye görünür kılmak istemem, aksi takdirde kimse şifresini çözmek için kullanabilir. Ancak koda içseldir, karmaşıktır ve her zaman çalışması gerekir (bariz istisna, SecurityManagerbunu önlemek için yapılandırılmadığında çoğu durumda özel yöntemleri bile görüntülemek için kullanılabilen yansımadır ).
2. Topluluk tüketimi için bir SDK oluşturma . Burada kamu tamamen farklı bir anlam kazanır, çünkü bu tüm dünyanın görebileceği bir koddur (sadece uygulamamın içinde değil). SDK kullanıcılarının görmesini istemiyorsam özel yöntemlere kod koydum - Bunu kod kokusu olarak görmüyorum, sadece SDK programlama nasıl çalışıyor. Ama elbette hala özel yöntemlerimi test etmem gerekiyor ve SDK'mın işlevselliğinin gerçekte yaşadığı yer bunlar.

Sadece "sözleşmeyi" test etme fikrini anlıyorum. Ama aslında kod test değil savunucu göremiyorum - Kilometre değişebilir.

Yani benim ödünleşim, güvenlik ve SDK'mdan ödün vermek yerine JUnits'i yansıma ile karmaşıklaştırmayı içeriyor.

Özel yöntemler genel bir yöntemle çağrılır, bu nedenle genel yöntemlerinizin girdileri de bu genel yöntemlerle çağrılan özel yöntemleri test etmelidir. Genel bir yöntem başarısız olduğunda, bu özel yöntemde bir hata olabilir.

Kullandığım başka bir yaklaşım, özel veya korumalı paketlemek için özel bir yöntemi değiştirmek ve ardından Google Guava kütüphanesinin @VisibleForTesting ek açıklamasıyla tamamlamaktır .

Bu, bu yöntemi kullanan herkese dikkat etmesini ve bir pakette bile doğrudan erişmemesini söyler. Ayrıca, bir test sınıfının fiziksel olarak aynı pakette değil, test klasörü altındaki aynı pakette olması gerekir .

Örneğin, test edilecek bir yöntem varsa src/main/java/mypackage/MyClass.javatest çağrınızın yapılması gerekir src/test/java/mypackage/MyClassTest.java. Bu şekilde, test sınıfınızdaki test yöntemine erişebilirsiniz.

Eski kodu büyük ve ilginç sınıflarla test etmek için, şu anda yazdığım tek bir özel (veya genel) yöntemi test edebilmek genellikle çok yararlıdır .

Java için junitx.util.PrivateAccessor -package kullanıyorum . Özel yöntemlere ve özel alanlara erişmek için çok sayıda yararlı tek gömlek.

import junitx.util.PrivateAccessor;

PrivateAccessor.setField(myObjectReference, "myCrucialButHardToReachPrivateField", myNewValue);
PrivateAccessor.invoke(myObjectReference, "privateMethodName", java.lang.Class[] parameterTypes, java.lang.Object[] args);

Gelen Bahar Framework bu yöntemi kullanarak özel yöntemler test edebilirsiniz:

ReflectionTestUtils.invokeMethod()

Örneğin:

ReflectionTestUtils.invokeMethod(TestClazz, "createTest", "input data");

Cem Catikkas'ın çözümünü Java için yansıma kullanarak denedikten sonra, burada tarif ettiğimden daha zarif bir çözüm olduğunu söylemeliyim. Ancak, yansıma kullanmak için bir alternatif arıyorsanız ve test ettiğiniz kaynağa erişiminiz varsa, bu yine de bir seçenek olacaktır.

Herhangi bir kod yazmadan önce küçük testler tasarlamak istediğiniz bir sınıfın özel yöntemlerini, özellikle test odaklı geliştirmeyi test etmenin olası bir değeri vardır .

Özel üyelere ve yöntemlere erişerek bir test oluşturmak, yalnızca genel yöntemlere erişimle hedeflenmesi zor olan kod alanlarını test edebilir. Herkese açık bir yöntemin birkaç adımı varsa, daha sonra tek tek test edilebilen birkaç özel yöntemden oluşabilir.

Avantajları:

• Daha ince bir ayrıntıya kadar test edebilir

Dezavantajları:

• Test kodu, bakımı daha zor olabilecek kaynak koduyla aynı dosyada bulunmalıdır
• .Class çıktı dosyalarıyla aynı şekilde, kaynak kodda belirtilenle aynı pakette kalmaları gerekir

Bununla birlikte, sürekli test bu yöntemi gerektiriyorsa, geleneksel, kamuya açık bir şekilde test edilebilecek özel yöntemlerin çıkarılması gerektiğinin bir işareti olabilir.

İşte bunun nasıl çalışacağına dair karmaşık bir örnek:

// Import statements and package declarations

public class ClassToTest
{
    private int decrement(int toDecrement) {
        toDecrement--;
        return toDecrement;
    }

    // Constructor and the rest of the class

    public static class StaticInnerTest extends TestCase
    {
        public StaticInnerTest(){
            super();
        }

        public void testDecrement(){
            int number = 10;
            ClassToTest toTest= new ClassToTest();
            int decremented = toTest.decrement(number);
            assertEquals(9, decremented);
        }

        public static void main(String[] args) {
            junit.textui.TestRunner.run(StaticInnerTest.class);
        }
    }
}

İç sınıf derlenecekti ClassToTest$StaticInnerTest.

Ayrıca bakınız: Java İpucu 106: Eğlence ve kâr için statik iç sınıflar

Diğerlerinin söylediği gibi ... özel yöntemleri doğrudan test etmeyin. İşte birkaç düşünce:

1. Tüm yöntemleri küçük ve odaklanmış tutun (test edilmesi kolay, yanlış olanı bulmak kolay)
2. Kod kapsamı araçlarını kullanın. Cobertura'yı seviyorum (oh mutlu günler, yeni bir sürüm çıktı gibi görünüyor!)

Ünite testlerinde kod kapsamını çalıştırın. Yöntemlerin tam olarak test edilmediğini görürseniz kapsamı artırmak için testlere ekleyin. % 100 kod kapsamını hedefleyin, ancak muhtemelen alamayacağınızı unutmayın.

Özel yöntemler herkese açıktır. Aksi takdirde, ölü kodlardır. Bu yüzden genel yöntemi test edersiniz, genel yöntemin beklenen sonuçlarını ve böylece tükettiği özel yöntemleri iddia edersiniz.

Özel yöntemlerin test edilmesi, birim testlerinizi genel yöntemlerle çalıştırmadan önce hata ayıklama yoluyla test edilmelidir.

Ayrıca, tüm iddialarınız karşılanana kadar birim testlerinizde hata ayıklayarak, test odaklı geliştirme kullanılarak hata ayıklanabilirler.

Şahsen TDD kullanarak sınıf oluşturmanın daha iyi olduğuna inanıyorum; genel yöntem koçanlarını oluşturmak, daha sonra önceden tanımlanan tüm iddialarla birim testleri oluşturmak , böylece yöntemin beklenen sonucu siz kodlamadan önce belirlenir. Bu şekilde, birim test iddialarını sonuçlara uydurmak için yanlış yola girmezsiniz. Sınıfınız daha sonra sağlamdır ve tüm birim testleriniz geçtiğinde gereksinimleri karşılar.

Spring kullanıyorsanız, ReflectionTestUtils , burada en az çabayla yardımcı olan bazı kullanışlı araçlar sağlar. Örneğin, istenmeyen bir genel ayarlayıcı eklemek zorunda kalmadan özel bir üyeye alay etmek için:

ReflectionTestUtils.setField(theClass, "theUnsettableField", theMockObject);

İsteksiz veya değiştiremediğiniz mevcut kodu test etmeye çalışıyorsanız, yansıma iyi bir seçimdir.

Sınıfın tasarımı hala esnekse ve ayrı ayrı test etmek istediğiniz karmaşık bir özel yönteminiz varsa, onu ayrı bir sınıfa çıkarmanızı ve bu sınıfı ayrı ayrı test etmenizi öneririm. Bunun orijinal sınıfın genel arayüzünü değiştirmesi gerekmez; dahili olarak helper sınıfının bir örneğini oluşturabilir ve helper yöntemini çağırabilir.

Yardımcı yöntemden gelen zor hata koşullarını test etmek istiyorsanız, bir adım daha ileri gidebilirsiniz. Yardımcı sınıftan bir arabirim ayıklayın, yardımcı sınıfı (arabirimi aracılığıyla kullanılır) enjekte etmek için orijinal sınıfa bir ortak alıcı ve ayarlayıcı ekleyin ve ardından özgün sınıfın nasıl sahte bir sürümünü orijinal sınıfın içine sınayın. yardımcıdan istisnalara cevap verir. Bu yaklaşım, yardımcı sınıfı test etmeden orijinal sınıfı test etmek istiyorsanız da yararlıdır.

Özel yöntemleri test etmek, dahili uygulamayı her değiştirdiğinizde istemci kodunu kırdığınızda (bu durumda testler) sınıfınızın kapsüllenmesini bozar.

Bu yüzden özel yöntemleri test etmeyin.

JUnit.org SSS sayfasından cevap :

Ama eğer ...

JDK 1.3 veya üstünü kullanıyorsanız, erişim kontrol mekanizmasını PrivilegedAccessor yardımıyla değiştirmek için yansımayı kullanabilirsiniz . Nasıl kullanılacağı hakkında ayrıntılar için bu makaleyi okuyun .

JDK 1.6 veya üstünü kullanıyorsanız ve @Test ile testlerinize açıklama ekliyorsanız, test yöntemlerinize yansıma eklemek için Dp4j'yi kullanabilirsiniz . Nasıl kullanılacağı hakkında ayrıntılar için bu test komut dosyasına bakın .

PS: Ben Dp4j ana katkıda , ben yardıma ihtiyacınız olup olmadığını sor . :)

Kodu değiştiremeyeceğiniz eski bir uygulamanın özel yöntemlerini test etmek isterseniz, Java için bir seçenek , sınıfa özel olduklarında bile bir nesneye alay oluşturmanıza izin veren jMockit'dir .

Özel yöntemleri test etmeme eğilimindeyim. Delilik yatıyor. Şahsen, sadece halka açık arayüzlerinizi test etmeniz gerektiğine inanıyorum (ve korumalı ve dahili yöntemleri içerir).

JUnit kullanıyorsanız, junit-eklentilerine bir göz atın . Java güvenlik modelini yoksayma ve özel yöntemlere ve özniteliklere erişme yeteneğine sahiptir.

Kodunuzu biraz yeniden düzenlemenizi öneririm. Sadece kodunuzu test etmek için yansıma veya başka tür şeyler kullanmayı düşünmeniz gerektiğinde, kodunuzla ilgili bir sorun var.

Farklı sorun türlerinden bahsettiniz. Özel alanlarla başlayalım. Özel alanlar durumunda, yeni bir kurucu ekledim ve buna enjekte edilen alanlar ekleyecektim. Bunun yerine:

public class ClassToTest {

    private final String first = "first";
    private final List<String> second = new ArrayList<>();
    ...
}

Bunu kullanırdım:

public class ClassToTest {

    private final String first;
    private final List<String> second;

    public ClassToTest() {
        this("first", new ArrayList<>());
    }

    public ClassToTest(final String first, final List<String> second) {
        this.first = first;
        this.second = second;
    }
    ...
}

Bazı eski kodlarda bile bu sorun olmaz. Eski kod boş bir kurucu kullanacak ve bana sorarsanız, yeniden düzenlenmiş kod daha temiz görünecek ve yansıma olmadan testte gerekli değerleri enjekte edebileceksiniz.

Şimdi özel yöntemler hakkında. Kişisel deneyimlerime göre, test için özel bir yöntemi saplamak zorunda kaldığınızda, o yöntemin o sınıfta bir ilgisi yoktur. Ortak bir desen, bu durumda, bir arayüz içine sarmak gibi olur Callableve daha sonra bu arayüze yapıcıda da (bu çoklu kurucu hile ile) geçersiniz:

public ClassToTest() {
    this(...);
}

public ClassToTest(final Callable<T> privateMethodLogic) {
    this.privateMethodLogic = privateMethodLogic;
}

Çoğunlukla yazdığım tek şey bağımlılık enjeksiyon modeli gibi görünüyor. Kişisel deneyimlerime göre test ederken bu gerçekten kullanışlı ve bence bu tür kodlar daha temiz ve bakımı daha kolay olacak. Aynı şeyi iç içe dersler için de söyleyebilirim. Yuvalanmış bir sınıf ağır mantık içeriyorsa, onu bir paket özel sınıfı olarak taşıdıysanız ve buna ihtiyaç duyan bir sınıfa enjekte etseniz daha iyi olur.

Ayrıca eski kodu yeniden düzenlerken ve korurken kullandığım birkaç tasarım deseni daha var, ancak hepsi test etmek için kodunuzun durumlarına bağlı. Yansımayı kullanmak çoğunlukla bir sorun değildir, ancak yoğun bir şekilde test edilen ve her dağıtımdan önce testler yapılan bir kurumsal uygulamanız olduğunda her şey gerçekten yavaşlar (sadece sinir bozucu ve bu tür şeyleri sevmiyorum).

Ayrıca setter enjeksiyonu var, ama kullanmanızı tavsiye etmem. Bir kurucuya bağlı kalsam ve gerçekten gerekli olduğunda her şeyi başlatırsam, gerekli bağımlılıkları enjekte etme olasılığını bırakırsam.

Özel bir yönteme sadece aynı sınıftan erişilmelidir. Dolayısıyla, herhangi bir test sınıfından bir hedef sınıfın “özel” yöntemini test etmenin bir yolu yoktur. Bir çıkış yöntemi, manuel olarak birim testi yapabilmeniz veya yönteminizi “özel” den “korumalı” olarak değiştirebilmenizdir.

Ve sonra korumalı bir yönteme yalnızca sınıfın tanımlandığı pakette erişilebilir. Dolayısıyla, hedef sınıfın korumalı bir yöntemini test etmek, test sınıfınızı hedef sınıfla aynı pakette tanımlamamız gerektiği anlamına gelir.

Yukarıdakilerin tümü gereksiniminize uygun değilse , özel yönteme erişmek için yansıma yolunu kullanın.

Yukarıda belirtildiği gibi, iyi bir yol onları genel arayüzleriniz aracılığıyla test etmektir.

Bunu yaparsanız, özel yöntemlerinizin gerçekten testlerinizden yürütülüp yürütülmediğini görmek için bir kod kapsamı aracı (Emma gibi) kullanmak iyi bir fikirdir.

İşte özel alanları test etmek için benim genel işlevi:

protected <F> F getPrivateField(String fieldName, Object obj)
    throws NoSuchFieldException, IllegalAccessException {
    Field field =
        obj.getClass().getDeclaredField(fieldName);

    field.setAccessible(true);
    return (F)field.get(obj);
}

Örnek için lütfen aşağıya bakın;

Aşağıdaki içe aktarma ifadesi eklenmelidir:

import org.powermock.reflect.Whitebox;

Şimdi özel yöntem, çağrılacak yöntem adı ve ek parametreleri içeren nesneyi doğrudan aşağıdaki gibi aktarabilirsiniz.

Whitebox.invokeMethod(obj, "privateMethod", "param1");

Bugün, özel yöntemlerin ve alanların test edilmesine yardımcı olmak için bir Java kütüphanesi ittim. Android göz önünde bulundurularak tasarlanmıştır, ancak herhangi bir Java projesi için gerçekten kullanılabilir.

Özel yöntemlerle veya alanlarla veya kurucularla bazı kodlarınız varsa, BoundBox'ı kullanabilirsiniz . Tam olarak aradığınızı yapar. Aşağıda, bir Android etkinliğinin test edilmesi için iki özel alanına erişen bir test örneği verilmiştir:

@UiThreadTest
public void testCompute() {

    // Given
    boundBoxOfMainActivity = new BoundBoxOfMainActivity(getActivity());

    // When
    boundBoxOfMainActivity.boundBox_getButtonMain().performClick();

    // Then
    assertEquals("42", boundBoxOfMainActivity.boundBox_getTextViewMain().getText());
}

BoundBox özel / korumalı alanları, yöntemleri ve yapıcıları test etmeyi kolaylaştırır. Kalıtımla gizlenen öğelere bile erişebilirsiniz. Gerçekten de, BoundBox kapsüllemeyi keser. Her şeye yansıma yoluyla erişmenizi sağlar, ancak her şey derleme zamanında kontrol edilir.

Bazı eski kodları test etmek için idealdir. Dikkatlice kullanın. ;)

https://github.com/stephanenicolas/boundbox

İlk olarak, şu soruyu atacağım: Özel üyelerinizin neden izole testlere ihtiyacı var? Bunlar, kamu yüzeyinden ayrı olarak test edilmeyi gerektirecek karmaşık davranışlar sağlayan karmaşık mı? 'Kod satırı' testi değil, birim testi. Küçük şeyleri terlemeyin.

Eğer bu kadar büyük, bu özel üyelerin her biri karmaşık bir 'birim' olacak kadar büyüklerse - bu tür özel üyeleri bu sınıftan yeniden düzenlemeyi düşünün.

Yeniden düzenleme uygun değilse veya mümkün değilse, birim sınaması sırasında bu özel üye işlevlerine / üye sınıflarına erişimi değiştirmek için strateji modelini kullanabilir misiniz? Birim sınaması altında, strateji ek doğrulama sağlar, ancak sürüm derlemelerinde bu basit geçiş olacaktır.

Son zamanlarda bu sorun vardı ve açıkça Java yansıma API, iki örnek kullanma sorunları önler Picklock adlı küçük bir araç yazdı :

Arama yöntemleri, örneğin private void method(String s)- Java yansıması ile

Method method = targetClass.getDeclaredMethod("method", String.class);
method.setAccessible(true);
return method.invoke(targetObject, "mystring");

Arama yöntemleri, örneğin private void method(String s)- Picklock tarafından

interface Accessible {
  void method(String s);
}

...
Accessible a = ObjectAccess.unlock(targetObject).features(Accessible.class);
a.method("mystring");

Ayar alanları, örneğin private BigInteger amount;- Java yansıması ile

Field field = targetClass.getDeclaredField("amount");
field.setAccessible(true);
field.set(object, BigInteger.valueOf(42));

Ayar alanları, örneğin private BigInteger amount;- Picklock tarafından

interface Accessible {
  void setAmount(BigInteger amount);
}

...
Accessible a = ObjectAccess.unlock(targetObject).features(Accessible.class);
a.setAmount(BigInteger.valueOf(42));

PowerMockito bunun için üretildi. Maven bağımlılığını kullan

<dependency>
    <groupId>org.powermock</groupId>
    <artifactId>powermock-mockito-release-full</artifactId>
    <version>1.6.4</version>
</dependency>

Sonra yapabilirsin

import org.powermock.reflect.Whitebox;
...
MyClass sut = new MyClass();
SomeType rval = Whitebox.invokeMethod(sut, "myPrivateMethod", params, moreParams);