Wątek przeniesiony 2022-03-24 16:52 z Java przez cerrato.

Testowanie - na jakim poziomie najwięcej testów?

0

Każdy projekt to inni ludzie i inne sposoby testowania.

Na pewno bez sensu jest imho powielenia testów na każdym poziomie byle tylko zapewnić % pokrycia.

Moje kilka rozkmin i wątpliwości:

  1. Czy raczej więcej testów robić na poziomie fasad (ze wstrzykiwanymi implementacjami repo na kolekcjach i innymi fejk implementacjami pozostałych zależnoscj - byle ograniczyć mokito do minimum) czy tez na poziomie postawionej apki z jakimś testconteiners i innymi lokalnymi kontenerami.

  2. Testy już na stojącej apce lubię robić poprzez napisane clienty zamiast mock mvc czy rest assura. Podobnie jak @Shalom w swoim demo. Tylko trochę to wygląda tak, że modele z fasad tłumaczę na HttpResponse a potem w tych klientach w drugą stronę. W sumie klient i fasada mają te same kontrakty. To jest ok?

  3. Testowanie poprzez clienty nie sprawdza kontraktu. Jak sobie zrefaktotuję nazwę pola w dto to test i tak przejdzie a UI czy inny mikroserwis strzelający do mnie już się realnie sypnie. Takie przypadki wychwycą testy e2e. A co jeśli projekt takich nie posiada :D

  4. Co mówicie o testach API w tym przypadku?

6

Jak sobie zrefaktotuję nazwę pola w dto to test i tak przejdzie a UI czy inny mikroserwis strzelający do mnie już się realnie sypnie. Takie przypadki wychwycą testy e2e. A co jeśli projekt takich nie posiada

To masz problem skoro nie masz testów e2e. Przykro mi, ale takich błędów nie da się wychwycić inaczej. Jeśli ktoś myśli że testy na niższym poziomie sprawiaja ze nie potrzeba mu testów e2e to boleśnie będzie się musiał kiedyś przekonać że tak nie jest. A im niższy poziom testów które ma, tym szybciej.

Testy na poziomie "stawiamy apkę z testcontainers i uderzamy normalnie w endpointy tak jak będzie to robić klient" moim zdaniem mają ten plus, że pokrywają 95% interakcji i jedyne bugi jakie przez takie sito przejdą są właśnie na poziomie interfejsu z jakimś zewnętrznym systemem. Co wiecej w takich testach można prawie zawsze dość łatwo zreprodukować buga.
Oczywiście to nie znaczy ze można/trzeba mieć tylko i wyłącznie takie testy - tak jak pisałem wielokrotnie, jeśli mamy złożony kawałek logiki/algorytm który chcemy przetestować, w oderwaniu od tego gdzie i jak to jest używane w systemie, to jak najbardziej warto porobić do niego unit testy. Ale trzeba pamiętać, ze to że nasze testy pokazują ze jakiśtam algorytm czy serwis działają poprawnie, nijak sie ma do tego czy system działa poprawnie, bo dany serwis może w ogóle nigdzie w kodzie nie być użyty, albo wyższa warstwa może mu przekazywać błędne dane.

Schodzenie testami na niższy poziom, czyli np. zamiast uderzać po endpointach wołamy w teście bezpośrednio metody serwisów domenowych, albo podmieniamy sobie repozytorium na implementacje która czyta z jakiejś statycznej mapy, to jest generalnie trade-off pomiędzy tym jak dobrze test sprawdza system, a tym jak szybko testy się wykonują (albo jak złożone jest ich napisanie). Każde takie zejście "niżej" sprawia że pomijamy testowanie pewnego fragmentu systemu (np. stukajac bezpośrednio po serwisach pomijamy security endpointów, a podmieniajac repozytorium pomijamy sprawdzenie czy nasze query są poprawne) i trzeba sobie zadać pytanie czy zysk jest tego warty. Szczególnie, że automatycznie wymaga to od nas potencjalnie większej liczby testów e2e, które pokryją te brakujące elementy.

Kwestii klientów (punkt 2) troche nie rozumiem. Takiego klienta i tak w 99% przypadków musisz napisać, bo inne serwisy będą chciały korzystać z twojego i nie ma sensu żeby każdy pisał ten sam kod do komunikacji.

