On 21 Maj, 00:29, Andrzej Jarzabek <a...@g...com> wrote:

> > Problem w tym, że tanio to można przetestować bezstanowe funkcje typu
> > największy wspólny dzielnik (ale ironicznie, jeszcze łatwiej je
> > udowodnić) - wystarczy jednak że w systemie pojawia się współbieżność
> > albo efekty pamięciowe (cache) i testy "z automata" można sobie
> > wsadzić.
>
> Podaj może przykład, jak ręcznym testowaniem zapobiegasz powyższym
> problemom,

Nie zapobiegam im ani testami z automata ani ręcznymi.

Bo się nie da. Przynajmniej nikogo w tym nie oszukuję, ani siebie, ani
klienta.

Temat na anegdotę: w projekcie YAMI4 wszystkie (ok, oprócz jednego)
bugi wykryte po wersji 1.0.0 były w kodzie, który był pokryty przez
unit-testy. Tzn. ta konkretna linijka, w której był błąd, była
wykonana co najmniej raz przez jeden z testów, które są częścią
projektu. Te testy można odpalać "z automata".

Co to znaczy? To znaczy, że te testy były do dupy i dawały wszystkim
fałszywe poczucie bezpieczeństwa - dlatego miara pokrycia testów nie
ma żadnej użytecznej interpretacji[*].

Wybij sobie z głowy taki pomysł, że jakakolwiek (pseudo)metodologia
pozwoli niedoświadczonym ludziom robić dobre projekty. Dotyczy to
każdej dziedziny inżynierskiej, nie tylko IT. Doświadczenia nie da się
niczym zastąpić a jeśli już to doświadczenie jest, to należy z niego
skorzystać przy planowaniu co i jak należy zrobić.
Zysk z dobrego planowania jest większy, niż z testowania przy
porównywalnym wkładzie pracy i właśnie dlatego bardziej cenię sobie
dobrze przemyślany projekt (wspomniany już "papier" jako faza
wstępna), niż testy.
Testy, oczywiście, są. Ale jak już pisałem - bywa, że są do dupy i
dają fałszywe poczucie bezpieczeństwa.
Problem z agile/xp/itd. polega na tym, że niestety nie daje żadnych
kryteriów oceny ani obrony przed taką możliwością a przez to prowadzi
do fałszywego poczucia bezpieczeństwa.

[*] więcej:

http://www.inspirel.com/articles/Mythical_Code_Cover
age.html

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com