Czy testujecie aplikację manualnie jako dodatek do testów automatycznych?

W nowej pracy startuje relatywnie nowy projekt, zapytałem więc jak podchodzimy do odpalenia aplikacji lokalnie, czy przygotujemy jakiegoś docker-compose, czy przynajmniej jakieś readme? Wiem, że w greenfieldzie to nie jest aż taki problem jak w legacy, ale zdarzyło mi się spędzić dosłownie 2 dni żeby uruchomić jakiegoś klocka napisanego przez niemieckich architektów, który do działania potrzebuje 100 zewnętrznych zależności, które nie są nigdzie opisane. W każdym razie, odpowiedź mojego nowego teamu mnie zaskoczyła, zapytali "ale po co uruchamiać aplikacje lokalnie?". Odpowiedziałem, że chociażby po to by po skończonym developmencie przetestować manualnie to co się zrobiło, czy też zobaczyć czy spring w ogóle wstaje z takim a nie innym configiem. Odpowiedź na to brzmiała "my mamy dobre testy, nie musimy aplikacji już odpalać". Chwilę jeszcze przedyskutowaliśmy temat, ale generalnie moje argumenty nie miały dla nikogo sensu.

Efekt? Aplikacje są wdrażane na deva i nie działają, bo testy mimo wszystko nie są idealne, wiele przypadków jest jednak pominiętych i to wychodzi dopiero gdy ktoś przejdzie po takim API od A do Z. Często są różnice między propertiesami w testach a na środowisku przez co aplikacja działa po prostu inaczej (flyway.enabled: true/false). Mało tego, wychodzą nawet takie błędy jak zła konfiguracja beanów, przez co spring w ogóle nie wstaje. Tutaj według mnie prawdziwy hit - komuś nie wstawał spring, zamiast zainstalować lokalnie / uruchomić obraz o ile pamiętam, elasticsearcha i wtedy po prostu kliknąć shift + F10, to ta osoba wolała commitować 1 linijkowe zmiany i odpalać je w CI/CD. W efekcie potrzeba było 5 czy 6 takich commitów.

Pytanie wiec, jak to u Was wyglada? Tez uważacie że testy automatyczne są wystarczające? Czy jednak przed commitem uruchamiacie lokalnie efekty swojej pracy?

Testy automatyczne nie są wystarczające. To, że testy przechodzą, oznacza tylko i wyłącznie, tyle że testy przechodzą, a nie że nie ma błędów. Dobre testy dużo ułatwiają i pomagają, ale nie powinny być ostatecznym wyznacznikiem. W pewnych typach aplikacji dobrze napisane testy automatyczne (jednostkowe, integracyjne itp) mogą zrobić jakieś 90% roboty, w innych tylko 30 -50% za programistę.
A co do tego commitowania po jednej linijce to też kiedyś coś takie spotkałem i moim zdaniem to patologia albo głupota.

Jak firma nie ma takiego standardu, że lokal, dev, prod to dla mnie to jeden z sygnałów, że to patologia i należy szukać innej pracy.

Testy automatyczne to zautomatyzowane testy manualne. Wiadomo, że nie aplikacja nie zawsze może być postawiona do testów w taki sposób jak na produkcji. Jeśli robię zmianę w tych kilku linijkach, które się różnią (warto je minimalizować) to testuję manualnie, w innych przypadkach nie ma po co

Zawsze.

@AngryProgrammer: W, CI/CD nie macie tych samych testów co lokalnie?

lion137 napisał(a):

@AngryProgrammer: W, CI/CD nie macie tych samych testów co lokalnie?

Mamy, ale to niczego nie rozwiązuje. Jak wspomniałem, różnice mogą być między application.properties a application-integration.properties, wtedy wszystko działa w testach, ale prawdziwa aplikacja już nie wstaje. Albo testy po prostu nie są wystarczające, bądź są napisane w ten sposób by przeszły więc wydaje się że jest ok. Jednak według mnie brakuje po prostu odpalenia tego co się napisało lokalnie i przetestowania danej funkcjonalności ręcznie, choćby strzelając do API z Postmana.

Jak pracuję z jakąś usługą, to nie wyobrażam sobie, żeby wrzucić kod do repo bez przynajmniej sprawdzenia czy się zbuduje i uruchomi.

Testy automatyczne nie załatwiają wszystkiego ze swojej natury. Sprawdzają jedynie z góry określone ścieżki działania aplikacji. Dlatego trzeba czasami poklikać ręcznie (inaczej) i poszukać błędów.

Jakiś czas temu miałem okazję debuggować kod kompilatora .NETa podpiętego pod Developerskie Visual Studio,
czyli w praktyce odpalałem swoje Visual Studio, z niego odpalała mi się wersja Developerska Visual Studio, stawiałem break pointy w swoim VS i klikałem po wersji Dev Visual Studio.

