Czy można uniknąć testowania klas podstawowych?

Mam klasę podstawową z dużą ilością „metaprogramowania”, aby zapewnić jej elastyczność / abstrakcję, która musi być raczej ogólna.

Mam wiele podklas, które używają wspólnych metod w klasie podstawowej, i mam zorientowane na zachowanie testy jednostkowe obejmujące wszystkie przypadki w każdej podklasie.

Czy można pominąć testowanie klasy podstawowej?

unit-testing testing

— Nathan
źródło

Jedną rzeczą, którą czasami robię, kiedy zaczynam zadawać sobie to pytanie, jest próba złamania kodu. Rzucaj na nią niepoprawne dane wejściowe, określ nieprawidłowe wartości konfiguracyjne itp.

— Zymus

Odpowiedzi:

Aby sprawdzić, czy masz wystarczającą liczbę testów, możesz sprawdzić zasięg kodu i zasięg gałęzi wywołany przez testy (może za pomocą narzędzia pokrycia, może ręcznie poprzez przejrzenie ścieżek kodu lub za pomocą debugera).

Jeśli dojdziesz do wniosku, testy dla podklas zapewniają wystarczająco wysoki zasięg dla kodu klas podstawowych, to dodanie kolejnych testów oczywiście nie przyniesie ci wiele korzyści. Z drugiej strony, jeśli istnieją ścieżki kodu, które można testować tylko poprzez dodanie konkretnych testów przy użyciu klasy podstawowej bezpośrednio, należy wybrać tę trasę.

Innym możliwym powodem „bezpośredniego testowania klasy podstawowej” jest to, że chcesz przetestować określoną funkcję tej klasy „w izolacji”. Czasami może być łatwiej zaprojektować przypadki testowe bezpośrednio dla konkretnej metody, zamiast tylko testować tę metodę pośrednio, wywołując metody z twoich podklas, które używają tej metody.

Zauważ, że jeśli masz ogólną klasę podstawową, dla której typowym scenariuszem użycia jest wyprowadzenie podklasy, twoja klasa podstawowa jest prawdopodobnie abstrakcyjna. Tak więc, aby przetestować taką klasę, musisz zrobić pochodną. W tej sytuacji testowanie „klasy podstawowej bezpośrednio” może oczywiście oznaczać dodanie specjalnej pochodnej wyłącznie do celów testowych.

— Doktor Brown
źródło

Tak, zgadzam się z bezpośrednimi testami jednostkowymi w klasie bazowej dla bardziej konkretnie zdefiniowanych metod. To, czego nie chciałem robić, to przetestować wszystkie metaprogramowanie, ponieważ testy jednostkowe w podklasach pośrednio testują te rzeczy.

— Nathan

Zaprojektowanie klasy rozszerzającej klasę podstawową / abstrakcyjną, która istnieje tylko w katalogu testowym i służy jedynie do ujawnienia / utworzenia instancji klasy podstawowej, jest całkowicie uzasadnionym i rozsądnym podejściem do uzyskania odpowiedniego pokrycia klasy podstawowej i zapewnienia, że metody bazowe są działa poprawnie w oderwaniu od bardziej złożonych klas, które są używane.

@MichaelT: tak. Czy moja odpowiedź brzmi, jakbym miał inne zdanie na ten temat?

— Doc Brown

@DocBrown wcale nie - wyraźnie wyraziłeś ten punkt. Właśnie dodałem dodatkowe wyjaśnienie, które napisałbym we własnej odpowiedzi (jeśli jeszcze tego nie powiedziałeś). Nie chcę pisać odpowiedzi, która by się zaczęła „Zgadzam się ze wszystkim, co powiedział Doktor, ale chcę specjalnie zadzwonić i napisać więcej o ...”

Zautomatyzowane testy zostały stworzone dla programistów, programiści nie zostali stworzeni do obsługi testów.

Przeprowadzamy testy, aby zwiększyć produktywność i zmniejszyć liczbę „problemów”, na które narzekają klienci.

Biorąc pod uwagę, że masz testy jednostkowe zorientowane na zachowanie obejmujące wszystkie przypadki w każdej podklasie, nie ma dla ciebie korzyści, że klient również testuje bezpośrednio klasę podstawową. Można to potwierdzić , zmieniając jakiś kod w klasie bazowej i sprawdzając, czy test się nie powiedzie, np. Wydzielając wiersz kodu lub dodając „nie” do „instrukcji if”. (Samo sprawdzenie, czy każda linia kodu jest objęta testami, nie jest wystarczająco dobre).

Pozostaje nam pytanie, czy test zwiększy produktywność . Może się to zdarzyć na kilka sposobów.

Pozwalając ci jaśniej myśleć o kodzie - ponieważ kod jest napisany, w tym przypadku jest mało prawdopodobne.
Pozwalając przetestować jakiś kod w klasie podstawowej w oderwaniu, więc debuguj go szybciej, ponownie mało prawdopodobne w przypadku, gdy kod już działa.
Pozwalając ci zmienić kod w klasie bazowej bez konieczności rozumienia szczegółów logiki w podklasach - może jeśli refaktoryzujesz kod ???

Biorąc pod uwagę, że podklasy działają, nie widzę sensu w pisaniu bezpośrednich testów dla klasy podstawowej. Nie jest tak, że pisanie tych testów na wczesnym etapie nie przyniosłoby korzyści.

— Ian
źródło