6

Ja bym zaczął od tego że to bardzo zależy od rodzaju aplikacji i tego co testujemy. Im bardziej CRUD/mniej skomplikowanych warunków tym bardziej testy integracyjne, a jeśli mamy jakąś bardziej złożoną logikę to testy jednostkowe. Przy czym przy testach itegracyjnych najlepsze oczywiście jest podejscie blackboxowe, np.
robisz request zeby przelać 2137 zł na konto, późnie walisz requesty po stan konta i sprawdzasz czy jest powiększone/pomniejszone te saldo o 2137 zł.

0

@Shalom: co do punktu drugiego to chodzi o to, że w gruncie rzeczy fasada/serwis i klient ma ten sam kontrakt.
Załóżmy, że z serwisu zwracamy Either<Error, UserDto
i mapujemy to na jakis ResponseEntity

to potem pisząc nasz klient restowy mapujemy w drugą stronę i finalnie masz restowy client zwróci Either<Error,UserDto> czyli to samo co serwis.

W sensie nie uważam tego za problem, ale mam rację, że tak jest?

A co do tego że zawsze i tak musisz napisać te klienty - no nie .. czasem jedynym konsumentem jest UI.

1

nasz klient restowy mapujemy w drugą stronę

Co ty tam chcesz mapować? Mówisz jacksonowali jaka klasa przychodzi z jsona i tyle, nie ma tam żadnego mapowania :) I nie, moim zdaniem niekoniecznie jest tak jak piszesz, bo z RESTowego klienta wraca ci jakis Either<RestError,UserDTO> podczas gdy z serwisu domenowego jakiś Either<DomainError,UserDTO> albo czasami User a nie UserDTO

3

Najlepiej podzielić kod na moduły (oczywiście nie fizycznie, tylko koncepcyjnie), coś jak zwarte części (np API HTTP, domenę biznesową, widok, persystencję), i najpierw przetestować każdą z tych części osobno, potem interakcję pomiędzy tymi częściami.

Poza tym, pamiętaj że to nie jest tak że więcej testów == lepiej. Testy to też jest zależność, i mają również swój koszt. Także nie pisz więcej testów, niż jest to absolutnie wymagane, ale też nie mniej niż jest logiki i zachowania do przetestowania.

W skrócie: jeśli wpadniesz na jakiś pomysł, jak zepsuć aplikację (tak że nie będzie działać albo będzie miała defekt), to powinien być również jeden (i najlepiej jeden) test który sfailuje jak to zrobisz.

Co do samej ilości testów, w moich projektach średnio proporcje kodu do testów to jest tak mniej więcej na 1 część kodu produkcyjnego, przypada około 2-3.5 części testów; ale to nie jest zasada.

1

Najlepiej podzielić kod na moduły (oczywiście nie fizycznie, tylko koncepcyjnie), coś jak zwarte części (np API HTTP, domenę biznesową, widok, persystencję), i najpierw przetestować każdą z tych części osobno, potem interakcję pomiędzy tymi częściami.

nie. nie ma sensu sprawdzać czy adnotacje w kontrolerach Springa działają osobnymi testami.

1
scibi_92 napisał(a):

Najlepiej podzielić kod na moduły (oczywiście nie fizycznie, tylko koncepcyjnie), coś jak zwarte części (np API HTTP, domenę biznesową, widok, persystencję), i najpierw przetestować każdą z tych części osobno, potem interakcję pomiędzy tymi częściami.

nie. nie ma sensu sprawdzać czy adnotacje w kontrolerach Springa działają osobnymi testami.

A jak inaczej sprawdzisz czy przy kontrolerze jest @GetMapping czy @PostMapping?

Jedynym innym wyjściem byłoby włączyć aplikację i strzelać pod endpointy, jasne. Tylko wtedy nie napiszesz 2000 testów które się wykonują w 2 sekundy, tylko może 500 testów które siekają 10, 15 minut albo i więcej. Upośledzisz w ten sposób swój system testów, dodawanie kolejnych feature'ów i testów będzie wolniejsze.

Popracuj w takim systemie kilka lat i będziesz miał test suite który chodzi godzinę, więc nikt go już nie odpala lokalnie, tylko przeniosą to do CI/CD w chmurze, i testy staną się useless.

