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ć.