Istnieją poprawne refactory, które udają się bez żadnych testów - dowód

3

Temat nie ma nic wspólnego z mockami, więc nie wrzucam tam.

Twierdzenie: istnieją poprawne refactory, które udają się bez żadnych testów
Dowód:
Weźmy metodę, którą napisałem.

	public static IEnumerable<int> MyReverse(IEnumerable<int> enumerable)
	{
		if(!enumerable.Any()) return new List<int>();
		return MyReverse(enumerable.Skip(1)).Concat(enumerable.Take(1));
	}

metoda działa, ale gołym okiem widać, że da się to zrobić lepiej np. wykorzystując klasy biblioteczne, więc refactoruję.

	public static IEnumerable<int> MyReverse(IEnumerable<int> enumerable)
	{
		return enumerable.Reverse();
	}

Refactor zrobiony, nie napisałem ani jednego testu automatycznego, pierwsza i druga metoda działają zgodnie z założeniami. QED.


Nie chodzi tu wcale o to czy refactory bez testów są dobrym pomysłem, ale o to, że robienie prostytutki z logiki, bo nie odróżnia się kwantyfikatorów nigdy nie ma uzasadnienia.

Poza tym myślę, że wiele prostych helperów o skomplikowaniu podobnym do powyższego Reverse nie jest pokryta testami co nie przeszkadza w modyfikowaniu tych funkcji, bo ktoś postanowił jak powyżej użyć rozwiązania z biblioteki, a nie naklepanego na szybko z ręki.

CC: @1a2b3c4d5e @Seken

2

nie wiem czy jest sens kontynuować tamtą dyskusję, tam ewidentnie coś poszło nie tak

ale na przyszłość może komuś się przyda:


https://web.stanford.edu/class/cs246/handouts/CS246_Proof_Probability.pdf

Here we will learn to prove universal mathematical statements, like “the square of any odd
number is odd”. It’s easy enough to show that this is true in specific cases – for example,
3^2 = 9, which is an odd number, and 5^2 = 25, which is another odd number. However, to
prove the statement, we must show that it works for all odd numbers, which is hard because
you can’t try every single one of them.

Note that if we want to disprove a universal statement, we only need to find one counterex-
ample. For instance, if we want to disprove the statement “the square of any odd number is
even”, it suffices to provide a specific example of an odd number whose square is not even.
(For instance, 3^2 = 9, which is not an even number.)

Rule of thumb:

  • To prove a universal statement, you must show it works in all cases.
  • To disprove a universal statement, it suffices to find one counterexample.

(For “existence” statements, this is reversed. For example, if your statement is “there exists
at least one odd number whose square is odd, then proving the statement just requires saying
3^2 = 9, while disproving the statement would require showing that none of the odd numbers
have squares that are odd.)

2

Twierdzenie: istnieją poprawne refactory, które udają się bez żadnych testów

Niestety nie da się udowodnic że oprogramowanie działa, więc nie jesteś w stanie udowodnić że refaktor działa. Nie jestes w stanie wykazać że funkcja który sortuje tablice sortuje je dobrze, możesz co najwyżej wykazać że nie funkcja nie dziala.

0

@scibi_92:

szkoda tylko, że 99% kodu to nie jest kod sortujący tablicę która może mieć nieskończenie wiele elementów, a np 5 ifków.

i tu jak najbardziej da się obsłużyć wszystkie casy/branche.


Moja definicja działającego kodu jest taka, że jest to kod który po wrzuceniu na produkcje nigdy się nie wywali przez jakiś np. błąd logiczny, brak checka czy coś tego typu.

4
Saalin napisał(a):

Refactor zrobiony, nie napisałem ani jednego testu automatycznego, pierwsza i druga metoda działają zgodnie z założeniami. QED.

Ale działa zgodnie z założeniami na podstawie Twojego oświadczenia, tak? Bo żadnego dowodu na to jak nie było, tak nie ma.

1

@somekind

wystarczy że zastosujesz te same sposoby udowadniania które stosujesz na co dzień w pracy, to będzie "reasonably enough"

3

