Private Member Testing

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.

2 myśli na temat “Private Member Testing

  1. Koziolku,
    mozna jeszcze pokusic sie o uzycie AspectJ.
    Osobiscie nie ograniczam sie do testowania samych publicznych, bo w prywatnej czesci moze lezec wazna logika. Poza tym, z samym public, jak kiepsko wyglada pokrycie kodu…

  2. Próbowałem już zabaw z AspektJ, ale nie koniecznie działają tak jak chcę. pmt stosuje tu brute force wykorzystując API javy bez zewnętrznych bibliotek. Jednak podsunąłeć mi pewien pomysł.

Napisz odpowiedź

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

To create code blocks or other preformatted text, indent by four spaces:

    This will be displayed in a monospaced font. The first four 
    spaces will be stripped off, but all other whitespace
    will be preserved.
    
    Markdown is turned off in code blocks:
     [This is not a link](http://example.com)

To create not a block, but an inline code span, use backticks:

Here is some inline `code`.

For more help see http://daringfireball.net/projects/markdown/syntax