Redakcja
Koncept piramidy testów, stworzonej i rozpropagowanej przez Martina Fowlera, jest bardzo znany. Pokazuje on nie tylko jakie poziomy testów powinny być uruchamiane, ale również to, które testy są szybkie, a które wolne oraz które są tanie, a które drogie.
Do koncepcji tej usiadł dość znany i mocno kontrowersyjny Kent C. Dodds i przerobił ją na tzw. "Testing Trophy".
Panowie może nie do końca zgadzają się co do liczby i zakresu testów (symbolizowanych przez rozmiar obszaru), ale ich koncept jest w spójny jeśli chodzi o wagę testowania w wytwarzaniu oprogramowania. To, co wyróżnia propozycję Pana Doddsa, to dorzucenie do całości testów statycznych oraz modyfikacje zakresów testów.
Jakie poziomy testów proponuje autor i co się za nimi kryje?
- Test statyczne (wyróżnione przez Kenta) są po to, by wyłapywać literówki i błędy w kodzie.
- Testy jednostkowe świetnie nadają się do testowania funkcji z ich wejściami i wyjściami. Przydatne w obiektach, procedurach lub modułach.
- Testy integracyjne (na sposób Kenta) to testowanie, które sprawdza jak wszystkie małe komponenty i UI działają razem. Weryfikowane jest raczej zachowanie niż informacje wyjściowe. Świetnie nadaje się do testowania izolowanych elementów, ale nie nadaje się do głównych przepływów.
- E2E przetestuje przepływy użytkownika w stosunku do wszystkich istotnych zależności w środowisku jak najbardziej zbliżonym do produkcyjnego, jeśli nie wręcz na produkcyjnym.
Co myślicie o takiej propozycji?
