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.

Dwa skrajne przykłady z działki, którą zajmowałem się ostatnio
najwięcej (systemy rozproszone):

1. Jak piszę serializator, to używam TDD, bo serializator jest na to
idealnym miejscem. Zaczynam od protokołu i danych testowych, od
najprostszych do bardziej wyuzdanych i najpierw piszę test a potem
odpowiedni kod serializatora, z drobnymi iteracjami. Np. gdybym miał
pisać funkcję do kowersji ASCII->Morse, to też bym tak zrobił (osobne
iteracje na każdą literkę), bo to ma wtedy sens.

2. Jak mam wymaganie, że w układzie publish-subscribe jitter u każdego
odbiorcy ma być niezależny od awarii (zawieszenia, zgon, itp.) innych
odbiorców, to *nie* używam TDD ani w ogóle nie robię na to żadnego
testu. Tego typu wymagania można sensownie spełnić nie przez jakąś tam
refaktoryzację, tylko przez odpowiednią *konstrukcję*, czyli to ma
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.
Prawie zawsze działa, bo prawie zawsze mam dobrą konstrukcję, która
wynika z dobrego projektu na papierze.
Inne wymaganie, któro traktuję podobnie, to np. "ruch komunikatów ma
być płynny". Itd.
Jak ktoś chce pisać na to testy (albo nawet TDD), to będę za niego
trzymał kciuki.
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.

> >> Nie tylko unit testy można odpalać z automata. Można automatycznie
> >> testować całe systemy, nawet GUI.
>
> > Nie, nie można.
>
> 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*

2. w aplikacji typu sklep GUI ma *umacniać postrzeganie marki i
sprzyjać tzw. konwersji*, czyli kierować odwiedzającego w stronę
zakupów

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.

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

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