Teoretycznie w oprogramowaniu komputerowym da się przetestować wszystkie przypadki, bo ta tablica ma jakąś skończoną przestrzeń adresową, np. z definicji tego interface'u wynika, że nie da się z tablicy pobrać elementu z indeksem poza zakresem int'a. Ale oczywiście to przypadek kompletnie nie realny. Z drugiej strony znam też realne przypadki, gdzie testuje się całą dziedzinę funkcji i nie piszę tu o 5 if'ach.

@1a2b3c4d5e: Nie uzyskasz takiej gwarancji. Testy są tylko tak dobre jak przypadki testowe, które ktoś napisał. Nie tak dawny przypadek padu na produkcji: prosty kod, pokryty testami, przeszedł przez kilka środowisk testowych, deploy na produkcję i piękna wyj....ka. Autor nie przewidział, że jeden z parametrów przetwarzanych przy starcie usługi może być null'em.

@Salin:
To teraz wyobrażmy sobie że gdzieś tam jest kod:

List <int>unsortedList;

List<int> reversedList = MyReverse(unsortedList);  
List<int> sortedList = unsortedList.Sort();

//jakieś tam użycie reversedList i sortedList

Udowodniłem, że refaktor sie nie powódł? :D

Ps.
Gdybym dostawał tak 100zł za każdy przypadek kiedy słyszałem "patrzyłem w kod i tam nie ma błędu".

2

Drugi kod nie zwraca starej posortowanej listy tylko nową... To LINQ.

1

Szczerze to wolę oświecony pragmatyzm. W przypadku refaktorowania kodu bez testów to warto skrobnąć test nie dlatego, że "refaktor bez testów jest niebezpieczny", tylko dlatego, żeby ten test na przyszłość był - i tyle.

1

Specjalnie dla @somekind znalazłem program, którego poprawność umiemy (szybko) udowodnić!

Weźmy funkcję:

	public static bool Fun(bool a, bool b)
	{
		return (a || b) && (b || a);
	}

Ale ktoś następny przyszedł i stwierdził - "Co za debil nie wie, że lub jest przemienne", więc skórcił do:

	public static bool Fun(bool a, bool b)
	{
		return a || b;
	}

Formalny dowód, że funkcje są równoważne pozostawiam czytelnikowi, ale podpowiem, że wystarczą tabele prawdy. Jeszcze tylko musicie mi uwierzyć, że naprawdę nie pisałem do tych funkcji testów.

Edit.
Dla kompletności:

a b (a || b) (b || a) (a || b) && (b || a)
F F F F F
F T T T T
T F T T T
T T T T T

Metody są równoważne.

3

Załóżmy, że mamy kod bez testów, który nie działa. Jeżeli skasujemy go w całości (co również jest refaktorem), to również nie będzie działał (bo nie będzie istniał), a zatem stan projektu się nie zmienił, a zatem refaktor się udał mimo braku testów, QED.

1

to jak już idziemy w takie przykłady, to wrzucam oryginał:

public static string Test(int i, int b)
{
    if (i > 5 && b > 5)
    {
        return "result";
    }

    if (i > 5 && b <= 5)
    {
        return "wynik";
    }


    return "result";
}

refaktor:

public static string Test2(int i, int b)
{
    if (i > 5)
    {
        if (b > 5)
        {
            return "result";
        }
        else
        {
            return "wynik";
        }
    }
    else
    {
        return "result";
    }
}

i jak, da się bez testów wykazać że działa to tak samo, albo może i nie działa, czy się nie da?

podrzucam control flow graphy

screenshot-20220628223645.png

5
1a2b3c4d5e napisał(a):

@somekind

wystarczy że zastosujesz te same sposoby udowadniania które stosujesz na co dzień w pracy, to będzie "reasonably enough"

Nie stosuję w pracy żadnych sposobów udowadniania, nie zajmuję się dowodzeniem niczego w ogóle. Zamiast tego stosuję rozumowanie indukcyjne w oparciu o obserwacje i swoje doświadczenie.

Zaś osoby, które mylą twierdzenie z dowodem raczej nie powinny pouczać innych w tej materii. (To taka ogólna uwaga.)

