Po co testy jak można przeklikać

Szalony Programista napisał(a):

Testy służą dowodzeniu, że dane funkcjonalności działają w zamierzony sposób i jest to równoznaczne matematycznemu dowodzeniu twierdzeń.

Nie, typowe testy nie są równoważne dowodom matematycznych twierdzeń. Typowe testy są równoważne np. sprawdzeniu, że hipoteza Riemanna jest prawdziwa dla X przetestowanych nietrywialnych zer funkcji dzeta, ale bez dowodu, że jest prawdziwa dla wszystkich.

Do formalnego dowodzenia poprawności oprogramowania służą programy typu https://en.wikipedia.org/wiki/Coq a przykładem na oprogramowanie z formalnym dowodem poprawności jest https://en.wikipedia.org/wiki/L4_microkernel_family#High_assurance:_seL4

Testy służą dowodzeniu, że dane funkcjonalności działają w zamierzony sposób i jest to równoznaczne matematycznemu dowodzeniu twierdzeń.

Nie zgodzę się że testy są dowodami, nawet jeśli są są dobrze napisane - większość testów to próbkowanie przestrzeni problemu z uwagi na to że ta przestrzeń jest wielka (weźmy pod uwagę chociażby głupie mnożenie dwóch liczb zmiennoprzecinkowych)

Gdy programowanie jest dla biznesu to nie ma mowy o "udowadnianiu".
W matematyce Newton i Leibniz położyli podwaliny na których opiera się wiedza matematyczna 17, 18, 19, 20, 21 wieku.
"Modele" biznesowe z czasów Potopu Szwedzkiego, Newtona, Leibniza? Biznes ciągle ewoluuje, biznes przed i po krachu Lehman, przed i po COVID.
Nie stworzy się modelu i nie udowodni jego poprawności dla biznesu z sukcesem działającego 20 lat, bo on się zmienia.
Jakby biznes i testy opisujące biznes (przełożone na software) były dowodem, to musiałyby być niezmienne i niepodważalne przez cały czas.

Jednak dzięki temu, że "pewne jest tylko że nic nie jest pewne" to pracy dla programistów nie brakuje ;)

Właśnie, po co testy piszecie.

Przestańcie, to wtedy będą mogli pisać w artykułach, że na rynku nie brakuje 50 tys programistów, a 500 tysięcy!

urke napisał(a):

Właśnie, po co testy piszecie.

Między innymi dla siebie, żeby mieć spokój, że co działało i spełniło wymagania testów, to po zmianach dalej spełnia. A mogłem coś przeoczyć.

Nie czytałem całego flame więc odniosę się jedynie do pytania postawionego w wątku:

Gdyby mi płacili od godziny to moze bym klikał, ale nie płacą :)

Dlatego wolę sobie przeklikać szybciej niż wolniej. W związku z tym sprytnie postanowiłem klikanie zautomatyzować - bo przecież mogę sobie skryptem wysłać taki sam request HTTP jaki wysłałaby moja przeglądarka. Idąc dalej, mogę też skryptem sprawdzić czy odpowiedź z serwera zawiera to czego się spodziewam, nie muszę koniecznie "patrzeć" na to. No i to klikanie konkretnych funkcji zawsze przebiega tak samo, więc napisałem sobie te skrypty raz i teraz mogę je uruchomić jeden po drugim.
Te skrypty nazywają się właśnie testami. Dzięki nim mogę przeklikać wszystkie funkcje systemu w 10s zamiast 10h.

A wiara w to że robiąc coś przy kodzie na 100% nie popsuje czegoś "w innym miejscu" to marzenie ściętej głowy i może się udać tylko jak projekt jest mały i jesteśmy jedynym developerem i znamy na pamięć wszystkie zależności między elementami systemu. W zwykłej pracy taka sytuacja w zasadzie nie ma miejsca.

Przeczytałem "przeklinać" i się nawet zgadza

nobody01 napisał(a):

Po co komu testy jak można przeklikać po wprowadzeniu zmian. Dobry programista potrafi sprawdzić, czy kod, który dodał, nie psuje niczego w systemie. /s

Jakie kontrargumenty byście dali w takiej sytuacji....?

Im bardziej mozolne jest sprawdzanie czy się czegoś nie popsuło (bo trzeba ręcznie przeklikać, bo testy są ale powolne, bo setup środowiska do testów jest upierdliwy) tym mniejsza motywacja, by często sprawdzać czy się nie popsuło. Innymi słowy - tym większa motywacja, by sprawdzać jak najrzadziej.