Good luck.

4

Tylko wtedy nie napiszesz 2000 testów które się wykonują w 2 sekundy, tylko może 500 testów które siekają 10, 15 minut albo i więcej.

Nie wiem jakie mother of all moliths piszesz ale nie wiem czy widziałem serwis który potrzebowałby więcej niż ~100 testów i wykonują się kilkanascie sekund.

W takiej sytuacji problem stanowi zły design a nie zły poziom testów i zaczyna sie kombinowanie z serii "testujmy mniej/gorzej ale szybciej". Trochę jak ten kawał:

  • W CV napisał Pan, że potrafi szybko liczyć... więc ile to jest 39 razy 12
  • 36
  • to nawet nie było blisko!
  • ale szybko
1
Shalom napisał(a):

Tylko wtedy nie napiszesz 2000 testów które się wykonują w 2 sekundy, tylko może 500 testów które siekają 10, 15 minut albo i więcej.

Nie wiem jakie mother of all moliths piszesz ale nie wiem czy widziałem serwis który potrzebowałby więcej niż ~100 testówm i wykonują się kilkanascie sekund.

100 testów na całe API http aplikacji? ;| Mało coś.

Shalom napisał(a):

W takiej sytuacji problem stanowi zły design a nie zły poziom testów i zaczyna sie kombinowanie z serii "testujmy mniej/gorzej ale szybciej".

Tylko jeśli ktoś nie ma doświadczenia albo nie wie jak się pisze dobre testy.

Można mieć bardzo dużo testów, tak że nadal się wykonują bardzo szybko (i jednocześnie testują dobrze).

To nie jest tak, że masz taki trójkąt good, fast, many z którego możesz mieć dwa, ale nie trzeci.

1
scibi_92 napisał(a):

Najlepiej podzielić kod na moduły (oczywiście nie fizycznie, tylko koncepcyjnie), coś jak zwarte części (np API HTTP, domenę biznesową, widok, persystencję), i najpierw przetestować każdą z tych części osobno, potem interakcję pomiędzy tymi częściami.

nie. nie ma sensu sprawdzać czy adnotacje w kontrolerach Springa działają osobnymi testami.

Shalom napisał(a):

Tylko wtedy nie napiszesz 2000 testów które się wykonują w 2 sekundy, tylko może 500 testów które siekają 10, 15 minut albo i więcej.

Nie wiem jakie mother of all moliths piszesz ale nie wiem czy widziałem serwis który potrzebowałby więcej niż ~100 testów i wykonują się kilkanascie sekund.

W takiej sytuacji problem stanowi zły design a nie zły poziom testów i zaczyna sie kombinowanie z serii "testujmy mniej/gorzej ale szybciej".

Shalom napisał(a):

100 testów na całe API http aplikacji? ;| Mało coś. mikroserwisy panie Ferdku, mówi to coś panu? ;)

Wszystko to bardzo dobre argumenty, ale niestety nic nie wnoszą.

Mając do wyboru:

  1. szybkie testy bez włączania aplikacji + kilka integracyjnych

vs.

  1. wszystkie testy które strzelają po api do stojącej aplikacji

...po co - z jakiego powodu miałbym wybrać to drugie? Ma same wady, i zero zalet. Tak, niektóre z tych wad można ominąć jak się ma mały mikroserwis, i mało logiki do testowania jeśli odpalasz wszystkie testy na raz na koniec dnia, ale samej zasadności dalej nie ma.

  1. Nadal musisz postawić aplikację, żeby odpalić testy.
  2. Nawet jak masz 100 testów na microserwis jak @Shalom to nadal to będzie trwało kilkanaście sekund do minuty, zamiast 1 sekund.
  3. Jak odpalasz jeden test do debuga albo do developmentu, to do postawienia aplikacji poczekasz kilka sekund (zamiast kilka milisekund w przypadku zwykłego testu).
  4. Nadal nie masz jak wstrzyknąć moków albo fake'ów.

Można zaryzykować stwierdzenia że nie można uprawiać TDD z takimi testami, przez to że są tak wolne.

5

z jakiego powodu miałbym wybrać to drugie?

