Wzorce projektowe i testowanie

Cześć! Kilka pytanek z zakresu testowania :)
Jakie testy piszesz w swoim projekcie?
Kiedy decydujesz się na to czy i jaki test pisać?
Jaki jest twój ulubiony design pattern którego używasz w testach?

podaj najpierw swoje

Back end biznesowy:

1. Testuję funkcjonalności, a nie kod.
2. Piszę testy jednostkowe, gdzie jednostka to nie metoda lub klasa, a jakiś publiczny interfejs odpowiadający za cały use-case.
3. Zwykle używam architektury portów i adapterów i dzięki niej uruchamiam testy jednostkowe w trybie szybkim (mocki) i integracyjnym/dokładniejszym (test containers).
4. Czasem tryb integracyjny jest również szybki i nie bawię się w żadne mocki.
5. Jeżeli mock można zastąpić prostą implementacją np. z użyciem kolekcji to nie bawię się w mocki.
6. Dużo mother object i DSL, żeby nie kopiować i wklejać setupu testu.
7. Dodatkowo kilka testów E2E na środowisku testowym lub preprodowym
8. Parametryczne testy zawsze i wszędzie gdzie to możliwe
9. Do testowania logiki zależnej od czasu wykorzystuję MutableClock z Threeten Extra
10. Dużo metryk
11. Technologie Kotlin + JUnit 5 + AssertJ + mockk + Test containers

Frontend biznesowy:

1. Testuję funkcjonalności, a nie kod
2. Piszę testy jednostkowe, gdzie jednostka to nie funkcja lub komponent, ale funkcjonalność
3. Renderuję całą stronę i klikam po niej za pomocą react-testing-library, ze skonfigurowanym serwerem API in memory
4. Dużo mother object i DSL, żeby nie kopiować i wklejać setupu API
5. Dla skomplikowanych i krytycznych komponentów czasem piszę dedykowane testy z użyciem testing library
6. Przy wybieraniu elementów używam HTML roles zamiast jakichś sztucznych id lub klas
7. Kilka testów E2E w cypres na środowisku testowym lub preprodowym
8. Technologie: Jest, Testing Library, Cypress, MSW

Jan943 napisał(a):

Cześć! Kilka pytanek z zakresu testowania :)
Jakie testy piszesz w swoim projekcie?
Kiedy decydujesz się na to czy i jaki test pisać?

Piszę testy tylko pod ten kawałek kodu który ma działać.

Jan943 napisał(a):

Jaki jest twój ulubiony design pattern którego używasz w testach?

Patterny:

• Dużo małych szybkich testów. Lepiej mieć 300 malutkich testów które się wykonują pół sekundy, niż 10 dużych, testujących to samo.
• Testy niezależne od siebie w najmniejszym stopniu,
• Rozwój testów w jedną stronę, rozwój kodu w inną stronę.
• Testy pozwalające całkowicie zredesignować system, jeśli tylko zachowanie zostanie takie samo.
• Nie testowanie dwóch rzeczy w jednym teście - to wymaga małej duplikacji (dwóch mniejszych testów zamiast jednego większego, ale to się opłaca).

Antypatterny:

• Klasa Sender oraz test SenderTest, czyli robienie klas 1:1 do testów. W żadnym stopniu to nie jest akceptowalne, nigdzie. Jeśli ktoś tak robi to niewiele wie o testowaniu.
• Testy wiedzące o implementacji klasy (nie respektujące enkapsulacji), albo wręcz napisane w taki sposób że nie mogą jej respektować.
• Testy które utrudniają refaktor (właściwie suma dwóch poprzednich)
• Testy które trwają długo, dłużej niż 30 sekund powiedziałbym to już jest hardcore.
• Test suite do którego dodanie nowego testu trwa dłużej niż 1-2 sekundy.
• Mylenie nazwy "unit test". Wielu ludzi całkowicie niepoprawnie uważa że test jednostkowy to test pojedynczej klasy. To nie prawda, bo test pojedynczej klasy nigdy nie ma sensu (chyba że w przypadku w którym jest tylko jedna klasa w projekcie, to jest jedyny przypadek kiedy test jest 1:1 klasy).