To, że piszemy sobie jakiś testy naszego kodu, i te testy pozwalają nam stwierdzić, że dla pewnych danych wejściowych kod zwraca spodziewane wyniki, i na tej podstawie uznajemy, że kod jest OK, to nie jest dowodzenie. To po prostu nasze wniosek z obserwacji zapewne popartej doświadczeniem.

To, że ludzie działają w jakiś określony sposób (np. refaktoryzując kod niepokryty testami), to też nie jest żadne dowodzenie. To po prostu obserwacja (smutnej) rzeczywistości.

0

Teoretycznie wykonałeś testy manualne.

Ja bym powiedział, że jak sobie zasymulujemy pracę procesora jak debugger i prześledzimy kilka przykładów i napiszemy kod, to pewnie zadziała za pierwszym razem dla przypadków, które rozważaliśmy.
Manualnie sprawdzimy czy w miarę ok i puszczamy dalej.
Albo jednak opiszemy jakie przypadki, które rozważaliśmy podczas implementacji i zapiszemy w oddzielnym pliku jakoby to była historia tej funkcjonalności te testy.

Teraz napiszemy sobie funkcje, zrobimy czy nie te testy i później po kilku godzinach pisania ukończymy jakiś projekt i manualnie end to end testując zobaczymy, że coś się wykłada.
Prześledzimy w dół debuggerem i znajdziemy winowajcę, to dopiszemy tylko linijkę testu z tym przypadkiem i refaktor.
A jeśli nie ma testów, to co powodowało błąd, to jeśli my to implementowaliśmy to pół biedy, a jeśli ktoś inny to musimy jeszcze dopisać inne testy, żeby nie pominąć czegoś czego osoba co to implementowała o tym pomyślała.

Im bardziej złożona funkcjonalność tym więcej jakiś corner casów się znajdzie.
W wyobraźni można prześledzić, przejść nawet 30-50 węzłów grafu do 5-8 głębokości pamiętając do tego, które już się odwiedziło gałęzie i odtworzyć je wstecz retrograde analizą, np. bardzo dużo grając w szachy blindem.
Ale wyobraźnia się wymazuje bardzo szybko, jeden melanż alkoholowy, albo kilka dni/tygodni i te wszystkie wyobrażenia znikają i trzeba cały proces powtarzać, co jest męczące.
Czasem analizując czyiś kod i śledząc w głowie wykonanie, jest to i tak zbyt męczące, a z testami można teoretycznie od nowa cały kod napisać bez czytania z analizą poprzedniego.

3
1a2b3c4d5e napisał(a):

Rule of thumb:

  • To prove a universal statement, you must show it works in all cases.
  • To disprove a universal statement, it suffices to find one counterexample.

(For “existence” statements, this is reversed. For example, if your statement is “there exists
at least one odd number whose square is odd, then proving the statement just requires saying
3^2 = 9
, while disproving the statement would require showing that none of the odd numbers
have squares that are odd.)

nie wiem czy tytuł wątku się (w tzw. międzyczasie) zmienił, ale teraz jest taki: "Istnieją poprawne refactory, które udają się bez żadnych testów - dowód", czyli to jest "existence" statement, a nie universal statement

prawdopodobnie dokładnie o to chodziło @1a2b3c4d5e ale nie napisał tego wprost :)

2

Miałem znajomego na socjologii i zajęcia z logiki siały tam blady strach. Miał trochę pretensje do rzeczywistości, że każą mu się uczyć takich głupot kompletnie nie mających powiązania z rzeczywistością. Przecież w nauce umiejętność spójnego logicznie wnioskowania nie ma znaczenia.
Teraz na forum dla programistów, którzy tę logikę stosują na co dzień, toczą się takie dyskusje, a podstawowe pojęcia jak teza, antyteza, hipoteza, fakt są stosowane właściwie zamiennie i przypadkowo.

"Aplikacja działa" - teza
"Aplikacja nie działa" - antyteza