Tak jak pisałem na początku tego wątku, sens jest taki, że te drugie testy sprawdzają faktycznie czy system działa (modulo jakieś wyjątkowe sytuacje z niedograniem API), podczas gdy te pierwsze sprawdzają tylko czy jakiś kawałek kodu działa i w zasadzie niczego mi nie mówią.
To że takie testy są zielone, oznacza tylko że jakiś kawałek kodu działa zgodnie z asercjami w teście, ale ten kawałek kodu moze nigdy nigdzie nie być wywoływany i funkcja systemu wali HTTP500.
Z drugiej strony to ze takie testy są czerwone znów niczego mi nie mówi, bo takie testy maja tedencje do failowania przy dowolnym refaktoringu i znów to że są czerwone mówi ci tylko że jakiś kawałek kodu nie działa zgodnie z asercjami w teście (a często są czerwone tylko dlatego że struktura kodu się zmieniła, nagle wołamy metodę X a nie Y i mocki się zesrały).
Czyli w sumie nic mi te testy nie mówią o stanie systemu. Tylko co najwyżej o jakimś kawałku kodu.

Z drugiej strony test który uderza po endpointach tak jak robi to docelowy klient i sprawdzają czy wyniki są zgodne z oczekiwaniami, potwierdza że funkcja systemu działa zgodnie z wymaganiami, niezaleznie od tego co tam się dzieje w środku. Możesz wymienić logikę systemu na hindusa który ręcznie pisze ci jsony z odpowiedzią jak chcesz.

Nadal nie masz jak wstrzyknąć moków albo fake'ów.

I bardzo dobrze! Czemu miałbym coś takiego robić? o_O Ja chce testować jak działa kod który chce statkować na produkcje, a nie jak działa mockito. Co mi z testów które są zielone dla jakiegoś mocka, jak mi sie potem prawdziwa implementacja wywali?

1
Shalom napisał(a):

Z drugiej strony to ze takie testy są czerwone znów niczego mi nie mówi, bo takie testy maja tedencje do failowania przy dowolnym refaktoringu i znów to że są czerwone mówi ci tylko że jakiś kawałek kodu nie działa zgodnie z asercjami w teście (a często są czerwone tylko dlatego że struktura kodu się zmieniła, nagle wołamy metodę X a nie Y i mocki się zesrały).
Czyli w sumie nic mi te testy nie mówią o stanie systemu. Tylko co najwyżej o jakimś kawałku kodu.

Tylko jeśli jesteś na tyle nieodpowiedzialny żeby napisać testy które są tightly-coupled do kodu, że failują z takich randomowych powodów. Twój argument (ten konkretny) to nie jest argument przeciwko pisaniu testów które się odpala bez stawiania aplikacji, tylko przeciwko pisaniu testów które są przywiązane do implementacji. I ja się zgadzam.

Ja rozumiem, że łatwiej jest sobie powiedzieć "To nie moja wina że test sfailował, to wina tego że odpalamy testy na kodzie zamiast na aplikacji". Taka strefa komfortu. Ciężko jest się przyznać przed sobą "napisałem słaby test". Więc łatwiej jest zrzucić na runner testów, albo na proces, albo czasem na bibliotekę. Ale again, w dobrze napisanym test suitecie nie ma miejsca na coś takiego. Gdyby mi sfailował test przez refaktor - to nie powiedziałbym "aaag, muszę odpalić testy na prawdziwej aplikacji" tylko powiedziałbym "ten kto napisał ten test zjeb***" (i w 99% przypadków to byłbym ja sam). Nie każdy jednak ma zdolność do tego. Łatwiej jest się wyprzeć i zrobić talki walk around.

Także zgadzam się. Testom które failują randomowo przy rafaktorze nie można ufać. Ale radą na to nie jest odpalanie testów przy stojącej aplikacji, tylko konsekwentna poprawa dyscypliny w pisaniu dobrych testów. Ale zmiana w sobie wymaga wysiłku, niestety.

z jakiego powodu miałbym wybrać to drugie?

