On 22/05/2011 23:19, Maciej Sobczak wrote:
> On 22 Maj, 14:39, Andrzej Jarzabek<a...@g...com> wrote:
>
>> Skoro więce robisz testy, to chyba jednak czemuś one zapobiegają. Bo
>> chyba nie powiesz, że robisz je, bo lubisz poczucie beezpieczeństwa?
>
> Robię je tam, gdzie (jak sądzę) ich użyteczność jest większa, niż ich
> koszt. To oznacza, że czasami ich nie robię a w szczególności czasami
> od nich nie zaczynam. Czyli traktuję testy tak, jak młotek i każde
> inne *narzędzie*, któro czasem jest odpowiednie a czasem nie.
> I dlatego nie mam zaufania do żadnej metody, która stawia testowanie
> (albo jakiekolwiek inne narzędzie) w centrum uwagi albo je wręcz
> wymusza.

A ja się jeszcze nigdy nie spotkałem przy żadnym większym produkcie
kompercyjnym żeby nie było procesu wymuszającego testy.

> najpierw zadziałać na papierze. Automatycznego testu nie ma sensu
> robić, bo jest to zbyt kosztowne (albo w praktyce w ogóle niemożliwe)
> w stosunku do efektu. Takie rzeczy testuję przy użyciu paczki czipsów,
> czyli robię testowy system, który wizualizuje mi się na ekranie, kładę
> nogi na stole i przy ostatnim czipsie wiem, czy działa poprawnie.

A możesz wyjaśnić, dlaczego tych danych, które wizualizujesz nie da się
przetestować automatycznie? To, o czym pisałeś nie da się powiązać z
jakąś mierzalną np. statystyczną właściwością danych?

> Jeśli jakaś metodologia zmuszałaby mnie do robienia automatycznych
> testów do tego typu wymagań, to ta metodologia jest do dupy. A
> ponieważ właśnie takie wymagania są najciekawsze i z takimi mam
> najwięcej do czynienia, to agile/xp/łotewer byłby dla mnie jedynie
> obciążeniem. Oops - a podobno miał być wybawieniem od poprzednich
> obciążających metodologii. There is no silver bullet.

Być może nie jest dostosowana do tego, co robisz. XP na przykład jest
pomyślane pod kątem programu, który ewoluuje, czy to dlatego, że
wymagania zmieniają się w trakcie developmentu, czy dlatego, że robi się
kolejne wersje z nową funkcjonalnością. Dodatkowo obejmuje programy
tworzone w wieloosobowych zespołach. TDD jest m. in. po to, żeby dlasze
modyfikacjee nie spowodowały regresji względem tych wymagań.

>> Można. Wiem, bo akurat moja praca ma z tym związek i blisko współpracuję
>> z ludźmi, którzy to właśnie robią.
>
> Etam. Dla mnie wymagania na GUI to np.:
>
> 1. w aplikacji do obsługi kont emerytalnych GUI ma być *przyjazne dla
> starszych osób*
[...]

Jeśli GUI robi coś innego, niż założyłeeś, że ma robić, to raczej nie
będzie przyjazne dla kogokolwiek.

Od tego, żeby "modelowe" GUI (z którym zgodność GUI rzeczywistego
sprawdzają testy) było takie jak trzeba to masz inne praktyki.

> Jeżeli pod pojęciem testowania GUI rozumiesz sprawdzenie, czy
> naciśnięcie przycisku wywołuje podpiętą do niego funkcję, to mówimy o
> różnych rzeczach. Ja mówię o tym, że nie da się automatycznie testować
> GUI; przypuszczam, że być może da się testować *display*, ale mały z
> tego pożytek.

Tak, automatyczne testowanie GUI to sprawdzanie czy naciśnięcie
przycisku powoduje pokazanie się odpowiedniego okienka, czy w gridzie są
odpowiednie dane itd. Pożytek z tego jest duży.

"Display" to monitor do komputera. Pewnie je jakoś testują w fabryce,
może i nawet automatycznie, ale przyznam się, że na tym się kompletnie
nie znam.

>> W przypadku projektów zlecanych zewnętrznie, ta widoczność powinna miec
>> postać "nasz człowiek siedzi z waszym zespołem i uczestniczy w zebraniach".
>
> "Nasz człowiek nie ma czasu i w ogóle to wyjeżdża/awansował/łotewer.
> Przyślijcie jak skończycie."

Jeśli robisz na zamówienie zewnętrznego klienta, to domyślnie wymagasz
obecności tego człowieka i wpisujesz to do umowy. Jeśli nie da się
wpisać do umowy, to nie stosujesz agile (a przynajmniej XP).

Alternatywa jest taka, że klient ufa, że twoi specjaliści rozpoznają
jego potrzeby biznesowe i że ty będziesz te potrzeby implementował tak,
żeby zmaksymalizować wartość programu dla niego, i to zaufanie też ma
odzwierciedlenie w umowie.