Piramida testów

Rozmawiając z kilkoma osobami na temat podziału ilości testów względem ich przeznaczenia okazało się, że pojęcie piramidy testów nie jest aż tak popularne jak mi się wydawało. Ponad pół roku temu Agnieszka w bardzo fajny sposób opisała rodzaje testów, dlatego też ten wpis jest tylko uzupełnieniem jej postu. Także w pierwszej kolejności zapraszam do przeczytania jej artykułu i zapraszam z powrotem! 

Piramida testów to nic innego jak przedstawienie w sposób graficzny hierarchii ilości wykonywanych testów:

Testy jednostkowe

Na samym dole znajdują się testy jednostkowe (około 70% wszystkich testów). Testy te powinny testować pojedynczą “jednostkę” kodu. Są “najtańsze“. Oznacza to, że wykonywanie ich jest bardzo szybkie, ponieważ nie testują one komponentów graficznych oraz integracji z innymi systemami, co związane jest z przygotowaniem odpowiednich środowisk. Ponadto, testy te uruchamiane są w izolacji, oznacza to, że nie jesteśmy w żaden sposób związani z innymi elementami systemu. Aby osiągnąć izolację wykorzystujemy  Test Doubles.

Testy integracyjne

Środkową pozycję zajmują testy integracyjne (około 20% wszystkich testów). Testują one “integrację” z innymi komponentami/serwisami/usługami zewnętrznymi. Nie są to już testy uruchamiane w kompletnej izolacji jak w testach jednostkowych, tym razem interesuje nas integracja z innymi komponentami, na przykład z naszą bazą danych.

Testy akceptacyjne – end to end – funkcjonalne

Testy te są różnie nazywane, jednakże są to testy akceptacyjne (około 10% wszystkich testów), które znajdują się na samej górze hierarchii naszej piramidy. Testują one całą funkcjonalność od początku do końca (end to end), symulują zachowanie użytkowników i najczęściej testują też UI przy wykorzystaniu na przykład Selenium.

Bardzo obrazowa koncepcja piramidy testów pomaga nam określić ich priorytety.

  • Warren

    Pytanko – jak się do tego mają testy komponentowe? Zaliczają się one do integracyjnych, czy w ogóle znajdują się poza piramidą testów?

    • CodeCouple.pl

      Cześć,
      Tak naprawdę testy komponentowe mogą być wykonywane na każdym poziomie. To co robimy, lub czym jest komponent zależy od naszej dokumentacji. Przykładowo, jeśli w dokumentacji jako komponent określone są trzy klasy wykonujące daną logikę to spokojnie testy jednostkowe wystarczą. Jeśli natomiast przez komponent określona jest większa część, na przykład formularz logowania to tutaj testy end to end są jak najbardziej wskazane.