Jak się nauczyć testować?

1

Odczuwam irracjonalną niechęć do zmiany i dodawania nowych rzeczy do działającego kodu. Stwierdziłem, że pomóc mi może pisanie testów jednostkowych.
Szukając czegoś na ten temat w internecie znalazłem sporo artykułów lejących wodę, tłumaczących wszystkie drobiazgi w jUnit, ale nigdzie nie znalazłem faktycznie dobrych przykładów i porad. Same przykłady z testowaniem getterów i innych bzdur.

Jak się nauczyć pisać testy? Czy mam testować każdą metodę/klasę, a po jakimś czasie samemu stwierdzić co warto, a czego nie warto testować?

2

Od tego możesz zacząć https://helion.pl/ksiazki/tdd-sztuka-tworzenia-dobrego-kodu-kent-beck,tddszt.htm#format/d.

Później jak się okaże, ze Twój kod to straszne gowno i nie da się testować przeczytaj to: https://helion.pl/ksiazki/praca-z-zastanym-kodem-najlepsze-techniki-michael-feathers,prazav.htm#format/d

Jak juz coś tam zaczniesz testować to możesz czytać dalej w dowolnej kolejności:
https://www.amazon.com/Art-Unit-Testing-examples/dp/1617290890 oraz źródła wypisane tutaj https://stackoverflow.com/a/924639 (pierwsz odpowiedz)

0

Ta książka jest niezła (lub polskie wydanie):
https://www.packtpub.com/application-development/test-driven-java-development
Jest sporo przykładów nie tak całkiem trywialnych, a poza tym jest też o mockingu i BDD.

1

Też polecam "TDD. Sztuka tworzenia dobrego kodu" Kent Beck.

Jak się nauczyć pisać testy?

Trzeba pisać dużo testów, zacznij od dzisiaj - od teraz.

Czy mam testować każdą metodę/klasę, a po jakimś czasie samemu stwierdzić co warto, a czego nie warto testować?

To zależy o jakich testach mówisz. Jeżeli masz na myśli jednostkowe to tak - trzeba testować każdą klasę i jej metody publiczne.

1

Również polecam TDD Kenta Becka - klasyka gatunku ;) Oprócz tego także ksiązke polskiego autora Tomka Kaczanowskiego - Practical Unit Testing with JUnit and Mockito. Jak dla mnie świetna pozycja dla początkujących

0

Dzięki za odpowiedzi. Zakręcę się przy pozycji pana Becka i po prostu postaram się pisać jak najwięcej testów.

1

Jak się nauczyć testowania, a nie testować. Dopełniacz, a nie biernik. Proszę, nie kaleczmy naszego języka.

Co do meritum: testy jednostkowe zazwyczaj nie wystarczają, dopiero testy funkcjonalne potrafią wykryć różne nieprawidłowe zależności i działania.

Polecam także naukę wzorca projektowego TDD, czyli Test Driven Design.

10
TomRZ napisał(a):

Jak się nauczyć testowania, a nie testować. Dopełniacz, a nie biernik. Proszę, nie kaleczmy naszego języka.

To nie jest biernik tylko bezokolicznik. To nawet nie jest rzeczownik tylko czasownik.

W tytule nie ma błędu, autor chce się nauczyć testować, tak samo jak mógłby chcieć nauczyć się biegać, jeść czy śpiewać. Mógłby też chcieć nauczyć się testowania, biegania, jedzenia i śpiewania. Bez różnicy.

W pełni popieram ideę niekaleczenia języka, ale żeby to wytykać trzeba mieć po pierwsze rację, po drugie rozróżniać podstawowe części mowy, no bo jednak pomylić rzeczownik z czasownikiem to trochę przypał. Wszakże to wiedza z pierwszych klas szkoły podstawowej.

3

Parę istotnych faktów na temat testowania:

  • 100% pokrycia kodu nie znaczy, że apka działa idealnie
  • 100% pokrycia kodu w dużych projektach to niebotyczne osiągnięcie
  • QA jest ZAWSZE potrzebny - możesz przeklikać apkę, ale pozostali developerzy tego nie zrobią, nie nastawiaj się. Poza tym QA znajdzie coś, na co byś nie wpadł.
  • Testy jednostkowe nie są wystarczające - w grę wchodzą API testy, load testy etc.
  • Testy jednostkowe powinny pokrywać każdą klasę i każdą metodę / funkcję, najlepiej kilkoma różnymi testami, które sprawdzają kilka scenariuszy testowych
  • Nie powinieneś mockować klasy czy metody, a jedynie zewnętrzne zależności
  • CI, które nie puszcza zmian dalej, jeśli build nie przeszedł testów to bardzo dobry pomysł, ale nie jest to gwarancja, że apka się nie wysypie (patrz punkt pierwszy)
  • Testy jednostkowe stanowią istotny wyznacznik tego czy nie zrąbałeś podczas efaktorowania kodu

Przykład: masz metodę, która dodaje liczby.

Co możesz przetestować?
Zaczynasz od scenariuszy wykluczających np. w Javie masz statyczne typowanie, więc nic innego Ci się nie skompiluje i super, ale np. w Pythonie, Rubim czy Elixirze musisz zrobić unit testy, że np. stringi się nie dodadzą itp.

Potem przechodzisz do testów, które powinny Ci dać dobry wynik: duże liczby, małe liczby, liczby zmiennoprzecinkowe, liczby ujemne itp.

Zasada jest taka, że dobre testy jednostkowe zajmują sporo więcej miejsca, niż kod który testują. Jeżeli testujesz funkcję / metodę, która obsługuje logikę biznesową, to testujesz TYLKO ten fragment kodu. Reszta powinna być zamockowana, jeśli jest zależna od czegoś, albo z założeniem, że działa w 100% idealnie, aby móc jednoznacznie i deterministycznie stwierdzić czemu test nie przechodzi tj. czemu coś nie działa. Jeżeli Twój kod robi ify i elsy to powinieneś sprawdzić KAŻDY możliwy przypadek, dlatego dobre testy skłaniają do pisania dobrego kodu - zamiast mieć metodę z 4 ifami i 4 elsami, która sprawia, że masz 16 możliwości, piszesz metody, które mają jednego ifa albo nie mają go wcale- wtedy nie musisz tylu różnych scenariuszy testować.

Z własnego doświadczenia wiem, że jeżeli w życiu kodu nie widziałem to zaczynam od napisania do niego testów - poznaję jak toto powinno działać, widzę kiedy działa i potem dopiero mogę bezpiecznie w tym grzebać. Inaczej bałbym się takiego kodu dotykać.

2

Uczyłem się testowania z książek Tomka Kaczanowskiego.

Polecam książki:
Practical Unit Testing (wersja JUnit lub TestNG)
Bad Tests Good Tests

Jak programujesz w .NET to też będą ok, bo w sumie to jest prawie to samo co Java. Pomogła mi też prezentacja Jakub Nabrdalik - Test Driven Traps:

Nie ze wszystkim się zgadzam, ale spoko źródło wiedzy.

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