W większości przypadków tezy nie da się udowodnić testami automatycznymi, ręcznymi, patrzeniem w kod, bo trzeba by sprawdzić wszystkie jej przypadki użycia, na każdym środowisku gdzie ma działać. Prościej jest próbować udowodnić antytezę, czyli zdanie dokładnie przeciwne do tezy. Piszemy testy mające na celu wywalenie aplikacji. Jeżeli jeden z nich nie przejdzie, to aplikacja nie działa, ale nie da się zwykle "udowodnić", że aplikacja działa. Można to jedynie uprawdopodobnić faktem, że przeprowadzono wiele prób zaprzeczenia tezy i to się nie powiodło, ale tak długo jak nie udowodnimy, że przetestowane została cała dziedzina działania aplikacji, czyli wszystkie jej przypadki użycia dla wszystkich możliwych wartości parametrów to teza awansuje jedynie na hipotezę, no może teorię.

Analogicznie mamy Teorię Ewolucji - zbór hipotez, liczne próby jej zaprzeczenia, które się nie powiodły. To nie oznacza, że teoria jest prawdziwa, a jedynie że nie udało się udowodnić, że prawdziwa nie jest.

1
piotrpo napisał(a):

tak długo jak nie udowodnimy, że przetestowane została cała dziedzina działania aplikacji, czyli wszystkie jej przypadki użycia dla wszystkich możliwych wartości parametrów to teza awansuje jedynie na hipotezę, no może teorię.

Ale mamy: https://4programmers.net/Forum/Inzynieria_oprogramowania/361899-istnieja_poprawne_refactory_ktore_udaja_sie_bez_zadnych_testow_dowod?p=1853367#id1853367

Wszystkie przypadki użycia dla wszystkich wartości parametrów. Pytam się - czego jeszcze chcecie?

1

@Saalin: obie wersje są matematycznie równoważne i kompilator za nas i tak by to zoptymalizował do tej samej postaci.
Ale Nie wiadomo czy ten kod jest poprawy, bo co to za funkcja fun?

Może miało wykonać zupełnie coś innego, sama nazwa czasem nic nie wskazuje, a testy na podstawie funkcjonalności są napisane.
Czyli mówią trochę o tym jakie to ma zachowanie.

Logikę łatwo udowodnić, cały procesor jest tak zbudowany, chodź matematycznie liczba może pomieścić nieskończoną liczbę, a na komputerze mamy ograniczenie do wielkości rejestru.
W ogóle mamy różne implementacje liczb bazujące na logice, ale z różnymi ograniczeniami.

Matematycznie łatwo udowodnić, że a+b = b+a, lub exp(log(a) + log(b)) = a*b, ale jak dojdzie do integer overflow, błędów precyzji lub w ogóle jakiegoś innego błędu, które jakby powstają przez abstrahowaniu logiki do wyższych tworów.

0

@Saalin: Nie wiem dlaczego uważasz, że to komentarz twierdzący, że nie masz racji. Chociaż czysto "filozoficznie" można rozważać, czy spojrzenie w kod i stwierdzenie "powinno działać" może być uznane za "dowód", chociażby z tego powodu, że kod, to jeszcze nie aplikacja. CPU nie wykonuje kodu w C#, tylko kod maszynowy, który powstaje w wyniku iluś tam transformacji tego co napisałeś na to co procesor rozumie. Ale bez zagłębiania się w sofistykę, a bazując jedynie na własnych obserwacjach: da się wykonać refaktoryzację nie rozwalacjąc działania kodu.

1
Szalony Programista2 napisał(a):

@Saalin: obie wersje są matematycznie równoważne i kompilator za nas i tak by to zoptymalizował do tej samej postaci.
Ale Nie wiadomo czy ten kod jest poprawy, bo co to za funkcja fun?

Jakie błędy precyzji, integer overflow? Nie ma znaczenia po co jest funkcja Fun. Kod został zrefactorowany, robi to samo. Zaczynacie uprawiać tu logikę pokroju płaskoziemców, kiedy wprost widać, że coś działa (i to nie tylko widać, ale jest to ściśle poprawne) ale twierdzicie, że jednak nie do końca, bo nie wiadomo co coś robi, ani jak CPU działa, a to jakieś terminy nie są znane (bo co to znaczy refactor albo test?). Dla mnie EOT.

