Jak przetestować funkcję prywatną lub klasę, która ma prywatne metody, pola lub klasy wewnętrzne?

Jak przetestować jednostkę (używając xUnit) klasy, która ma wewnętrzne metody prywatne, pola lub klasy zagnieżdżone? A może funkcja, która jest prywatna dzięki wewnętrznemu powiązaniu ( staticw C / C ++) lub jest w prywatnej ( anonimowej ) przestrzeni nazw?

Zmiana modyfikatora dostępu do metody lub funkcji wydaje się zła, aby móc uruchomić test.

Aktualizacja:

Jakieś 10 lat później być może najlepszym sposobem przetestowania prywatnej metody lub dowolnego niedostępnego członka jest skorzystanie @Jailbreakz frameworka Manifold .

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

W ten sposób Twój kod pozostaje bezpieczny i czytelny. Żadnych kompromisów projektowych, żadnych metod i pól prześwietlania na potrzeby testów.

Jeśli masz nieco starszą aplikację Java i nie możesz zmienić widoczności swoich metod, najlepszym sposobem na przetestowanie metod prywatnych jest użycie refleksji .

Wewnętrznie używamy pomocników do pobierania / ustawiania privatei private staticzmiennych, a także wywoływania privatei private staticmetod. Poniższe wzory pozwolą ci zrobić prawie wszystko, co jest związane z prywatnymi metodami i polami. Oczywiście nie można zmieniać private static finalzmiennych poprzez odbicie.

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

A dla pól:

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

Uwagi:
1. TargetClass.getDeclaredMethod(methodName, argClasses)pozwala spojrzeć na privatemetody. To samo dotyczy getDeclaredField.
2. Wymagane setAccessible(true)jest, aby bawić się z szeregowymi.

Najlepszym sposobem przetestowania metody prywatnej jest inna metoda publiczna. Jeśli nie można tego zrobić, spełniony jest jeden z następujących warunków:

1. Metoda prywatna to martwy kod
2. W pobliżu testowanej klasy wyczuwa się zapach wzorniczy
3. Metoda, którą próbujesz przetestować, nie powinna być prywatna

Kiedy mam prywatne metody w klasie, które są na tyle skomplikowane, że odczuwam potrzebę bezpośredniego przetestowania metod prywatnych, to jest zapach kodu: moja klasa jest zbyt skomplikowana.

Moje zwykłe podejście do rozwiązywania takich problemów polega na wprowadzeniu nowej klasy, która zawiera interesujące elementy. Często ta metoda i pola, z którymi wchodzi w interakcje, a może inna metoda lub dwie mogą zostać wyodrębnione do nowej klasy.

Nowa klasa ujawnia te metody jako „publiczne”, więc są one dostępne do testów jednostkowych. Zarówno nowa, jak i stara klasa są teraz prostsze niż klasa oryginalna, co jest dla mnie świetne (muszę zachować prostotę, inaczej się zgubię!).

Pamiętaj, że nie sugeruję, aby ludzie tworzyli zajęcia bez korzystania z mózgu! Chodzi o to, aby użyć siły testowania jednostkowego, aby pomóc ci znaleźć dobre nowe klasy.

W przeszłości korzystałem z refleksji, aby to zrobić dla Javy, i moim zdaniem był to duży błąd.

Ściśle rzecz biorąc, powinno nie być pisanie testów jednostkowych, które bezpośrednio testowania metod prywatnych. To, co powinieneś przetestować, to umowa publiczna, którą klasa ma z innymi przedmiotami; nigdy nie należy bezpośrednio testować wewnętrznych elementów obiektu. Jeśli inny programista chce wprowadzić niewielką wewnętrzną zmianę w klasie, która nie wpływa na zamówienie publiczne na zajęcia, musi zmodyfikować test oparty na refleksji, aby upewnić się, że działa. Jeśli robisz to wielokrotnie w trakcie projektu, testy jednostkowe przestają być użytecznym pomiarem stanu kodu i stają się przeszkodą w rozwoju oraz irytacją dla zespołu programistów.

Zamiast tego zalecam korzystanie z narzędzia pokrycia kodu, takiego jak Cobertura, aby upewnić się, że pisane testy jednostkowe zapewniają przyzwoite pokrycie kodu metodami prywatnymi. W ten sposób pośrednio testujesz, co robią prywatne metody, i utrzymujesz wyższy poziom zwinności.