Tak jak pisałem na początku tego wątku, sens jest taki, że te drugie testy sprawdzają faktycznie czy system działa (modulo jakieś wyjątkowe sytuacje z niedograniem API), podczas gdy te pierwsze sprawdzają tylko czy jakiś kawałek kodu działa i w zasadzie niczego mi nie mówią.
To że takie testy są zielone, oznacza tylko że jakiś kawałek kodu działa zgodnie z asercjami w teście, ale ten kawałek kodu moze nigdy nigdzie nie być wywoływany i funkcja systemu wali HTTP500.

Oczywiście, warto mieć takie testy. Tu się zgadzam, że są istotne! Zgadzam się w 100%.

Ale ich ilość powinna musi być mała. Są koniecznie, ale niestety są też bardzo kosztowne. Zbyt kosztowne by dodać ich więcej niż kilka i zbyt kosztowne by odpalać je często, np 1-5 razy na minutę. Co potrzebujesz sprawdzić takim testem - Czy aplikacja wstaje/bootuje się, czy strzela do bazy lub innej persystencji, i po jednym teście na każdą integrację. Jakiekolwiek inne zachowanie lub szczegóły mogą się zawrzeć w testach które nie wymagają stawiania aplikacji. Niektórych rzeczy nie da się sprawdzić tylko z poziomu kodu, tak jak mówisz. Owszem. Ale takie rzeczy są w mniejszości, znaczącą część da się.

Z drugiej strony test który uderza po endpointach tak jak robi to docelowy klient i sprawdzają czy wyniki są zgodne z oczekiwaniami, potwierdza że funkcja systemu działa zgodnie z wymaganiami, niezaleznie od tego co tam się dzieje w środku. Możesz wymienić logikę systemu na hindusa który ręcznie pisze ci jsony z odpowiedzią jak chcesz.

Powiedziałbym że argument który przywołałeś jest z rodziny tych "technically correct". Czyli, tak, owszem to prawda co mówisz; jednak nie widzę żeby popierało Twoją pozycję w debacie.

Jakby - technicznie to co mówisz to prawda, ale co z tego, skoro są tak bardzo wolne.

Nadal nie masz jak wstrzyknąć moków albo fake'ów.

I bardzo dobrze! Czemu miałbym coś takiego robić? o_O Ja chce testować jak działa kod który chce statkować na produkcje, a nie jak działa mockito. Co mi z testów które są zielone dla jakiegoś mocka, jak mi sie potem prawdziwa implementacja wywali?

Co mi z testów które są zielone dla mocka; no to, że wiesz że jeśli testy przejdą to kod Twojej aplikacji działa dokładnie tak jak powinien (przy założeniu że testy są dobrze napisane).

Mam wrażenie że potrzegasz to zbyt czarno biało. Że albo wszystkie testy są bez stawiania apki, albo wszystkie z.

Moim zdaniem powinieneś napisać kilka kluczowych testów które są potrzebne do sprawdzenia tego o czym mówisz, czy aplikacja wstanie, czy prawdziwa integracja pyknie, etc. a pozostałą część logiki swojej aplikacji bez takiej integracji. Tych które na prawdę (powiedzmy) stawiają aplikacje lub strzelają do bazy powinno być mało.

Testy powinny być deterministyczne, przede wszystkim. Jak odpalisz je 1000 razy powinieneś dostać 1000 razy ten sam wynik. 1000. Nie 999, a raz false positive/negative. Jak Twoje testy strzelają do bazy, to czy na pewno jak failują to to jest problem z kodem? Of course not. Jest miejsce na niedeterministyczne testy, ale ich powinno być mało.

Ja widziałbym to tak, że miałbyś 900 testów (nawet na małą apkę) które odpalają się bez stawiania aplikacji, + kilka "cięższych" (dodane do grupy w junicie, żeby mi sie nie odpalały cały czas), i one mogłyby postawić aplikacje, strzelić do bazy lub czegoś innego. Te 900 testów mogłyby się wykonać w 1-2 sekundy, a kilka-kilkanaście tych cięższych mogłoby kilkanaście sekund do minuty. Co tym zyskam? To że mogę pracować w prawdziwym TDD, i po każdym refaktorze i dodaniu feater'ów odpalić 900 testów w sekundę, nie przerywając swojej pracy + na koniec feature'a przed puszem odpalić pełny suite.

W momencie w którym wszystkie moje testy byłby "ciężkie" i sprawdzały wszystko, nie mógłbym tego robić, odpałabym testy rzadziej bo po pierwsze; trwają dłużej; a po drugie musiałbym mieć inne zależności, tą bazę, albo container pod tomcata.