3
scibi_92 napisał(a):

Twierdzenie: istnieją poprawne refactory, które udają się bez żadnych testów

Niestety nie da się udowodnic że oprogramowanie działa, więc nie jesteś w stanie udowodnić że refaktor działa

Da się udowodnić, ale potrzebny jest do tego język programowania który pozwala pisać dowody np Kind. Tylko że taki dowód to test na sterydach, więc wracamy do punktu wyjścia że najlepiej mieć dowody (matematyczne) albo chociaż testy

Nie wiem czy zauważyłeś, ale temat nie dotyczy formalnej weryfikacji.

No to jak temat nie dotyczy formalnej weryfikacji to nie możesz zmieniać definicji dowodu według własnego uznania. Albo masz dowód, albo tylko poszlaki. IMHO Nawet testy jednostkowe to tylko poszlaki

0

Przeczytałem cały wątek i wydaje się, że w dyskusji jest problem definicji:

  • czy uznać, że zmienne w programie mogą zawierać jakąkolwiek wartość ich typu
  • czy uznać, że zmienne w programie są ograniczone działaniem samego programu i przyjmują tylko wybrane wartości

W pierwszym przypadku nie można udowodnić, że program działa poprawnie, ale wtedy nie całkiem to jest działanie programu, lecz jakiś błąd użycia lub sprzętowy. W drugim przypadku można by próbować udowadniać, że określone ścieżki wykonania są poprawne.
Wniosek z powyższego: program nigdy nie będzie poprawny dla wszystkich przypadków, jeśli stosować w nim abstrakcje (takie jak na przykład lista), ponieważ wtedy typy danych nie będą ograniczały do tylko możliwych wartości.

0
Saalin napisał(a):

Wszystkie przypadki użycia dla wszystkich wartości parametrów. Pytam się - czego jeszcze chcecie?

Jak sam widzisz, że aby udowodnić, że refaktor bez testów jest możliwy, musiałeś najpierw udowodnić, że obie funkcje działają. :) No i ja się zgadzam, jak masz dowód poprawności kodu, to nie potrzebujesz żadnych testów.
Pytanie dokąd nas ta wiedza prowadzi i jakie ma znaczenie w praktycznym życiu. :)
Bo pozostałe refaktory wykonane bez testów nie są w żaden sposób udowodnione. Po prostu autor zakłada, że się udały, bo jak na razie działają tak samo. I może mieć nawet rację, tylko nie ma dowodu.

A tak poza tym, to nie wiem o co chodzi, wydawało mi się, że ten wątek wyewoluował z innego, w którym padły takie stwierdzenia jak "testy jednostkowe dowodzą poprawności kodu" oraz "miliony programistów codziennie udowadniają, że refaktor bez testów jest możliwy". Ani jedna ani druga sytuacja nie ma nic wspólnego z dowodzeniem, bo to pierwsze to dowód anegdotyczny czyli błędna generalizacja, a to drugie to po prostu wykonywanie swojej pracy. (Ludzie, o których mowa nie zajmują się dowodzeniem, i nie chodzą do pracy z założeniem, że coś udowodnią.)

Tak więc jedyne, czego ja chcę, to odrobina inżynierskiego pragmatyzmu oraz nie przekręcania znaczenia słów. No i milion dolarów - skoro już pytasz. ;)

A tak BTW, to nie da się udowodnić istnienia milionów programistów, ani nawet jednego programisty. Ani Twojego czy mojego.

1

To jest niesamowite :D

O ile przyznam się, że rzucając Istnieją poprawne refactory, które udają się bez żadnych testów

miałem świadomość że to takie dyskutowanie bardziej teoretyczne niż praktyczne, to nie spodziewałem się że może być aż tak mocno kontrowersyjnym taka prosta definicja:

if your statement is “there existsat least one odd number whose square is odd, then proving the statement just requires saying 3^2 = 9

ale to jeszcze nic, bo gimnastykowanie się teraz że w sumie "nie wiadomo co to znaczy że program działa" (chociaż w pracy pewnie nie macie problemu z określeniem czy programik działa lub tez nie)