Im mniejsza motywacja by sprawdzać często, tym większe zmiany sprawdza się za każdym razem.

Im większą zmianę wprowadziłem i coś nią zepsułem, tym trudniej będzie mi ustalić co dokładnie spowodowało, że coś się popsuło i nie było mnie słychać i tym dłużej będę poprawiał.

Co gorsza, jak nie ma testów tylko przeklikuję się przez aplikację na oko i tylko patrzę czy działa, to mogę w ogóle nie wyłapać wprowadzonego błędu (szczególnie w przypadku błędów w innym miejscu, nieprzewidzianych przypadków szczególnych itp).

A jak ja nie wyłapię, to 2 dni później wyłapie to tester-klikacz który nabawił się już OCD od tego klikania albo jeszcze później klient i wtedy dopiero będzie wielkie szukanie przyczyn, szukanie winnych i tydzień zejdzie na ustaleniu kiedy i gdzie znalazła się ta niedobra zmiana, którą można było od razu złapać w testach :)

Skoro już mowa o przeklikiwaniu oprogramowania, a ono nie ma gui, to takie gcc, ma testów na 4 godziny przy 4 rdzeniach :>

Jak takie coś przeklilkać gdy to nie ma gui.

"Biznes" stwierdził kiedyś że nie mogę napisać testów integracyjnych które wyceniłem na jakieś 2 dni roboty (może nawet przeszacowałem). Nie były one zbyt skomplikowane, jednak to api integrowało ze sobą bardzo różne elementy systemu. Efektem tego była potrzeba testowania całego api za każdym razem, nawet jeśli zmiany nie dotykały reguł biznesowych. Testerzy płakali jak testowali (bo nie było to ani przyjemne ani szybkie) a biznes się wciąż cieszył z zaoszczędzonych pieniędzy. Wyszło im to bokiem (jak za każdym razem) bo programistów było wielu (można było jednego oddelegować do napisania testów) a tester jeden i zarzucony robotą na +3 miesiące

Szalony Programista napisał(a):

Testy służą dowodzeniu, że dane funkcjonalności działają w zamierzony sposób i jest to równoznaczne matematycznemu dowodzeniu twierdzeń.

Nie, nie, nie jest to równoznaczne! -- jestem fanem testów, ale testy służą dowodzeniu, że coś NIE działa. Są matematyczne metody formalnego dowodzenia poprawności algorytmów/programów, ale (poza opracowywaniem nowych elementarnych algorytmów) nikt tego nie robi.

Test może Ci pokazać, że coś nie działa. A jak testy przeszły na zielono, to znaczy, że działa to, co testowałeś dla przypadków, które przetestowałeś -- a reszta nadal jest nieznana.

To tak jak w matematyce -- przez przykład możesz obalić twierdzenie, ale nie udowodnić...

koszalek-opalek napisał(a):

To tak jak w matematyce -- przez przykład możesz obalić twierdzenie, ale nie udowodnić...

Nie, bo w matematyce obaliłeś twierdzenie i na tym koniec.
A testy masz w cyklu red, green, refactor aż do osiągnięcia [... TU wpisać o co walczymy...] (można długo dyskutować konkretnie co chcemy osiągnąć i na jakim poziomie werdykt: cel osiągnięto)

@Szalony Programista:

Doskonały test właśnie tak powinien wyglądać, w pełni go udowadniać, pewnych problemów nie da się tak łatwo rozwiązać.

Exhaustive testing is impossible - podstawowa zasada teorii testowania oprogramowania (https://github.com/elenastef/proj01/blob/master/Foundations%20of%20software%20testing%20-%20ISTQB%20Certification%20book.pdf, str. 10). Każdy programista, zwłaszcza szalony, powinien się z nią choć pobieżnie zapoznać.

Trzeba pamiętać, że testowanie ma charakter dyskretny, a dowodzenie - ciągły.

BraVolt napisał(a):

koszalek-opalek napisał(a):

To tak jak w matematyce -- przez przykład możesz obalić twierdzenie, ale nie udowodnić...

Nie, bo w matematyce obaliłeś twierdzenie i na tym koniec.
A testy masz w cyklu red, green, refactor aż do osiągnięcia [... TU wpisać o co walczymy...] (można długo dyskutować konkretnie co chcemy osiągnąć i na jakim poziomie werdykt: cel osiągnięto)

No właśnie dokładnie jak w matematyce -- twierdzenie obalone, więc musisz zmienić twierdzenie. Tutaj też: test nie przechodzi, to musisz zmienić kod. :)