A zatem, jeżeli takie dwie kobyły mające sumarycznie wiele dziesiątek milionów linii kodu (sam Roslyn z 30-40 milionów iirc) potrafią się odpalić lokalnie po git clone, odpaleniu jednej batki i 2 klikach w IDE

to trochę słabo jeżeli proste web appki nie potrafią się łatwo i szybko odpalić lokalnie.

Uważam że powinno się dążyć do tego aby git clone + dotnet run czy w ostateczności jakiś tam dokjer wystarczyły do odpalenia

@1a2b3c4d5e: Sprawa się "trochę" komplikuje jak masz do odpalenia zamiast dwóch dużych kobył po parę milionów linii kodu, 2-3 małe komponenty, za to zależne od iluś tam usług chmurowych.

@piotrpo:

Nie ma żadnych sandboxów? a może czasem warto mocka napisać

@AngryProgrammer: W, CI/CD nie macie tych samych testów co lokalnie?

ale prawdziwa aplikacja już nie wstaje

Jak wy tam dewelopujecie, ja jak mam coś zrobić to często strzelam z postmana i siedzę pod debuggerem.

Jestem przyzwyczajony do tego, że nie odpalam aplikacji. Przeważnie mam jakieś tesry, które odpalają wszystko co potrzeba i nawet coś tam przeklikają, niewiele - to bardziej kilka smoke testów gui (jeśli takie mamy) niż sensowne pokrycie e2e (mocno zresztą zależy od projektu ).

1. Nie ma problemu ze stawianiem aplikacji, bo zwykle jest, który to robi nawet jakby trzeba podnieść 20 ròżnych serwisów i kilka baz danych. I nawet jest jakaś gruba komenda run.
2. Mimo to często nie odpalam i zdażyło mi się wypuścić kawałki kodu, które nie miały prawa działać na prod :-) ( bo np. zapomniałem o jakichś specyficznych problemach w security/application firewall)

AngryProgrammer napisał(a):

W każdym razie, odpowiedź mojego nowego teamu mnie zaskoczyła, zapytali "ale po co uruchamiać aplikacje lokalnie?"

Ależ bierno-agresywna odpowiedź typowego pseudoseniora.

. Odpowiedziałem, że chociażby po to by po skończonym developmencie przetestować manualnie to co się zrobiło, czy też zobaczyć czy spring w ogóle wstaje z takim a nie innym configiem.

Odpowiedź na to brzmiała "my mamy dobre testy, nie musimy aplikacji już odpalać".

Hmm... co może pójść nie tak? Taka pycha już sama w sobie jest czerwoną flagą. To nawet nie pseudosenior, to jakiś junior, który z braku doświadczenia nie ma wyobraźni, że coś może pójść źle.

Efekt? Aplikacje są wdrażane na deva i nie działają, bo testy mimo wszystko nie są idealne, wiele przypadków jest jednak pominiętych i to wychodzi dopiero gdy ktoś przejdzie po takim API od A do Z. Często są różnice między propertiesami w testach a na środowisku przez co aplikacja działa po prostu inaczej (flyway.enabled: true/false). Mało tego, wychodzą nawet takie błędy jak zła konfiguracja beanów, przez co spring w ogóle nie wstaje.

No to było oczywiste, pozostaje ci tylko powiedzieć "a nie mówiłem" i ew. rzucić papierami. Swoją drogą tę rozmowę miałeś przed zatrudnieniem, czy już po zatrudnieniu?

Tak, testuje lokalnie, bo niektóre cechy aplikacji trudno przetestować automatycznie. Niektóre rzeczy są wręcz mocno subiektywne. Np. sprawdzenie czy help się renderuje poprawnie i czy jest czytelny. Testem automatycznym mogę sprawdzić czy help coś tam wyświetli, ale raczej nie wyłapie nieładnego formatowania.

Manualnie zawsze.

Co to znaczy że twoje argumenty nie miały sensu dla nikogo? Dla ciebie też nie miały? Nie zgadzasz się z zespołem? Przekonali cię do swojego podejścia? Jeśli nie, to zmień zespół bo będziesz sfrustrowany.

Jak jest taka możliwość to odpalam manualnie podczas developmentu. Staram się jednak by wszystkie przypadki były pokryte testami i jakbym coś wykrył manualnie, to na pewno bym postarał się dodać odpowiedni test, który pokryje przypadek użycia.

Bardzo rzadko, jak już to na ogół czy dobre propertisty podstawiłem. Poza tym, testy manualne na ogół nie przynoszą mi korzyści, ja tworzę tylko API i integracje z innymi systemami, więc nie musze sprawdzać "czy coś jest czytelne"

Nie