W dniu piątek, 27 marca 2015 16:00:39 UTC+1 użytkownik g...@g...com napisał:

> Mnie się zdaje, że to w ogólności jest "cieńka" metoda. Tym bardziej,
> że wielu ideologów pisania testów mówią, że "im więcej, tym lepiej"
> i że "testy nie muszą być elegancko napisane" -- problem jest taki,
> że testy również potrafią czynić pewne założenia, które nie są kluczowe
> z perspektywy projektu, a których zmiana w projekcie sprawi, że słita
> testowa stanie się bezużyteczna.

Tak. I na tej podstawie można też podważyć stosowanie takich artefaktów do testowania
regresji. Może być tak, że po zmianie w implementacji i wprowadzeniu do niej bugów
stary test nadal będzie przechodził, bo nie testuje nowo powstałych osobliwości.

Testów nie da się pisać na masę, chyba że ktoś chce uprawiać poprawność tzw.
statystyczną. To też ma jakąś wartość, ale trzeba wiedzieć, gdzie.

> A co jeśli ktoś napisze zły test i złą implementację? Taki sam klops.

I te rzeczy były pisane przez niezależnych wykonawców? To wtedy prawdopodobieństwo
znalezienia niezgodności jest bardzo wysokie i wiadomo, że co najmniej jedno z dwóch
jest zwalone. Tej efektywności nie ma gdy się robi jedno z drugiego (tu z pogardą
spoglądamy również na TDD).

Podobno w praktyce wychodzi 50-50, więc tym bardziej nie należy traktować jednego z
tych artefaktów jako nadrzędnego.

> Jednak artykuł w gruncie rzeczy nie opisywał tego, o czym mówił
> ten nagłówek, tylko po prostu pewną odmianę programowania
> deklaratywnego opartą o microsoftowy system.

Jasne. W takim kontekście jest to bardzo ciekawe. Szkoda tylko, że niepraktyczne.

> Tzn. generowanie testów z implementacji rzeczywiście brzmi idiotycznie.
> Jednak w drugą stronę to nie całkiem zachodzi. Jeżeli mamy system, który
> na podstawie testów potrafi wygenerować sensowną implementację, to szacun.

Szacun dla systemu. Ale nadal niepraktyczne.

Taki system zmusza autora testu do takiego sformułowania testu, żeby z jego formuły
wynikała kompletna implementacja. Tzn. albo test musi być wyczerpujący albo musi być
tak skonstruowany, żeby *nie dało się* z niego zrobić niekompletnej implementacji.
Np. napisz test, który sprawdza funkcję sort - ale napisz go tak, żeby po
wygenerowaniu implementacji z tego testu, każdy inny test też przechodził.
I jeszcze udowodnij, że tak jest.

Wysiłek intelektualny z tym związany jest porównywalny z napisaniem tej funkcji. I
udowodnienia, że jest poprawna.

To jest jak ze ściskaniem plasteliny w dłoni - po prostu wylezie z innej strony a jej
objętość się nie zmniejszy.

> Ja jednak będę trwał na stanowisku, że testy są z założenia niekompletne,
> bo obejmują pewne przypadki jednostkowe.

Mogą obejmować wszystkie klasy równoważności (albo w ogóle być wyczerpujące w sensie
przestrzeni wejść). Ale znalezienie wszystkich klas równoważności jest tak samo
trudne, jak dowód z pominięciem testów. A testy wyczerpujące to tylko dla
najprostszych funkcji logicznych można napisać przed zejściem.

> I testy jako takie mają pewną
> wartość.

Tak. Oraz cenę.

> I owszem, zgodzę się, że fajniej jest mieć dowody poprawności, kiedy
> tylko się da (choć nie wiem, czy akurat w logice Hoare'a), ale jedno
> nie wyklucza drugiego. Tak jak fajnie np. w podręczniku do matematyki
> mieć nie tylko definicje, twierdzenia i dowody, ale również przykłady.

Tak. Ale dowodem można uzasadnić zmniejszenie ilości testów. Tak jak w książce do
matematyki nie trzeba podawać wyczerpujacych przykładów, wystarczy podać te
ilustracyjne. Wtedy książka może mieć mniej kartek i może być tańsza.

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