Z tego artykułu: Testowanie metod prywatnych za pomocą JUnit i SuiteRunner (Bill Venners), w zasadzie masz 4 opcje:

1. Nie testuj metod prywatnych.
2. Daj dostęp do pakietu metod.
3. Użyj zagnieżdżonej klasy testowej.
4. Użyj refleksji.

Zasadniczo test jednostkowy ma na celu wykonanie publicznego interfejsu klasy lub jednostki. W związku z tym metody prywatne są szczegółami implementacji, których nie można oczekiwać bezpośrednio testować.

Tylko dwa przykłady, w których chciałbym przetestować metodę prywatną:

1. Procedury deszyfrowania - nie chciałbym, aby były widoczne dla każdego, kto mógłby je zobaczyć tylko ze względu na testowanie, w przeciwnym razie każdy może ich użyć do odszyfrowania. Są one jednak nieodłącznie związane z kodem, skomplikowane i muszą zawsze działać (oczywistym wyjątkiem jest odbicie, które w większości przypadków można wykorzystać do przeglądania nawet prywatnych metod, jeśli SecurityManagernie jest skonfigurowane, aby temu zapobiec).
2. Tworzenie zestawu SDK do użytku społeczności. Tutaj public ma zupełnie inne znaczenie, ponieważ jest to kod, który może zobaczyć cały świat (nie tylko wewnętrzny dla mojej aplikacji). Umieszczam kod w metodach prywatnych, jeśli nie chcę, aby użytkownicy SDK go widzieli - nie widzę w nim zapachu kodu, a jedynie działania programu SDK. Ale oczywiście nadal muszę przetestować moje prywatne metody i tam właśnie funkcjonuje mój zestaw SDK.

Rozumiem pomysł testowania tylko „kontraktu”. Ale nie widzę, aby można było opowiadać się za nie testowaniem kodu - przebieg może się różnić.

Więc mój kompromis polega na komplikowaniu JUnits refleksją, a nie na naruszeniu bezpieczeństwa i zestawu SDK.

Metody prywatne są wywoływane przez metodę publiczną, więc dane wejściowe do metod publicznych powinny również testować metody prywatne wywoływane przez te metody publiczne. Gdy metoda publiczna zawiedzie, może to oznaczać awarię metody prywatnej.

Innym podejściem, którego użyłem, jest zmiana prywatnej metody na prywatną lub chronioną, a następnie uzupełnienie jej adnotacją @VisibleForTesting biblioteki Google Guava.

To powie każdemu, kto używa tej metody, aby zachował ostrożność i nie uzyskał bezpośredniego dostępu nawet w pakiecie. Również klasa testowa nie musi znajdować się fizycznie w tym samym pakiecie, ale w tym samym pakiecie w folderze testowym .

Na przykład, jeśli istnieje metoda, która ma zostać przetestowana, src/main/java/mypackage/MyClass.javawówczas należy wprowadzić wywołanie testowe src/test/java/mypackage/MyClassTest.java. W ten sposób masz dostęp do metody testowej w swojej klasie testowej.

Aby przetestować starszy kod za pomocą dużych i dziwacznych klas, często bardzo pomocne jest przetestowanie jednej prywatnej (lub publicznej) metody, którą piszę teraz .

Korzystam z pakietu junitx.util.PrivateAccessor dla Java. Wiele pomocnych jedno-liniowych narzędzi umożliwiających dostęp do prywatnych metod i prywatnych pól.

import junitx.util.PrivateAccessor;

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

W Spring Framework możesz testować prywatne metody przy użyciu tej metody:

ReflectionTestUtils.invokeMethod()

Na przykład:

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

Po wypróbowaniu rozwiązania Cem Catikkas za pomocą odbicia dla Javy, muszę powiedzieć, że jego rozwiązanie było bardziej eleganckie niż to tutaj opisałem. Jeśli jednak szukasz alternatywy dla używania refleksji i masz dostęp do testowanego źródła, nadal będzie to możliwe.

Możliwe są zalety testowania prywatnych metod klasy, szczególnie w przypadku programowania opartego na testach , w którym chciałbyś zaprojektować małe testy przed napisaniem jakiegokolwiek kodu.

