[Maintainability] Unit Tests

[automationdream]

Repozytorium powinno zawierać chociaż najważniejsze testy jednostkowe.

[filipfe]

Nie jesteśmy fanami testowania jednostkowego, a o to kilka powodów:

• uważamy, że testowanie na bieżąco, na etapie rozwoju projektu jest reprezentacją realnych zachowań użytkownika, dzięki czemu błędy są łatwiejsze do znalezienia i prostsze do rozwiązania, "tańsze"
• pracujemy w najmniejszym możliwym gronie, czyli 2 osób z czego obydwoje zajmujemy się innymi rzeczami, a co za tym idzie rozumiemy działanie relacji serwera z klientem lepiej i możemy objąć aplikację "szerszym wzrokiem"
• staramy się rozpoznawać i przewidywać opcjonalne zagrożenia od razu, pisać dla każdego możliwego scenariusza

Oprócz tego mamy koło ratunkowe w postaci Typescriptu co bardzo ułatwia identyfikację błędów na etapie użytku przy rozwijaniu. Nie zaprzeczamy natomiast, że takie testy w aplikacji się nie pojawią i nie będą konieczne dla szczególnych wypadków

[automationdream]

Ok, to będę miał parę pytań.. Może rozwiniemy ten temat, jeśli mogę 😃 ?

• Wydaje mi się, że punkt pierwszy, o którym piszesz pokrywają testy end-to-end no i rzeczywiście mogą być wykonywane manualnie tak jak piszesz ale nie pokrywają one większej ilości scenariuszy testów takich jak Unit-Testy i Integration testy.
• Czy zastanawiałeś się może jak nowe osoby będą w stanie szybko wyłapać błędy na etapie kodowania bez udziału autorów, na przykład zmienią jakąś funkcjonalność i okaże się, że zepsują funkcjonalność aplikacji?
• Co na wstępnym etapie będzie blokowało mergowanie błędnego kodu na mastera? Czy jedynym punktem oporu będzie dokładna analiza kodu przez programistę? Szczerze mówiąc nie spotkałem się, żeby to działało ;p
• Właśnie punkt trzeci, który napisałeś obejmują testy jednostkowe, skoro możesz przewidzieć zdarzenie, możesz też dopisać test jednostkowy
• W jaki sposób planowaliście piramidę testów automatycznych w projekcie skoro nie ma tam testów jednostkowych?

Bardzo dobrze, że używacie Typescriptu 👍 ale on pokrywa raczej warstwę front :(

Zgadzam się, że wszystko nie musi być testowane. Najlepiej jak są to najważniejsze funkcjonalności. Skoro nie wykluczacie ich na kolejnych etapach, czy powinniśmy pozostawić ten issue? Jaki nadałbyś temu priorytet?

[automationdream]

Tu podsyłam króciutki artykuł o piramidzie testów, czym w skrócie jest i czy istnieje jako standard w branży:

https://automationpanda.com/2018/08/01/the-testing-pyramid/

[filipfe]

Do tej pory, na przestrzeni czasu programowania strony nie stwierdziliśmy, aby któreś z poszczególnych komponentów lub ich współdziałającej grupy wymagały takiego testowania. Chcielibyśmy poznać natomiast praktyczną opinię tzn. w których konkretnie miejscach w naszej aplikacji takie testy mogłyby się pojawić? Chodzi o to, że znamy scenariusze dla większości komponentów i ja sam staram się izolować funkcjonalność do jak najmniejszych elementów przez co takie błędy mają bardzo małą szansę na wystąpienie lub są wręcz niemożliwe. Tutaj z Typescriptem oczywiście w pełni front, chodziło bardziej o to, że jeżeli jakiś błąd już wystąpi to mamy jasny obraz po stronie frontu przez co. Myślę, że issue można wykluczyć lub przesunąć na mniejszy priorytet i późniejszy etap, aby ewentualnie na końcu przetestować te elementy, u których występuje największe ryzyko.