On Tuesday, 23 July 2013 09:30:21 UTC+1, Adam Klobukowski wrote:
> On Tuesday, 23 July 2013 09:26:06 UTC+2, Andrzej Jarzabek wrote:
>
> > Owszem, ale też zasygnalizują ci, że funkcja z 60 parametrami czy klasa
> > z 60 setterami to prawdopodobnie nienajlepszy pomysł i powinieneś rozbić
> > problem na składowe zagadnienia, które będą realizowane przez osobne
> > jednostki kodu (funkcje, klasy), które będą miały swoje unit testy,
> > przez co nie ma potrzeby sprawdzania testami kombinacji warunków
> > brzegowych itp. dla 60 parametrów.
>
>
>
> Podzielone to owszem jest, testy też, ale i tak istotne jest to co jest
> finalnie na wyjściu. Po prostu unit testy nie dają gwarancji że jeśli
> każde 10% ze 100% działa ok, to całe 100% będzie działać ok.

Tak. Nie. Znaczy:

Mówiliśmy o dokumentacyjnej, nie weryfikacyjnej roli testów. Dokumentacja nie
jest od dawania gwarancji, jest od udzielania informacji, w tym przypadku jak
dana funkja czy klasa działa.

Testy tak w ogóle (nie tylko unit testy) nie dają 100% gwarancji że coś
działa, wykrywają że nie działa z pewnym prawdopodobieństwem (redukują
ryzyko niedziałania).

Jeśli masz dobry projekt, sensowne testy i konsekwentnie trzymasz się
dyscypliny TDD, to unit testy redukują ryzyko niedziałania całości w bardzo
sensownym stopniu. Jeśli ma się powody przypuszczać, że testy mają luki w
sprawdzaniu czy testowane jednostki faktycznie działają razem żeby uzyskać
pożądaną funkcjonalność końcową, to warto pomyśleć o dopisaniu unit testów
które to sprawdzają. Jeśli projekt kodu (klas) jest taki, że trudno to zrobić,
warto pomyśleć o zrewidowaniu projektu. Kluczowe hasła tutaj: dependency
injection, mock objects.

Unit testy nie zabezpieczają przed sabotażem, bądź w postaci celowego zepsucia
kodu, bądź działania bezmyślnego, łamania dyscyplin itd.

Tak, owszem, opócz unit testów dobrze/nalezy mieć testy wyższego poziomu:
smoke/system/acceptance/functional/integration tests. Dlatego, że testują
rzeczy, których unit testy nie magą wyłapać (lub nie jest to praktyczne), ale
też dlatego, że moga pełnić funkcję dokumentacyjną innego rodzaju niż unit
testy. Unit testy dokumentują projekt kodu - co robią i jak się używa
poszczególnych klas, funkcji itd. Inne testy mogą dokumentowac funkcjonalność
biznesową, architekturę systemu, protokoły zewnętrznych interfejsów,
zachowania, co tam jeszcze.