[suckmyduck]

#testowanieoprogramowania
Mam do was pytanie o nazewnictwo poziomów testów. To obszar z którym zawsze mam problem żeby dogadać się z innymi qa/dev. Piramida testów zakłada poziomy unit, integration, e2e. Czy jest jakiś dokładniejszy podział który mógłbym uznać za złoty środek w komunikacji międzyludzkiej?

Jakie mam problemy:
- component testing - przyjmowałem że to ten sam poziom co unit. Wyczytałem że odpowiedzialność za nie często spada na qa, a nie dev jak unity i to osobny poziom.
- integracyjne - często mowa jest o nich jak o samym API (jeszcze różnie w zależności czy to wewnętrzne czy zewnętrze). Spotkałem się też z tym że to integracja kilku komponentów/modułów niekoniecznie po API.
- E2E - dla mnie to testy całej aplikacji na jakimś środowisku, ale często spotkałem się z określeniem E2E jako testy całej ścieżki po API.
- różne nazewnictwo jeżeli kiedy testy opierają się na mockach, a kiedy na prawdziwych danych

[Fristo]

@suckmyduck: nie znajdziesz żadnego złotego środka, wszystko jest umowne
ciekawostka: wg. istqb component test i unit test to synonimy

[pasta_alla_carbonara]

@suckmyduck: Integracyjne to często API, ale można pomyśleć też o konktraktowych testach FE <=> API, e2e to raczej testy całej apki bez mockowania (no bo jak coś mockujesz, to ciężko to nazwać e2e).

Zasadniczo musicie mieć spójne nazewnictwo w całej organizacji/projekcie i jedno źródło prawdy, a fakt jest taki, że czasami granica się zaciera, dużo też zależy od produktu ( jak testujesz hardware to już w ogole ;) )

u nas

[piolem]

@suckmyduck ja od dołu bym zaproponował jak chodzi o dość generyczne podejście: unit testy/component/integration/system/aceptance

[orkenzord]

@suckmyduck co do e2e (end-to-end), to pojęcia są bardzo mylone:
- testowanie konkretnej ścieżki (np. po API) od początku do końca według jakiegoś ustalonego flow
- testowanie scenariusza jako końcowy odbiorca, czyli użytkownik, wykorzystując już stworzoną aplikację (w skrócie mówiąc klikanie po UI) w przeglądarce

[diarrhoea]

@suckmyduck
Unit testy w branży to testy pisane przez developerów, testujący konkretne metody. Testy takie powinny istnieć niezależnie od tego jak wyglądają testy robione przez QA.

Testy modułowe/testy komponentu - najczesciej rozumie się jako testy jednego "elementu" aplikacji, np. Testy modułu do dodawania kontraktów. Czasem jednak moduły są rozumiane szerzej, np. Moduł do dodawania umów i zarzadzania nimi jako jedną rzecz. Im większa jest Apka, tym częściej jako moduł rozumie się

[Nihomme]

@suckmyduck: https://martinfowler.com/articles/practical-test-pyramid.html polecam się zapoznać bo trochę rozjaśnia