Wyobraźmy sobie, ze jest klasa w Typescript o nazwie UserTypeGetter Jest odpowiedzialna za połączenie z zewnętrznym api i pobraniem tablicy (json) z typami użytkowników.
Czy jeżeli napiszemy test do tej klasy który sprawdza czy zwrócona tablica posiada jakieś wyniki to czy wtedy czasem nie jest tak ze to już nie jest Test Jednostkowy ? (Bo opiera się na kodzie związanym z backendem)
@michal_szn: jeżeli sama komunikacja z API jest wydzielona do osobnego kolaboranta i podczas testu użyjesz dublera zamiast faktycznej implementacji to wtedy jak najbardziej będzie to unit test.
@S-Sawicka: No ale właśnie chodzi o to, ze nie ma żadnego dublera... czyli w teorii to nie jest UnitTest
@LazyInitializationException Czyli naprawdę korzyść pisania takich testów jest niewielka, jeśli 90% klas aplikacji w jakis sposób komunikuje się z api...
@michal_szn: El classico - to zależy jeżeli przepychasz dane z backendu do frontu gdzies dalej to chyba nie ale jak robisz jakieś mapowanie/normalizacje danych to już tak. W takim wypadku być może rozwiązaniem jest wyekstrachowanie mappera i wtedy możesz go łatwo przetestować unitowo f(dane z API)=>dane które oczekuje front-end
@michal_szn nie no to zależy co nazywasz jednostką, ale masz rację że to już bardziej test integracyjny, mógłbyś do tej klasy dostarczyć jakoś klienta http i zwracać jakieś fejkowe wyniki, wtedy to będzie na pewno bliżej testu jednostkowego
Wyobraźmy sobie, ze jest klasa w Typescript o nazwie UserTypeGetter
Jest odpowiedzialna za połączenie z zewnętrznym api i pobraniem tablicy (json) z typami użytkowników.
Czy jeżeli napiszemy test do tej klasy który sprawdza czy zwrócona tablica posiada jakieś wyniki to czy wtedy czasem nie jest tak ze to już nie jest Test Jednostkowy ? (Bo opiera się na kodzie związanym z backendem)
Komentarz usunięty przez moderatora
@LazyInitializationException Czyli naprawdę korzyść pisania takich testów jest niewielka, jeśli 90% klas aplikacji w jakis sposób komunikuje się z api...