Testowanie części prywatnej

0

Co będzie najlepszym rozwiązaniem dla testowania części prywatnej ?

Do testów używam frameworku GTest.

  1. Części prywatnej NIE testujemy.
  2. Zamiana części private którą chcemy przetestować na protected.
  3. Dodanie #define private public
  4. Dodanie do klasy statycznej metody jeżeli define UNIT_TEST i wywoływanie metody ...

Jakiś lepszy pomysł ?

Pozdrawiam :)

0

friend do klasy testującej?

4
  • Metody prywatne powinny być na tyle proste że nie trzeba ich samodzielnie testować tylko testuje się je poprzez wywołania publicznego api
  • Jeśli jakieś prywatne metody są zbyt skomplikowane i fajnie byłoby je przetestować samodzielnie to jest sygnał że może warto wydzielić tą logikę do osobnej klasy i zrobić public w tejże klasie.

Więc jak dla mnie tylko opcja 6) Wydzielić skomplikowane zachowania do osobnych klas, a proste testować przez wywołania publicznego API
Zmiany w kodzie "pod testy" są generalnie dość słabą sprawą.

0

Tak i 5. Dodanie przyjaźni...

Które z tych rowiązań będzi najbardziej 'eleganckie' ?

Prawda :)
Dzięki.

Jeszcze jedno pytanie... metody statyczne.

Jest lepszy pomysł od dodania nowej klasy z metodą virtualną która wywołuje metodę statyczną ... którą mockujemy (templaty odpadają) ?

4

Ja staram się stosować taką zasadę że static jeśli już jest to robi coś prostego i oczywistego, do tego stopnia że nie warto mockować. Na przykład jakieś StringUtils do cięcia ścieżek, usuwania spacji itd Wszystko inne, szczególnie logika biznesowa, raczej leci przez kontener IoC.

0

Dzięki Shalom, niestety to kod używanego projektu ... projekt jest na etapie "nie dotykaj bo działa" brakuje tylko wymagań odnośnie unit testów (nie komentuj :) )

Za to mam jeszcze dwa pytanie :)

Powiedzmy ze w jakiejś funkcji która testuje mam takie fragment:

Message *msg = new Message(MessageType::Private, data);

if( msg ){
....
} else {
// allocation failed
}

W jaki sposób mogę przetestować fragment ... zamockować konstrukotra oczywiście nie mogę... wywoła się i zwróci adres zaalokowanej pamięci. Zmieniać tego kodu nie chce ani dodawać try catchów, może stub z licznikiem zwracający NULL lub "jakiś" adres ?

Pytanie numer dwa.

Powiedzmy ze mam klasę która nie ma w sobie żadnej metody wirtualnej, jeżeli chce ją przetestować to większy sens ma dodawanie virtual do metod i mockowanie używanych ... czy po prostu stworzenie instancji testowanej klasy wywołaniu metod i tak dobieranie parametrów żeby sensownie przetestować metody - sprawdzając wyniki za pomocą excpect calli ?

Pozdrawiam,

0
  1. Jeśli nie ma żadnego frameworka który potrafi mockować wywołania new (dla javy istnieje na przykład powermock który takie cuda potrafi, potrafi też mockować statici swoja drogą) to może zamienić takie gołe wywołania new na jakieś Factory? Plus taki że łatwiej potem będzie zmienić to na jakieś smart-pointery bo alokacje będą w jednym miejscu.
  2. To jest dość trudne pytanie, bo znów pojawia sie kwestia zmiany kod "pod testy". Miej na uwadze że dodanie virtual wprowadza dość wyraźną różnicę w działaniu obiektów danej klasy, nawet jeśli na pierwszy rzut oka tego nie widać. Dochodzi tutaj narzut związany z wywoływaniem metod wirtualnych plus w klasie pojawia się też "niewidzialne" pole z virtual method table, więc gdyby ktoś przypadkiem bawił się w jakieś rzutowanie bloków pamięci na obiekty to może sie to teraz źle skończyć.
    Wydaje mi się że musisz tutaj decydować dla konkretnych sytuacji -> jeśli da się prosto ustalić parametry tak żeby zrobić test to nie ma sensu kombinować, ale jeśli to jest jakaś skomplikowana metoda (ot choćby klasyczne łączenie z bazą danych) to wtedy może warto coś poczarować.

1 użytkowników online, w tym zalogowanych: 0, gości: 1