Gdyby istniał sposób żeby uruchamianie testów na stojącej aplikacji, np 1000 testów w sekundę to byłbym jak najbardziej za. Ale niestety nie mamy takiej technologii jeszcze.

0

Dla mnie tego typu testy, o których pisze @Shalom to bardziej dupochron przed commitem/pushem, no i w CI, niż coś co ma być odpalane as you code (a przynajmniej nieczęsto). Przy czym dobrze napisane i tak nie są aż tak wolne, no chyba, że chcesz stawiać tam WildFly'a zamiast Jetty/Netty.

W typowych serwisie na Springu (czy innym frameworku) po prostu za dużo się dzieje poza twoją logiką, żeby takich testów nie mieć. Prócz tego są bajecznie proste w utrzymaniu.

0
raxigan napisał(a):

Dla mnie tego typu testy, o których pisze @Shalom to bardziej dupochron przed commitem/pushem, no i w CI, niż coś co ma być odpalane as you code (a przynajmniej nieczęsto).

A testy o których ja mówię to nie dupochron przed commitem i pushem? ;|

6

Z mojej strony EOT bo jak ktoś pisze o tym że odpala testy 5 raz na minutę (czyli co 12 sekund) i ze go boli ze test wykonuje się sekundę a nie 10ms, to dla mnie jest to czyste bajkopisarstwo i nie mamy o czym dyskutować bo xD

0
Shalom napisał(a):

Z mojej strony EOT bo jak ktoś pisze o tym że odpala testy 5 raz na minutę (czyli co 12 sekund) i ze go boli ze test wykonuje się sekundę a nie 10ms, to dla mnie jest to czyste bajkopisarstwo i nie mamy o czym dyskutować bo xD

No mam Ci nagrać filmik jak pracuję? Sekundę mógłbym poczekać, ale 10 sekund na 10 testów to już za dużo.

Nie rozumiem teraz, zarzucasz mi że ja tylko tak plotę, a wcale moje projekty tak nie wyglądają? Czy po prostu wypierasz, to że tak się da pracować?

1
Shalom napisał(a):

Sorry ale jak ktoś twierdzi ze jest w stanie w 12 sekund zaklepać funkcjonalność i potrzebuje odpalić testy, to dla mnie jest bajkopisarstwo.

@Shalom A o TDD Pan słyszał czy nie?

Chyba ze jesteś saperem i twoje programowanie polega na jakimś usuwam jeden znak w kodzie i sprawdzam czy już się wywaliło odpalając wszystkie testy

No dokładnie tak to wygląda. A jako że 2000 testów trwa 500-1500 milisekund (w kompilowanym języku nawet mniej), to nie ma problemu z tym.

PS: Dokładniej mówiąc to usuwam znak, piszę test, usuwam znak, piszę test, etc. Ale tak.

6

@TomRiddle:

No mam Ci nagrać filmik jak pracuję?

chętnie zobaczę, bo chciałbym zobaczyć jaki zatem masz workflow i jak korzystasz ze swojego IDE

0
1a2b3c4d5e napisał(a):

@TomRiddle:

No mam Ci nagrać filmik jak pracuję?

chętnie zobaczę, bo chciałbym zobaczyć jaki zatem masz workflow i jak korzystasz ze swojego IDE

Zaproponowałem to, bo Shalom nie dowierzał że da się tak pracować; jednak myślę że każdy kto praktykuje TDD nie potrzebuje specjalnego przekonywania że odpalenie testów kilka razy nawet co 10-12 sekund to nie jest wcale bajkopisanie tylko standrdowa procedura.

1

@TomRiddle:

nie widzę żadnej wartości w odpalaniu tak często testów

a w 10 sec to co najwyżej napiszę 1 LoC i po co tu odpalać testy?

0
1a2b3c4d5e napisał(a):

@TomRiddle:

nie widzę żadnej wartości w odpalaniu tak często testów

A widzisz wadę?

a 10 sec to co najwyżej napiszę 1 LoC i po co tu odpalać testy?