i że z jakiegoś powodu chcecie przepchnąć jakieś wręcz brednie rzucając skrajne przypadki typu algorytmu z nieskończonym inputem nie da się w kodzie udowodnić, które oczywiście nadal nic nie zmieniają, bo ja potrzebowałem tylko jednego przykładu który da się udowodnić że działa (dla was formalnie udowodnić, dla mnie w miarę rozsądku)

i były one dostarczone - chociażby refaktor return (a || b) && (b || a);

to nie potrafię zrozumieć, co was tak naprawdę boli?

To zapytam inaczej @somekind

Czy według ciebie nie ma firm, które klepią koda bez żadnych testów, wprowadzają w nim zmiany i o dziwo to działa? może nie za pierwszym razem, nie za drugim, ale po iluś tam fixach ten soft faktycznie działa?

Tu naprawdę nie potrzeba formalnych dowodów na to że kod działa, ale nawet jeśli tak bardzo chcesz, to można to wykazać na prostym kodzie (było wyżej), a refaktor takiego prostego kodu to nadal jest przykład który się kwalifikuje pod Istnieją poprawne refactory, które udają się bez żadnych testów, a zatem jest QED.

@piotrpo:

CPU nie wykonuje kodu w C#

super, to mamy przepisać te kody na asm? a może ograniczymy się tylko do jakiegoś prostego procesora, bo przecież te współczesne mają wiele różnych złożonych mechanizmów i głupio jakby to tam był bug

ale zastanówmy się - czy coś to zmieni w praktyce?

nie możemy udowadniać wszystkiego wychodząc od początku świata, bo nie jest to możliwe (czasowo/ekonomicznie), niektóre rzeczy trzeba przyjąć za już udowodnione.

btw. a co z refaktorowaniem pseudokodu?

5
1a2b3c4d5e napisał(a):

miałem świadomość że to takie dyskutowanie bardziej teoretyczne niż praktyczne, to nie spodziewałem się że może być aż tak mocno kontrowersyjnym taka prosta definicja:

if your statement is “there existsat least one odd number whose square is odd, then proving the statement just requires saying 3^2 = 9

ale to jeszcze nic, bo gimnastykowanie się teraz że w sumie "nie wiadomo co to znaczy że program działa" (chociaż w pracy pewnie nie macie problemu z określeniem czy programik działa lub tez nie)

i że z jakiegoś powodu chcecie przepchnąć jakieś wręcz brednie rzucając skrajne przypadki typu algorytmu z nieskończonym inputem nie da się w kodzie udowodnić, które oczywiście nadal nic nie zmieniają, bo ja potrzebowałem tylko jednego przykładu który da się udowodnić że działa (dla was formalnie udowodnić, dla mnie w miarę rozsądku)

ale to Ty dzwonisz.....znaczy kawałek wyżej rzucasz przykładową formalną definicję a dziwisz się że o dowodzeniu że program działa chcemy też rozmawiać bardziej formalnie

co najlepsze ja nie jestem za testami
jestem za kulturą dyskusji

0

@Miang

Wrzuciłem ją z tego względu że "some people" za nic nie chcieli się dać przekonać że coś takiego istnieje i przykłady nie wystarczyły, no to chyba nie miałem wyjścia?

I zresztą jaką formalną definicją wrzucam, tutaj jest proste wytłumaczenie tego konceptu dla studentów.


To zapytam jeszcze inaczej

Jaka jest wartość z przyjęcia waszego podejścia do uznawania "czy program działa", jeżeli przez całą waszą karierę nie bylibyście w stanie uznać że program działa (bo nikt by wam takiego budżetu nie przydzielił aby to sprawdzić), a jednak przez całą karierę będziecie pisać soft, który przez prawie cały czas jego istnienia będzie działał

No nie ma żadnej wartości.

3

