ACMM-033 napisało:

>>> Drogi Kolego, testowanie moze wykazac OBECNOSC bledow, nigdy zas nie
>>> moze wykazac NIEOBECNOSCI bledow.
>>
>> A mamyż jaką inną drogę, ponad testować, testować i jeszcze raz testować?
>> O praktykę pytam, nie o teorię.
>
> Przetestujesz milion razy, puścisz w świat, a tu nagle u mr Jima
> wypierniczy jakieś runtime, czy inne general. I zgaduj, czy to
> błąd kodu programu, czy jednak kompilatora?

Albo li też biblioteki. W ogóle dzisiaj to tak się porobiło, że przez
"napisanie programu" rozumie się wywoływanie bibliotecznych funkcji do
malowania na ekranie ramek, okienek, przycisków czy innych dupereli.
A z rzeczy niebibliotecznych, to może być dodawanie, mnożenie i dzielenie
kilku liczb -- co w sumie ma dać na przykład "aplikację do wypełniania
zeznania PIT". I tu zwykle zaczynają się nieporozumienia co do tego, co
oznacza "bezbłędny program". Bo te "aplikacje", fakt, zwykle działają
albo nie -- i nikt nie jest w stanie przewidzieć, która z możliwości
zajdzie gdy akurat zbliża się ostatni dzień kwietnia.

Ja do rzeczy podchodzę bardziej oldskulowo. Hołduję takim przesądom
światło ćmiącym, jak na przykład "warunek stopu". Że niby każdy porządny
program po uruchomieniu powinien się sam zatrzymać. Im szybciej, tym
lepiej. Co jest warunkiem koniecznym, choć nie wystarczającym, by orzec,
że program jest bezbłędny. Wiem, że w tym momencie oponentnowi zaczyna
się malować na twarzy taki wyraz, jakby chciał powiedzieć "co żeż pan
mi tu za farmazony prawi, program mam się sam zatrzymać?! toż on w takim
razie na pewno jest zapluskwiony jak materac w hotelu robotniczym! pewnie
to jakiś darmowy program -- trzeba kupowac porządne, za pieniądze, te się
same nie zatrzymują nigdy".

Jarek

--
Jimmy opowiedz jeszcze coś...
Będzie lało...
-- Już mówiłeś!
Będzie lało...
-- Czy dziś piłeś?!