Istnieją dwie szkoły testowanie. Pierwsza zakłada, że testować należy tyko kod publiczny. Druga, że należy testować cały kod.

Pierwsza mówi, że tylko dobrze działający kod publiczny jest w zakresie zainteresowania klienta. Zgoda. Jako klient nie interesuje mnie jak dokładnie coś działa. Rzadko wnikam w kod używanych bibliotek. Jeżeli już to robię to zazwyczaj interesuje mnie rozwiązanie konkretnego problemu lub implementacja konkretnej funkcjonalności.
Założenie jest słuszne do momentu, w którym testowana funkcjonalność jest na tyle skomplikowana, że potencjalnie zawalony test nie daje jednoznacznej odpowiedzi co jest źle. W tym momencie odzywa się zazwyczaj druga szkoła.
Mówi ona, że po zakończeniu testów można ingerować w kod zmieniając modyfikatory dostępu. Jest to jednak kłopotliwe ponieważ nie ma możliwości wykonania tego automatycznie. W praktyce jedynym rozwiązanie jest ręczne przepisywanie kodu. Wiąże się to z ryzykiem popełnienia błędu.

Istnieje też rozwiązanie pośrednie. Zakłada ono przygotowanie dwóch zestawów testów. Pierwszy uruchamiany jest w trybie „all public” i kompleksowo testuje kod. Następnie zmieniane są modyfikatory i uruchamiany jest zestaw testujący tylko publiczne fragmenty kodu.

W Javie mamy mechanizm refleksji, który umożliwia manipulowanie obiektami na poziomie maszyny wirtualnej. Można ten mechanizm zastosować do testowania kodu, ale zazwyczaj pojawia się pytanie czy tak przygotowane testy nie zawierają błędów. Czy prawidłowo uruchamiają poszczególne metody i czy całość „bangla”.

Wychodząc na przeciw tym problemom przygotowałem małe narzędzie, które pozwala na uruchamianie prywatnych metod oraz ustawianie i pobieranie wartości prywatnych pól w obiektach w trakcie testów.
Zapraszam wszystkich do zapoznania się z Private Member Testing.

Narzędzie jest bardzo proste. Pozwala na wywołanie metody lub stworzenie obiektu poprzez ręczne ustawienie wartości poszczególnych pól. Nie ma tu funkcjonalności JMock, ale nie taki jest cel.
Czekam na wasze opinie i propozycje pod tym adresem.