@1a2b3c4d5e: Udowadniaj co chcesz, mi nic do tego. Nie mniej - jeżeli chcesz "udowodnić, że aplikacja działa", albo "udowodnić, ze aplikacja nie działa", to przyda się mieć jasną wizję tego, co to "działanie" oznacza. Kod jest poprawny, kompiluje się, może startuje, czy działanie jest zgodne z oczekiwanym. Jeżeli chodzi o poprawność kodu, to jasne, można sobie go w oparciu o dokumentację (załóżmy że jest pozbawiona błędów), zasady logiki, matematykę itd. zweryfikować i stwierdzić, że nie widać w nim błędów. Można też założyć, ze kompilator nie ma błędów (a były i to dość oczywiste "optymalizacje"), które potrafiły napsuć krwi, bo jakiś fragment kodu wg. kompilatora działał inaczej, niż według programisty (i to kompilator się mylił).
No i wreszcie fragment perełka: Czy według ciebie nie ma firm, które klepią koda bez żadnych testów, wprowadzają w nim zmiany i o dziwo to działa? Skąd wiadomo, że działa jeżeli nikt tego nie przetestował? Nie piszę tu o testach automatycznych, ale takim najzwyklejszym tester wziął, odpalił, przetestował.

0

@piotrpo:

Nie mniej - jeżeli chcesz "udowodnić, że aplikacja działa", albo "udowodnić, ze aplikacja nie działa", to przyda się mieć jasną wizję tego, co to "działanie" oznacza

Ja na samym początku tego wątku napisałem

Moja definicja działającego kodu jest taka, że jest to kod który po wrzuceniu na produkcje nigdy się nie wywali przez jakiś np. błąd logiczny, brak checka czy coś tego typu.

I jest to chyba dość rozsądne, czyż nie? no przecież nie będę brał pod uwagę promieniowania kosmicznego itd.

Skąd wiadomo, że działa jeżeli nikt tego nie przetestował? Nie piszę tu o testach automatycznych, ale takim najzwyklejszym tester wziął, odpalił, przetestował.

W oryginale wychodziliśmy od testów typu unit, e2e, etc. wyszło to z wątku o Mockach.

Aczkolwiek point still stands, bo wystarczy że ktoś doda kilka printów z logami do kodu i od razu wrzuci to na proda bez odpalenia i już mam taki przykład. Ja na pewno tak zrobiłem i nie sądzę abym był jedynym ;)

W ogóle co z kodem który da się odpalić tylko na prodzie? może jakaś maszyna/robot?

3

@1a2b3c4d5e: Według mnie (i o ile rozumiem @Miang ) Mieszasz tutaj 2 kompletnie różne perspektywy. Jeżeli mówimy o stronie praktycznej, to tak, robi się zmiany na prodzie "ad-hoc", nawet, bywa. Bo np. nie ma środowiska testowego.
Druga perspektywa, od której zacząłeś wątek, to logika formalna i wnioskowanie. I jeżeli rozmawiamy z tej perspektywy, to słowa definicje "działania", "udowodnienia", "zaprzeczenia" są bardzo istotne. To co piszesz jest mix'em tych 2 perspektyw i wychodzi "zmieniłem kod i działa, koń jaki jest każdy widzi".

A odnośnie twojej "definicji działania", to nie jest tak prosto, bo może oznaczać, że np. usługa sie podniesie, będzie działać jak wcześniej, będzie działać jak wczesniej i będzie odporna na wyciągnięcie wtyczki zasilania z serwera baz danych. I ogólnie tak, masz rację - da się zmienić kod, nie odpalić go, wrzucić na prod'a i przy jakiejś dozie szczęścia (zależnej od zakresu zmiany) zadziała i się nie wyrypie.

0

@piotrpo:

Mieszasz tutaj 2 kompletnie różne perspektywy.

Ja bym jeszcze inaczej to napisał

Ja i @Saalin piszemy że jeżeli ktoś wykona dobrze jeden refaktor bez testów, to udowadnia że się da.

a @somekind i @Seken skupili się na tym, że nie da się udowodnić że program działa

I teraz, o ile to pierwsze już chyba ustaliliśmy że ma sens (1 post), to druga kwestia jest po prostu lekko dyskusyjna, ale jest to coś osobnego.

Ja mam mniej wymagające podejście do udowadniania czy program działa, a zatem dla mnie miliony devów codziennie udowadniają że się da ;)

1 użytkowników online, w tym zalogowanych: 0, gości: 1