Utworzenie testu z dostępem do prywatnych członków i metod może testować obszary kodu, które są trudne do ukierunkowania, szczególnie z dostępem tylko do metod publicznych. Jeśli metoda publiczna obejmuje kilka etapów, może składać się z kilku metod prywatnych, które można następnie przetestować indywidualnie.

Zalety:

• Może testować z większą dokładnością

Niedogodności:

• Kod testowy musi znajdować się w tym samym pliku co kod źródłowy, co może być trudniejsze w utrzymaniu
• Podobnie z plikami wyjściowymi .class, muszą pozostać w tym samym pakiecie, co zadeklarowano w kodzie źródłowym

Jeśli jednak ciągłe testowanie wymaga tej metody, może to być sygnał, że należy wyodrębnić metody prywatne, które można przetestować w tradycyjny, publiczny sposób.

Oto skomplikowany przykład tego, jak to by działało:

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

Klasa wewnętrzna zostałaby skompilowana ClassToTest$StaticInnerTest .

Zobacz także: Java Tip 106: Statyczne klasy wewnętrzne dla zabawy i zysku

Jak powiedzieli inni ... nie testuj metod prywatnych bezpośrednio. Oto kilka myśli:

1. Wszystkie metody powinny być małe i skoncentrowane (łatwe do przetestowania, łatwe do znalezienia, co jest nie tak)
2. Użyj narzędzi do pokrywania kodu. Lubię Coberturę (och, szczęśliwy dzień, wygląda na to, że nowa wersja została wydana!)

Uruchom obsługę kodu w testach jednostkowych. Jeśli zauważysz, że metody nie są w pełni przetestowane, dodaj je do testów, aby zwiększyć zasięg. Celuj w 100% pokrycie kodu, ale zdaj sobie sprawę, że prawdopodobnie go nie dostaniesz.

Metody prywatne są konsumowane przez metody publiczne. W przeciwnym razie są martwym kodem. Dlatego testujesz metodę publiczną, potwierdzając oczekiwane wyniki metody publicznej, a tym samym metod prywatnych, które zużywa.

Testowanie metod prywatnych należy przetestować poprzez debugowanie przed uruchomieniem testów jednostkowych na metodach publicznych.

Mogą być również debugowane przy użyciu programowania opartego na testach, debugując testy jednostkowe, dopóki wszystkie asercje nie zostaną spełnione.

Osobiście uważam, że lepiej jest tworzyć klasy przy użyciu TDD; tworzenie kodów pośredniczących metody publicznej, a następnie generowanie testów jednostkowych ze wszystkimi asercjami wcześniej zdefiniowanymi, więc oczekiwany wynik metody jest określany przed jej kodowaniem. W ten sposób nie pójdziesz niewłaściwą ścieżką dopasowania stwierdzeń testu jednostkowego do wyników. Twoja klasa jest wtedy solidna i spełnia wymagania, gdy wszystkie testy jednostkowe przejdą pomyślnie.

Jeśli używasz Springa, ReflectionTestUtils zapewnia kilka przydatnych narzędzi, które pomagają tutaj przy minimalnym wysiłku. Na przykład, aby skonfigurować próbkę na prywatnym elemencie, bez konieczności dodawania niepożądanego ustawienia publicznego:

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

Jeśli próbujesz przetestować istniejący kod, którego nie chcesz lub nie możesz zmienić, odbicie jest dobrym wyborem.

Jeśli projekt klasy jest nadal elastyczny, a masz skomplikowaną metodę prywatną, którą chciałbyś przetestować osobno, sugeruję, abyś wyciągnął ją do osobnej klasy i przetestował osobno. Nie musi to zmieniać publicznego interfejsu oryginalnej klasy; może wewnętrznie utworzyć instancję klasy pomocniczej i wywołać metodę pomocniczą.

Jeśli chcesz przetestować trudne warunki błędu wynikające z metody pomocniczej, możesz pójść o krok dalej. Wyodrębnij interfejs z klasy pomocnika, dodaj publiczny moduł pobierający i ustawiający do klasy oryginalnej, aby wstrzyknąć klasę pomocnika (używaną przez interfejs), a następnie wstrząśnij próbną wersję klasy pomocnika do klasy oryginalnej, aby sprawdzić, jak klasa oryginalna reaguje na wyjątki od pomocnika. Takie podejście jest również pomocne, jeśli chcesz przetestować oryginalną klasę bez testowania również klasy pomocniczej.

