qarmin
Twórca
Jak często korzystacie z testów jednostkowych w swoich projektach?
Języków znam kilka, ale głównie z testami jednostkowymi miałem styczność jedynie w Pythonie i Rust.
W pythonie widzę że czasami niektóre repozytoria chwalą się coverage sięgającym niemal 100%.
W przypadku Rusta, ilość testów jest powiedzmy szczerze dosć ograniczona.
Mimo że uważam testy jednostkowe ogólnie za coś bardzo dobrego, to jednak bliżej mi do ich pisania tam gdzie niezbędne a nie dopychania ich na ilość.
W Rust, widzę że głównie pisze się testy do funkcji bez skutków ubocznych, czyli wrzucamy cos do środka i oczekujemy określonego wyniku(choć oczywiście są wyjątki).
W Pythonie jednak widzę że testuje się absolutnie wszystko, a to za sprawą że można zmockować niemal wszystko.
Trzeba dodać coverage do funkcji z pobieraniem informacji z bazy danych?
Nie ma sprawy, mockujemy połączenie i testujemy zwracanie wyjątku, losowych czy pustych danych.
Niby fajnie, ale jednak z tego co widzę to wydaje mi się że czasami takie funkcje testują bardziej to czy kod jest poprawnie zamokowany a nie samą logikę funkcji i są robione jako sztuka dla sztuki(lub po to by podbić coverage).
Często widzę że też takimi testami próbuje się testować, co się stanie jeśli typy nie są poprawne, coś co niemal nie występuje w językach silnie typowanych typu Rust lub C++, bo już kompilator odrzuca sporą część niepoprawnego kodu.
Jakie są wasze opinie o dużym coverage w zależności od języka dla którego testy są pisane?
#programowanie
Języków znam kilka, ale głównie z testami jednostkowymi miałem styczność jedynie w Pythonie i Rust.
W pythonie widzę że czasami niektóre repozytoria chwalą się coverage sięgającym niemal 100%.
W przypadku Rusta, ilość testów jest powiedzmy szczerze dosć ograniczona.
Mimo że uważam testy jednostkowe ogólnie za coś bardzo dobrego, to jednak bliżej mi do ich pisania tam gdzie niezbędne a nie dopychania ich na ilość.
W Rust, widzę że głównie pisze się testy do funkcji bez skutków ubocznych, czyli wrzucamy cos do środka i oczekujemy określonego wyniku(choć oczywiście są wyjątki).
W Pythonie jednak widzę że testuje się absolutnie wszystko, a to za sprawą że można zmockować niemal wszystko.
Trzeba dodać coverage do funkcji z pobieraniem informacji z bazy danych?
Nie ma sprawy, mockujemy połączenie i testujemy zwracanie wyjątku, losowych czy pustych danych.
Niby fajnie, ale jednak z tego co widzę to wydaje mi się że czasami takie funkcje testują bardziej to czy kod jest poprawnie zamokowany a nie samą logikę funkcji i są robione jako sztuka dla sztuki(lub po to by podbić coverage).
Często widzę że też takimi testami próbuje się testować, co się stanie jeśli typy nie są poprawne, coś co niemal nie występuje w językach silnie typowanych typu Rust lub C++, bo już kompilator odrzuca sporą część niepoprawnego kodu.
Jakie są wasze opinie o dużym coverage w zależności od języka dla którego testy są pisane?
#programowanie
Nie jestem tak biegły w kodowanie, czystych testów jednostkowych nie piszę, niemniej jak piszę macra do programu którego używam, to badam każdą jedną funkcję. Niestety ten soft mimo potencjału był tworzony przez debili którzy zlecili jego działanie debili na stażu i nawet, mimo że po API zwracam konkretną wartość, to raz się zwraca, a raz nie (albo nic, albo zwraca dane z d⁎⁎y) i szukam workaroundów, coś ala scrapowania tego co widzę. Prócz tego jest wiele podobnych rzeczy, które wymagają różnego podejścia - raz tablic dynamicznych, raz statycznych, raz obiektów, innym razem tylko doublów.
Pomaga mi to jednak rozwinąć się na nieszablonowe myślenie, po pierwsze alternatywne, lepsze (kub gorsze, ale nadal działające) rozwiązania, po drugie dzięki temu znajduję swoje błędy, nieprzewidziane przypadki które mogłyby spowodować wysypanie się softu.
Według mnie dodając coś zawsze warto choć raz to przetestować - zarówno na wszelakie dane, jak i idiotoodporność, gdy np. ktoś wklei tekst a program oczekuje liczbę, albo da liczbę z separatoem w dziesiętnym, a soft wymaga przecinka.