Odpowiedź jest prosta. Szybki feedback, podczas pisania kodu tym lepiej im szybszy. Napisałem linijkę, mogę odpalić testy, nic mnie to nie kosztuje - czemu miałbym tego nie zrobić.

W 99% jak odpalisz testy po dopisaniu jednej linijki wszystkie przejdą tak jak się spodziewałes. Ale raz na jakiś czas sfailują kiedy się tego nie spodziewałeś i wtedy dostaniesz cenne info.

2

@TomRiddle:

ale jaki feedback?

napisze

foreach (var user in users)
{
}

puszczę test i co mi to da?

feedback dostaje cały czas od IDE, może o to Ci chodzi?

0
1a2b3c4d5e napisał(a):

@TomRiddle:

ale jaki feedback?

napisze

{
}

puszczę test i co mi to da?

feedback dostaje cały czas od IDE, może o to Ci chodzi?

I co, kciuk Ci odpadnie jak wciśniesz Shift+F10 żeby odpalić testy i poczekać 1 sekundę?

Wyrobienie sobie nawyku często odpalania testów to jest pożądana umiejętność. Nie zaszkodzi drobna redundancja w odpaleniu testów, jeśli testy się odpalają szybko. Więszkość linijek kodu które piszesz nie są tak bezefektowe jak foreach który pokazałeś.

Wyrobienie sobie nawyku linijka, run, linijka, run, linijka run jest spoko nawykiem. To że czasem taki run nie ma szans sfailować nic nie szkodzi. Nie warto sobie nim zaprzątać głowy.

2

Wyrobienie sobie nawyku linijka, run, linijka, run, linijka run jest spoko nawykiem

Serio wygląda mi to jak nawyk z PHP albo z jakiegoś innego dynamicznego języka jak Python, gdzie bez odpalenia w sumie nie wiadomo czy ten kod w ogóle ma prawo zadziałać czy nie zacznie rzucać jakimiś NoSuchMethod. W językach statycznie typowanych kompilator wyłapuje większość problemów.

0
Shalom napisał(a):

Wyrobienie sobie nawyku linijka, run, linijka, run, linijka run jest spoko nawykiem

Serio wygląda mi to jak nawyk z PHP albo z jakiegoś innego dynamicznego języka jak Python, gdzie bez odpalenia w sumie nie wiadomo czy ten kod w ogóle ma prawo zadziałać czy nie zacznie rzucać jakimiś NoSuchMethod. W językach statycznie typowanych kompilator wyłapuje większość problemów.

No to Ci źle wygląda, bo to nie ma to żadnego związku z compiletime safety.

Chodzi tylko o kod który spełnia wymagania biznesowe lub nie, o to czy po refaktorze aplikacja nadal działa tak jak ma działać.

1

@TomRiddle:

i co, kciuk Ci odpadnie jak wciśniesz Shift+F10 żeby odpalić testy i poczekać 1 sekundę?

ale to nie jest sekunda.

puszczenie test runnera, skompilowanie kodu, wykonanie testów to będzie at least z 5 sekund, gdzie testy wykonają się w 100ms.

0
1a2b3c4d5e napisał(a):

@TomRiddle:

i co, kciuk Ci odpadnie jak wciśniesz Shift+F10 żeby odpalić testy i poczekać 1 sekundę?

ale to nie jest sekunda.

puszczenie test runnera, skompilowanie kodu, wykonanie testów to będzie at least z 5 sekund, gdzie testy wykonają się w 100ms.

Powinna być sekunda, może nawet mniej jak odpalasz jeden test. Jeśli trwa dłużej, to to jest niepotrzebny narzut.

1

@TomRiddle:

Powinna być sekunda, może nawet mniej jak odpalasz jeden test.

nie będzie, bo kompilator cię ogranicza.

Jak sobie to w ogóle wyobrażasz w takim C++ gdzie czasy kompilacji jeszcze większe niż w w/w C#?

0
1a2b3c4d5e napisał(a):

@TomRiddle:

Powinna być sekunda, może nawet mniej jak odpalasz jeden test.

nie będzie, bo kompilator cię ogranicza.

Jak sobie to w ogóle wyobrażasz w takim C++ gdzie czasy kompilacji jeszcze większe niż w w/w C#?

Czas: 33:00.

1 użytkowników online, w tym zalogowanych: 0, gości: 1