Testowanie metod prywatnych przerywa enkapsulację klasy, ponieważ za każdym razem, gdy zmieniasz wewnętrzną implementację, łamiesz kod klienta (w tym przypadku testy).

Więc nie testuj prywatnych metod.

Odpowiedź ze strony FAQ JUnit.org :

Ale jeśli musisz ...

Jeśli korzystasz z JDK 1.3 lub nowszego, możesz użyć refleksji, aby obalić mechanizm kontroli dostępu za pomocą PrivilegedAccessor . Aby uzyskać szczegółowe informacje na temat korzystania z niego, przeczytaj ten artykuł .

Jeśli używasz JDK 1.6 lub nowszego i adnotujesz swoje testy za pomocą @Test, możesz użyć Dp4j, aby wprowadzić odbicie w twoich metodach testowych. Aby uzyskać szczegółowe informacje na temat korzystania z niego, zobacz ten skrypt testowy .

PS Jestem głównym współpracownikiem Dp4j , zapytaj mnie, czy potrzebujesz pomocy. :)

Jeśli chcesz przetestować prywatne metody starszej aplikacji, w której nie możesz zmienić kodu, jedną z opcji dla Javy jest jMockit , który pozwoli ci tworzyć symulacje obiektu, nawet gdy są one prywatne dla klasy.

Nie testuję metod prywatnych. Istnieje szaleństwo. Osobiście uważam, że powinieneś testować tylko publicznie udostępnione interfejsy (i obejmuje to metody chronione i wewnętrzne).

Jeśli używasz JUnit, spójrz na junit-addons . Ma możliwość zignorowania modelu bezpieczeństwa Java i dostępu do prywatnych metod i atrybutów.

Sugerowałbym trochę przeredagować kod. Kiedy musisz zacząć zastanawiać się nad użyciem refleksji lub innego rodzaju rzeczy, do testowania kodu coś jest nie tak.

Wspomniałeś o różnych rodzajach problemów. Zacznijmy od prywatnych pól. W przypadku pól prywatnych dodałbym nowy konstruktor i do niego wstrzyknąłem pola. Zamiast tego:

public class ClassToTest {

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

Użyłbym tego:

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

Nie będzie to problemem nawet w przypadku niektórych starszych kodów. Stary kod będzie używał pustego konstruktora, a jeśli zapytasz mnie, zrefaktoryzowany kod będzie wyglądał na czystszy, a będziesz mógł wstrzyknąć niezbędne wartości w teście bez refleksji.

Teraz o metodach prywatnych. Z mojego osobistego doświadczenia, kiedy musisz wprowadzić prywatną metodę do testowania, ta metoda nie ma nic wspólnego z tą klasą. Typowym wzorcem w takim przypadku byłoby zawinięcie go w interfejs, na przykład, Callablea następnie przekazanie tego interfejsu również w konstruktorze (z tą sztuczką wielokrotnego konstruktora):

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

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

Przeważnie wszystko, co napisałem, wygląda na wzór wstrzyknięcia zależności. Z mojego osobistego doświadczenia jest to bardzo przydatne podczas testowania i myślę, że ten rodzaj kodu jest czystszy i łatwiejszy w utrzymaniu. To samo powiedziałbym o klasach zagnieżdżonych. Jeśli zagnieżdżona klasa zawiera ciężką logikę, lepiej byłoby przenieść ją jako prywatną klasę pakietu i wstrzyknąć do klasy, która tego potrzebuje.

Istnieje również kilka innych wzorców projektowych, których użyłem podczas refaktoryzacji i utrzymywania starszego kodu, ale wszystko zależy od przypadków testowania twojego kodu. Korzystanie z refleksji w większości nie stanowi problemu, ale jeśli masz mocno przetestowaną aplikację korporacyjną i testy są uruchamiane przed każdym wdrożeniem, wszystko staje się bardzo wolne (to po prostu denerwujące i nie lubię tego typu rzeczy).

Jest też zastrzyk setera, ale nie zalecałbym go używać. Lepiej trzymam się konstruktora i inicjuję wszystko, gdy jest to naprawdę konieczne, pozostawiając możliwość wstrzyknięcia niezbędnych zależności.

Dostęp do prywatnej metody można uzyskać tylko w ramach tej samej klasy. Nie ma więc możliwości przetestowania „prywatnej” metody klasy docelowej z żadnej klasy testowej. Wyjściem jest to, że możesz przeprowadzić testy jednostkowe ręcznie lub zmienić metodę z „prywatnej” na „chronioną”.

Następnie dostęp do chronionej metody można uzyskać tylko w tym samym pakiecie, w którym zdefiniowano klasę. Zatem testowanie chronionej metody klasy docelowej oznacza, że ​​musimy zdefiniować klasę testową w tym samym pakiecie co klasa docelowa.

Jeśli wszystkie powyższe warunki nie odpowiadają twoim wymaganiom, użyj metody odbicia, aby uzyskać dostęp do prywatnej metody.

Jak wielu sugerowało powyżej, dobrym sposobem jest przetestowanie ich za pomocą publicznych interfejsów.

Jeśli to zrobisz, dobrym pomysłem jest skorzystanie z narzędzia do pokrycia kodu (takiego jak Emma), aby sprawdzić, czy twoje prywatne metody są w rzeczywistości wykonywane na podstawie testów.

Oto moja ogólna funkcja do testowania pól prywatnych:

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

Przykład poniżej;

Należy dodać następującą instrukcję importu:

import org.powermock.reflect.Whitebox;

Teraz możesz bezpośrednio przekazać obiekt, który ma metodę prywatną, nazwę metody do wywołania i dodatkowe parametry, jak poniżej.

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

Dzisiaj wypchnąłem bibliotekę Java, aby pomóc w testowaniu prywatnych metod i pól. Został zaprojektowany z myślą o systemie Android, ale naprawdę można go używać w każdym projekcie Java.

Jeśli masz kod z prywatnymi metodami lub polami lub konstruktorami, możesz użyć BoundBox . Robi dokładnie to, czego szukasz. Poniżej znajduje się przykład testu, który uzyskuje dostęp do dwóch prywatnych pól działania Androida, aby go przetestować:

@UiThreadTest
public void testCompute() {

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

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

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

BoundBox ułatwia testowanie prywatnych / chronionych pól, metod i konstruktorów. Możesz nawet uzyskać dostęp do rzeczy ukrytych przez dziedziczenie. Rzeczywiście, BoundBox łamie enkapsulację. Zapewni ci to dostęp poprzez refleksję, ALE wszystko jest sprawdzane w czasie kompilacji.

Jest idealny do testowania starszego kodu. Używaj go ostrożnie. ;)

https://github.com/stephanenicolas/boundbox

Najpierw odpowiem na pytanie: Dlaczego twoi prywatni członkowie potrzebują izolowanych testów? Czy są one tak złożone, zapewniając tak skomplikowane zachowania, że ​​wymagają testów poza powierzchnią publiczną? To testy jednostkowe, a nie „liniowe”. Nie przejmuj się małymi rzeczami.

Jeśli są tak duże, wystarczająco duże, że każdy z tych prywatnych członków jest „jednostką” o dużej złożoności - rozważ refaktoryzację takich prywatnych członków z tej klasy.

Jeśli refaktoryzacja jest nieodpowiednia lub niewykonalna, czy możesz użyć wzorca strategii, aby zastąpić dostęp do tych prywatnych funkcji / klas członków podczas testowania jednostkowego? W teście jednostkowym strategia zapewniłaby dodatkowe sprawdzanie poprawności, ale w kompilacjach wersji byłaby to prosta transmisja.

Niedawno miałem ten problem i napisałem małe narzędzie o nazwie Picklock , które pozwala uniknąć problemów związanych z jawnym użyciem interfejsu API refleksji Java, dwa przykłady:

Metody wywoływania, np. private void method(String s)- przez odbicie Java

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

Metody private void method(String s)wywoływania , np. - przez Picklock

interface Accessible {
  void method(String s);
}

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

Ustawianie pól, np. private BigInteger amount;- przez odbicie Java

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

Ustawianie pól, np. private BigInteger amount;- przez Picklocka

interface Accessible {
  void setAmount(BigInteger amount);
}

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

PowerMockito jest do tego stworzony. Użyj zależności maven

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

To możesz zrobić

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