On 20/05/2011 09:26, Maciej Sobczak wrote:
> On 20 Maj, 09:35, Michal Kleczek<k...@g...com> wrote:
>
>>> Oczywiście, że każda iteracja jest testowana od A do Z. Automatycznie.
>>
>> Sek w tym, ze to jest tylko _udawanie_ testowania.
>
> Zgadzam się.
>
> Wydaje mi się, że agile/xp opiera się na założeniu, że test jest tani.
> Tak tani, jak build albo nawet pojedynczy commit w repozytorium.

Źle ci się wydaje.

> Dlatego pojawiają się absurdalne pomysły, żeby te rzeczy łączyć.

To nie są absurdalne pomysły. To jest bardzo dobry pomysł, żeby mieć
suitę testów, która leci przy każdym buildzie - z powodzeniem stosuje
się to nawet w procesach, które tak poza tym nie są agile.

Jeśli chodzi o to, jaki jest koszt testu, to trzeba wliczyć następujące
czynniki:
* koszt stworzenia frameworku do testów - może być niebanalny, ale
rozkłada się na wiele testów. Tutaj masz moduł do unit testów, ale też
automatyzację testów integracyjnych, czyli np. stworzenie skryptu, który
ci bierze daily build, robi automatyczny deployment w środowisku
testowym, odpala skrypty testowe i rozsyła wyniki.
* koszt przeprowadzania zautomatyzowanych testów, w co wchodzi
utrzymanie środowiska testowego i związany z tym czynnik czasowy: w
pełni automatyczne testy mogą być wykonywane przez noc lub nawet 24
godziny na dobę, ale jeśli przestaje wystarczać czasu w dobie, to
wchodzi dodatkowy koszt powiększenia środowiska testowego. Można też
podzielić testy na te, które wykonywane są na każdym nightly buildzie,
pełen zestaw, który jest robiony raz na iterację.
* koszt napisania automatycznych testów: TDD zakłada, że znacząca część
wysiłku programistycznego idzie w pisanie testów.
* koszt wykrycia tego, jakie testy trzeba mieć w skrypcie. Tutaj wchodzi
exploratory testing, czyli generalnie testowanie ręczne, tylko że nie
jest to ręczne wykonywanie testów "od A do Z", tylko odkrywanie, że
trzeba jeszcze dopisać Ź, Ż i Ń.

To ostatnie to jest koszt testerów i ich stanowisk w takiej ilości, jak
potrzeba. Kwestia tylko taka, że exploratory testing nie dotyczy w
szczególny sposób wersji demo/release, tylko jest robione na codziennych
buildach.

> 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, z którymi nie mogłyby sobie poradzić testy automatyczne.