w jaki sposob sie pisze testy jednostkowe do bardziej ambitnych projektow? napisanie testu dla funkcji, ktora dodaje liczby wydaje sie calkiem proste, ale jak napisac test dla funckji, ktora pobiera dane z csv/bazy danych, nastepnie wykonuje jakies operacje i zapisuje do csv wynik? Albo funkcja, ktora modyfikuje jakas podana pandas.DataFrame i zwraca zmodyfikowana?
ale jak napisac test dla funckji, ktora pobiera dane z csv/bazy danych, nastepnie wykonuje jakies operacje i zapisuje do csv wynik?
To ta twoja funkcja tyle robi rzeczy na raz? To troche za dużo. Te interfejsy do peracji I/O się po prostu mockuje. Nie testujesz samego czytania/pisania. Możesz testować interpretację danych. Po za tym powyżej UT są inne typy testów.
Robisz test jednostkowy dla funkcji która pobiera dane, oddzielne testy dla funkcji robiących operacje, i oddzielny test dla funkcji zapisującej csv. Dzięki temu zamiast 5 * 5 * 5 = 125 kombinacji do przetestowania (jeśli każdy etap miał 5 przypadków testowych) masz tylko 5+5+5 = 15 testów.
Test sprawdzający to wszystko razem nie nazywa się jednostkowy, tylko integracyjny, i jest wiele sposobów
@przepyszna_frytka: dodam jeszcze jedną rzecz. CO ciekawe testowanie kodu przez UT to tak naprawdę główny cel jak już kod napiszesz, główny cel UT gdy piszesz nową klasę to zrobienie dobrych interfejsów dlatego najpierw pisze się UT a później kod.
@CukrowyWykop: Nie zgadzam się z tym. Źle zaprojektowana abstrakcja ujawnia się z opóźnieniem (czasem bardzo dużym) i główna zaleta testów - ułatwianie zmian - staje się ich wadą, bo testy wymagają zmian równolegle z kodem. Testy mogą tu pomóc pośrednio, kiedy zamiast je pisać myślimy o problemach z testowaniem na etapie projektowania albo podczas wyodrębniania wyspecjalizowanego kodu z wyższej, łatwiejszej (do testowania z góry) abstrakcji na etapie jej refactoringu. Tutaj dyskusja
@tell_me_more: mała notka do tego. to nie jest tak, że w przypadku posiadania funkcji, która pobiera dane, przelicza coś i zapisuje do csv nie można czy nie powinno się pisać testu jednostkowego dla tej funkcji jako całość, co wazne to nie będzie wtedy test integracyjny w pełnym tego słowa znaczeniu.
okreśrenie jednostki jest płynne, dla aplikacji webowej widok może być taką jednostką pomimo tego, że logika jest skomplikowana. oczywiście jeżeli wewnątrz
powiem ci że już więcej niż raz UT pomogły mi przemyśleć interfejs.
@CukrowyWykop: Może dasz radę pokazać jakiś przykład tego jak testy pomogły ci zaprojektować interfejs? Przy czym nie chodzi mi o pomaganie, o którym pisałem - "pośrednio", tylko przykład kiedy sam test pokazał, że interfejs jest zły - może nie uwzględniam jakichś przypadków po prostu.
Na razie uważam, że bezpośrednio nie zbudujesz struktury obiektów dzięki testom pojedynczych klas/kontraktów - w
tylko przykład kiedy sam test pokazał, że interfejs jest zły - może nie uwzględniam jakichś przypadków po prostu.
@MQs: cieżko z pamięci mi przywołać refactorowane moje projekty. Pamiętam że zaprojektowałem źle hierarchię obiektów. W momencie w którym zaczekałem pisać UT i patrząc na przypadki testowe, od razu nasunęło mi się że funkcje powinna np. zwracać coś innego, powinny być dwie funkcje albo trzeba to przenieść do innej klasy.
Albo funkcja, ktora modyfikuje jakas podana pandas.DataFrame i zwraca zmodyfikowana?
#programowanie #python #tdd
To ta twoja funkcja tyle robi rzeczy na raz? To troche za dużo. Te interfejsy do peracji I/O się po prostu mockuje. Nie testujesz samego czytania/pisania. Możesz testować interpretację danych. Po za tym powyżej UT są inne typy testów.
Robisz test jednostkowy dla funkcji która pobiera dane, oddzielne testy dla funkcji robiących operacje, i oddzielny test dla funkcji zapisującej csv. Dzięki temu zamiast 5 * 5 * 5 = 125 kombinacji do przetestowania (jeśli każdy etap miał 5 przypadków testowych) masz tylko 5+5+5 = 15 testów.
Test sprawdzający to wszystko razem nie nazywa się jednostkowy, tylko integracyjny, i jest wiele sposobów
@informatyk @PrawyKuba dzieki
@tell_me_more to by wiele wyjasnialo xd dzieki
Testy mogą tu pomóc pośrednio, kiedy zamiast je pisać myślimy o problemach z testowaniem na etapie projektowania albo podczas wyodrębniania wyspecjalizowanego kodu z wyższej, łatwiejszej (do testowania z góry) abstrakcji na etapie jej refactoringu.
Tutaj dyskusja
okreśrenie jednostki jest płynne, dla aplikacji webowej widok może być taką jednostką pomimo tego, że logika jest skomplikowana. oczywiście jeżeli wewnątrz
@MQs: powiem ci że już więcej niż raz UT pomogły mi przemyśleć interfejs. Wiadomo UT to nie panaceum na wszyskto ale pomaga.
wiesz jak to jest w firmach szczególnie w korpo ze refactoringiem.
@CukrowyWykop: Może dasz radę pokazać jakiś przykład tego jak testy pomogły ci zaprojektować interfejs? Przy czym nie chodzi mi o pomaganie, o którym pisałem - "pośrednio", tylko przykład kiedy sam test pokazał, że interfejs jest zły - może nie uwzględniam jakichś przypadków po prostu.
Na razie uważam, że bezpośrednio nie zbudujesz struktury obiektów dzięki testom pojedynczych klas/kontraktów - w
@MQs: cieżko z pamięci mi przywołać refactorowane moje projekty. Pamiętam że zaprojektowałem źle hierarchię obiektów. W momencie w którym zaczekałem pisać UT i patrząc na przypadki testowe, od razu nasunęło mi się że funkcje powinna np. zwracać coś innego, powinny być dwie funkcje albo trzeba to przenieść do innej klasy.