On 21/05/2011 10:19, Maciej Sobczak wrote:
> 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.

Znaczy, nie robisz żadnych testów, bo testy niczemu nie zapobiegają, a
tylko dają fałszywe poczucie bezpieczeństwa.

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

Ej, ale jak rozumiesz "się nie da"? Że testy spowodują, że w ogóle
błędów nie będzie, no to rzecz jasna. Ale skoro i tak będą, to klienta
może interesować, czy będzie ich mniej czy więcej, czy będą występować
częściej, czy rzadziej. I jeśli mówisz klientowi, że testowanie nie ma
na to żadnego wpływu, to moim skromnym zdaniem jednak go trochę oszukujesz.

> 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".

Nie tylko unit testy można odpalać z automata. Można automatycznie
testować całe systemy, nawet GUI.

> 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[*].

Bo źle interpretujesz tę miarę. Ona mówi ci tyle, że jak masz kod
niepokryty testami to jest potencjalnie źle, a nie, że jak masz pokryty
to jest dobrze.

> Wybij sobie z głowy taki pomysł, że jakakolwiek (pseudo)metodologia
> pozwoli niedoświadczonym ludziom robić dobre projekty.

Oczywiście! Stąd moje zastrzeżenie do waterfall, że te wszystkie
metodologie analizowania i projektowania to i tak machanie rękami wokół
tego, że szacunki opierają się na doświadczeniu osoby z odpowiednim
doświadczeniem.

> 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ć.

Zgoda! I to nie jest tak, że w agile nie ma planowania. Jest planowanie,
i podstawą planowania jest to, że się zbiera osoby z odpowiednim
doświadczeniem w jednym pomieszczeniu.

> 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.

Ach, widzisz, tylko tak się składa, że istnieje taka szkoła
projektowania jak "simple design"/"incremental design", która mówi, że
na każdym etapie projekt jest tak prosty, że da się go wymyśleć w 15
minut, narysować na papierze w 20 sekund, wytłumaczyć w 5 minut i
zapisać w kodzie w sposób tak oczywisty, że papierowa dokumentacja nie
jest potrzebna. Przykładowo: "rozdzielę program na część pobierającą
komunikaty z feeda i część analizującą i przetwarzającą te komunikaty,
takie moduły mogą być od siebie w dużej mierze niezależne. Mam więc
projekt taki, że FeedInterface przekazuje Message do MessageProcessor.
Robienie w tym momencie większego projektu uważam za błąd.

> 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.

O, super to ująłeś, mogę pożyczyć? "Analiza, projekt - bywa, że są do
dupy i dają fałszywe poczucie bezpieczeństwa. Problem z
waterfall/iterative polega na tym, że nie dają żadneej obrony przed taką
możliwością, a przez to prowadzą do fałszywego poczucia bezpieczeństwa."