Trofeum testerskie

Trofeum testerskie
Kiedy ktoś wchodzi w dialog, a nawet przerabia kultową i szeroko znaną koncepcję piramidy testów, to warto się temu przyjrzeć. Szczególnie że w testerskich kręgach odbiło się to dość dużym echem.

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. 

trofeum-testerskie-1.jpg

Do koncepcji tej usiadł dość znany i mocno kontrowersyjny Kent C. Dodds i przerobił ją na tzw. "Testing Trophy".

trofeum-testerskie-2.jpg

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?

Źródła:
https://kentcdodds.com/blog/the-testing-trophy-and-testing-classifications
https://martinfowler.com/articles/2021-test-shapes.html
https://engineering.prezi.com/testing-testing-1-2-3-is-this-thing-on-deff196939eb