W dniu 07.10.2019 o 19:50, heby pisze:
> On 07/10/2019 00:50, J-23 wrote:
>> Jak byś przeczytał ze zrozumieniem to co napisałem w postach o
>> Lazarusie byś nie prosił o to by Ci ktoś wskazywał błąd w rozumowaniu.
>> Dlaczego? Dlatego że znał byś odpowiedz na to pytanie.
>
> Czas kończyć J-23. Dyskucja sprowadza się do bredzenia co ktoś kiedyś
> tam powiedział i jak bardzo tego ktoś inny nie zrozumiał bo miał coś
> innego na myśli niż tamten chciał żeby miał na myśli. Trudno, trolling
> depleted, dalej już tylko pozostał argument sketch a to już lepiej w
> oryginale obejrzeć.
Tutaj się z tobą zgadzam czas kończyć, bo i tak nie zrozumiesz :)
Chociaż odpowiedź na powyższe pytanie znajdziesz w moich postach i to
wielokrotnie.

Pozdrawiam

do góry

On 2019-10-06 23:21, Maciej Sobczak wrote:
> Ale w projekcie krytycznym używa się jednego kompilatora. I testuje się kod
produkcyjny.

Tak naprawde w projekcie (niekoniecznie tylko krytycznym - ot zwyklym)
powinien byc _nakaz_ (i z reguly jest/byl - przynajmniej w "moich
czasach") uzywania tylko jednego tego samego (co do scislej wersji)
kompilatora.
_Wlasnie ze wzgledu na wieksze bezpieczenstwo_.

PS: Inna sprawa to dobor "wlasciwego" kompilatora.
Powinien byc dokonany przez rozpoczeciem projektu
(zapisany w env. requirements), a potem non stop weryfikowany
- oczywiscie do pewnego etapu/momentu - zwlaszcza dla badziewi
typu C/C++ - Borlanda, VC++ czy szczegolnie gcc.

AK

do góry

On 2019-10-06 14:02, heby wrote:
> Jak byś był w stanie zdradzić sekret.

To takie proste.
Zachowuj sie tak jakbys _mial_ Ojca w AK :). To starczy.
Albo wzoruj sie na kims (wlasnie z AK - jeszcze zyją).

PS: Kilka lat temu powstal termin/pomysl: "Nowe AK".
Wlasnie z mysla o Was mlodych.
AK to "stan umyslu/duszy" a nie "przynaleznosc".

Niestety reszta Twego postu swiadczy o Twej skrajnej glupocie
i chamstwie. To Cie wyklucza z (nowego czy "starego") AK:(

AK

do góry

On 2019-10-06 11:30, heby wrote:
> On 06/10/2019 08:54, AK wrote:
>>> Jeśli dowolny element badanego kodu nie jest znany na etapie jego
>>> unittestowania to mamy do czynienia z testami nie unit tylko
>>> *jakimiś*, najczęsciej integracyjnymi.
>> Tu juz pojechales :)
>
> Wskaz bład w twierdzeniu że testowanie kodu którego nie znamy w całości
> za pomocą unit testów nie jest unit testowaniem.
>
>> Zwyczajnie pieprzysz.
>
> To wymaga podania argumentu inaczej to jest zwykłe pieprzenie.
>
>> PS: Moze bys wpierw przetestowal blech-a co?
>
> A co to jest blech?

buz()

Pajacu, moze bys tak wpierw przetestowal (unitestowo jak najbardziej)
ten buz, zgdomadzil maksymalnie (bo wiadomo ze calej "dziedziny"
nie pokryjesz, a wazne, zeby to byly miejsca "charakterystyczne" np.
blisko koncow przedzialu, jakies inne punkty charakterystyczne)
miarodajne dane (czyli wyniki buz() z przykladowego zakresu/zakresow).

Te dane przyjmij jako input do faktycznych danych "expected" fun()a.
Oblicz wiec dla przetestowanych unitestowo w buz() przedzialow
(sprawdzona metoda realizujaca to co robi fun() /czyli np.
policz te sumy na kartce;) a co!:) odpowiednie sumy i uzyj ich
po prostu (jako wartosci oczekowane) w unitestach dla fun().

PS: Wiec zwyczajnie z tymi testami integracyjnymi pojechales.
Jesli tak (hm... nie mamy _na patelni_ wartosci oczekiwanych to..
olewamy unittesty.... a co ! przecie w "integracyjnych" wyjdzie)
to moge stwierdzic tylko jedno. Przedszkole, a nie testowanie :(

AK

do góry

> > To wychodzi w pokryciu kodu obiektowego.
>
> Najpierw musisz znaleźć metodę testowania która zawiera dostatecznie
> dużo przypadków.

Dalej nie kapujesz. Najpierw mam metodę mierzenia pokrycia. A potem, jeśli testy nie
dają wystarczającego pokrycia, szukam dziury. To nie musi być dziura w testach. To
może być dziura w kompilatorze. Czyli nie chodzi o to, żeby coś pokryć dużą liczbą
testów, tylko żeby mieć świadomość, czemu coś nie jest pokryte. To znaczy, że nie
muszę mieć jakiejś specjalnej metody testowania, żeby taką świadomość uzyskać a w
omawianym przykładzie wcale nie trzeba mieć "dostatecznie dużo przypadków".

> Ależ happens. Na ten przykład popularną metodą testowania kodu
> krytycznego, ale naprawdę krytycznego,

Łoł, ale tak naprawdę-naprawdę krytycznego, czy tylko naprawdę krytycznego?
Bo w tej dyskusji wspinasz się sięgając po coraż wyższe autorytety. Ostatnio było
nawet o rozmowie z człowiekiem mającym kontakt z brażną lotniczą...

> jest psucie go w czasie
> rzeczywistym i patrzenie gdzie i co wybuchnie analizując czy jest czy
> nie podatny na uszkodzenia.

I nadal nie ma potrzeby używać wielu kompilatorów. Skup się.

> No ale jednak happens.

No ale jednak nie pokazałeś żadnego przekonywującego przykładu.

> Inaczej: akurat w tej branży testuje się kilkoma innymi metodami
> również.

I właśnie dlatego nie potrzeba wielu kompilatorów. Do tego wniosku asymptotycznie
zmierzamy.

> > Dlatego ten pomysł byłby potraktowany jako koszt bez wartości dodanej.
>
> Nie "byłby" tylko jest stosowany. Może bardziej w HDLu ale w normalnym
> programowaniu też.

Rozumiem. Czyli jeśli nie udało się wykazać sensowności użycia wielu kompilatorów, to
trzeba napisać "bardziej w HDLu" a potem dodać "ale tu też". I jest szansa, że
przypadkowy czytelnik dostrzeże w tym wartościową wypowiedź.

> Różnie bywa. Taka ciekawostka: weryfikację narzędzia robi się czasem na
> słowo honoru: "działa od dziesięciu lat i nie ma problemu". Serio mówie.

To się nazywa Previously Developed Software. Tak. Ale to nie jest słowo honoru, bo
historię użycia trzeba mieć udokumentowaną i trzeba wykazać w jakim stopniu nowe
użycia pokrywają się ze starymi. Nie ma w tym nic nieracjonalnego.

> Musisz zagwarantować że twój pewny kompilator jest pewny dla kodu
> którego jeszcze nie ma.

Jest dokładnie odwrotnie (czyli jak już pisałem, mylisz pojęcia).
Uważaj:

"Upon successful completion of verification of the software product, the compiler is
considered acceptable for that product."

"Although the compiler is considered acceptable once all of the verification
objectives are satisfied, the compiler is only considered acceptable for that product
and not necessarily for other products."

Czyli o tym, że kompilator *był* dobry wiadomo dopiero jak się nim zrobi produkt.
Natomiast nie zakłada się, że *będzie* dobry, zanim się tego produktu nie zrobi. Bo
proces jest tak ustawiony, że wcale na tym założeniu nie polega.

Zapytaj kolegę od samolotów, skąd są te cytaty.

> Albo z miejsca gdzie siedzę widać coś innego niż z Twojego.

Na to wygląda. Ale też dlatego nie mam zamiaru się w nieskończoność szarpać.

[...]

> Nikt nie naciska na kilka kompilatorów.

Hura!

> Ale kilku wielkich graczy
> zdecydowało się na to.

"Pewni ludzie", "niektórzy", "chodzą głosy", "ktoś mi opowiadał", itp...

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

do góry

> Tak naprawde w projekcie (niekoniecznie tylko krytycznym - ot zwyklym)
> powinien byc _nakaz_ (i z reguly jest/byl - przynajmniej w "moich
> czasach") uzywania tylko jednego tego samego (co do scislej wersji)
> kompilatora.

Tak. Nie tylko co do wersji, ale również co do użytych opcji kompilacji.

Dlatego problematyczne jest poleganie na różnych ficzerach diagnostycznych
przełączanych opcjami. Paradoksalnie, im wyższy rygor, tym mniejsza swoboda, również
w tym zakresie.

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

do góry

On 2019-10-08 09:34, Maciej Sobczak wrote:
>> Tak naprawde w projekcie (niekoniecznie tylko krytycznym - ot zwyklym)
>> powinien byc _nakaz_ (i z reguly jest/byl - przynajmniej w "moich
>> czasach") uzywania tylko jednego tego samego (co do scislej wersji)
>> kompilatora.
>
> Tak. Nie tylko co do wersji, ale również co do użytych opcji kompilacji.

Dokładnie!

AK

do góry

On 08/10/2019 09:28, Maciej Sobczak wrote:
>> Najpierw musisz znaleźć metodę testowania która zawiera dostatecznie
>> dużo przypadków.
> Dalej nie kapujesz. Najpierw mam metodę mierzenia pokrycia. A potem, jeśli testy
nie dają wystarczającego pokrycia, szukam dziury.

Cały czas mówisz o tym jak znaleźć problem na testach. Niestety testy
nie latają.

> To nie musi być dziura w testach. To może być dziura w kompilatorze. Czyli nie
chodzi o to, żeby coś pokryć dużą liczbą testów, tylko żeby mieć świadomość, czemu
coś nie jest pokryte. To znaczy, że nie muszę mieć jakiejś specjalnej metody
testowania, żeby taką świadomość uzyskać a w omawianym przykładzie wcale nie trzeba
mieć "dostatecznie dużo przypadków".

Trzeba znaleźć dziurę w kompilatorze. Dziura nie została znaleziona
perfekcyjnymi testami *MOJEGO* kodu choć ujawniła się w MOIM kodzie na
produkcji. Samolot spada.

>> Ależ happens. Na ten przykład popularną metodą testowania kodu
>> krytycznego, ale naprawdę krytycznego,
> Łoł, ale tak naprawdę-naprawdę krytycznego, czy tylko naprawdę krytycznego?

Naprawdę naprawdę.

> Bo w tej dyskusji wspinasz się sięgając po coraż wyższe autorytety. Ostatnio było
nawet o rozmowie z człowiekiem mającym kontakt z brażną lotniczą...

No i? Myślisz że opowieści wyssałem z palca?

>> jest psucie go w czasie
>> rzeczywistym i patrzenie gdzie i co wybuchnie analizując czy jest czy
>> nie podatny na uszkodzenia.
> I nadal nie ma potrzeby używać wielu kompilatorów. Skup się.

Pokazuje to jak ważna jest statystyka kiedy wyczerpiesz metody ścisłe.

>> No ale jednak happens.
> No ale jednak nie pokazałeś żadnego przekonywującego przykładu.

Podobnie jak administrator sieci nie potrafi pokazać żadnego
przekonywującego przykładu że jest potrzebny.

>> Inaczej: akurat w tej branży testuje się kilkoma innymi metodami
>> również.
> I właśnie dlatego nie potrzeba wielu kompilatorów. Do tego wniosku asymptotycznie
zmierzamy.

Nie, kiedy już wyczerpiesz zasoby ścisłe pojawia się statystyka. Analiza
randoiczna testów, upewnianie się co do kodu w różnych narzędziach itd itp.

>> Nie "byłby" tylko jest stosowany. Może bardziej w HDLu ale w normalnym
>> programowaniu też.
> Rozumiem. Czyli jeśli nie udało się wykazać sensowności użycia wielu kompilatorów

Ją się już dawno udało wykazać, tylko ciągle WYDAJE ci się że jak
sprawdziłeś kod metodami testującymi takimi a siakimi to nagle wszelakie
nieznane i znane bledy w kompilatorze masz pod kontrolą. Nie masz.

>, to trzeba napisać "bardziej w HDLu" a potem dodać "ale tu też". I jest szansa, że
przypadkowy czytelnik dostrzeże w tym wartościową wypowiedź.

Podobnie jak w bredzeniu że ktoś bredzi. HDL akurat ma testowanie
rozwięte do granic absurdu.

>> Różnie bywa. Taka ciekawostka: weryfikację narzędzia robi się czasem na
>> słowo honoru: "działa od dziesięciu lat i nie ma problemu". Serio mówie.
> To się nazywa Previously Developed Software. Tak. Ale to nie jest słowo honoru, bo
historię użycia trzeba mieć udokumentowaną

Owszem. Udokumentowanie polega na obserwacji, statystycznej i
subiektywanej, że działa.

> i trzeba wykazać w jakim stopniu nowe użycia pokrywają się ze starymi. Nie ma w tym
nic nieracjonalnego.

Oczywisćie. W końcu pisali helloworlda i piszą teraz innego helloworlda.
To TAKIE trywialne pokazać że mają ten sam kod, kompilwoany tak samo i
to coś zapewnia. Utopia.

>> Musisz zagwarantować że twój pewny kompilator jest pewny dla kodu
>> którego jeszcze nie ma.
> Jest dokładnie odwrotnie (czyli jak już pisałem, mylisz pojęcia).
> Uważaj:
> "Upon successful completion of verification of the software product, the compiler
is considered acceptable for that product."
> "Although the compiler is considered acceptable once all of the verification
> objectives are satisfied, the compiler is only considered acceptable for that
product and not necessarily for other products."
> Czyli o tym, że kompilator *był* dobry wiadomo dopiero jak się nim zrobi produkt.

Niebywałe. Czyli innymi słowy gadanie o tym że się go wybiera PRZED nie
miało sensu?

> Natomiast nie zakłada się, że *będzie* dobry, zanim się tego produktu nie zrobi. Bo
proces jest tak ustawiony, że wcale na tym założeniu nie polega.

Super. Innymi słowy może być zły? Ojej, to będzie trzeab użyć innego?
Ojejejej. Niemożliwe, przecież nie wolno:

"projekt zaczyna się mając już zatwierdzone narzędzia.".

No to lekka dupa, trzeba zauważyć.

Prosze, opisz jak wygląda koncepcja zrobnienia SWOJEGO projektu na
nieznanym kompilatorze i udowodnienia formalnie w ten sposób że jest
dobry. Z chęcią poczytam. Obawiam się jednak że wniosek będzie że jest
dobry do testów na których był testowany a i to będzie naciągane jak
guma z majtek.

> Zapytaj kolegę od samolotów, skąd są te cytaty.

Ze śmiesznych norm ISO i DO? Dokumentów szkoleniowych Tuv? Z publikacji
naukowych? Z poważnych książek z długimi tytułami?

>> Albo z miejsca gdzie siedzę widać coś innego niż z Twojego.
> Na to wygląda. Ale też dlatego nie mam zamiaru się w nieskończoność szarpać.

Ależ nie musisz. Ja najzwyczajniej w świecie doskonale sobie zdaje
sprawę w jakiej utopii testowania siedzi pół świata. I jak absurdalnymi
metodami staraja się z niej wydobyć.

>> Nikt nie naciska na kilka kompilatorów.
> Hura!
>> Ale kilku wielkich graczy
>> zdecydowało się na to.
> "Pewni ludzie", "niektórzy", "chodzą głosy", "ktoś mi opowiadał", itp...

Więc zapewne już rozumiesz że czasami o detalach nie można mówić. I nie
dlatego że nie istnieją tylko dlatego że takie mamy reguły gry na tym
rynku. To nie GitHub i nie każdy z woich rozmówców to dzieciak. Zrób
założenie inne, może się rozjaśni dlaczego nie każdy ma prawo i
możliwość mówienia o detalach, nazwach i nazwiskach.

do góry

On 08/10/2019 08:48, AK wrote:
>> A co to jest blech?
> buz()
> Pajacu

Czuć ten klimat lasu pełnego ojców AK przekazujacych tą kulturę na swoje
dzieci. Jak już wspomniałem, jest pewna grupa ludzi mająca najwięcej do
powiedzenia o kulturze.

>, moze bys tak wpierw przetestowal (unitestowo jak najbardziej)
> ten buz, zgdomadzil maksymalnie (bo wiadomo ze calej "dziedziny"
> nie pokryjesz, a wazne, zeby to byly miejsca "charakterystyczne" np.
> blisko koncow przedzialu, jakies inne punkty charakterystyczne)
> miarodajne dane (czyli wyniki buz() z przykladowego zakresu/zakresow).

No robie to z kodem dobre 20 lat jak nie więcej. I? No wiec zazyczaj
wtedy mam buz(). A tu nie ma buz(). I dupa z unit testowaniem.

> Oblicz wiec dla przetestowanych unitestowo w buz() przedzialow

Nie da się.

Zacytuje klasyka:

"Bo gdy buz będzie
definiowana przez użytkownika (np. przez podanie kilkunastu liczb
określających współczynniki, wykładniki itp.) - to zwyczajnie nie
wiesz co z czym masz assertEqual"

Nzjwyczajniej nie wiesz na jaki post i jaki kawałek kodu odpowiadasz,
stąd rady które są tyle warte ile kosztowały.

> PS: Wiec zwyczajnie z tymi testami integracyjnymi pojechales.
> Jesli tak (hm... nie mamy _na patelni_ wartosci oczekiwanych to..
> olewamy unittesty.... a co !

Bzdura.

Unit testy z definicji testują *unity* kodu. A nie tajemnicze funkcjie
podawane przez użytkownia jak u niejakiego sławka. Od tego są inne
warstwy testowania.

> to moge stwierdzic tylko jedno. Przedszkole, a nie testowanie :(

Nic nie możesz stwierdzić bo nie masz danych. Pokaż buz() to będzie
rozmowa o uni testach. Nie pokazesz buz() to nie ma unit testów tylko
wróżenie z fusów, co czasami się oczywiscie praktykuje, ale raczej bez
specjalnych nadziei że daje odpowiedź poprawną. Koniec dyskusji nad
buz() i fun(). Nie ma kodu, nie ma unit testów.

do góry

On 2019-10-10 21:52, heby wrote:
> On 08/10/2019 08:48, AK wrote:
>>> A co to jest blech?
>> buz()
>> Pajacu
>
> Czuć ten klimat lasu pełnego ojców AK przekazujacych tą kulturę na swoje
> dzieci. Jak już wspomniałem, jest pewna grupa ludzi mająca najwięcej do
> powiedzenia o kulturze.

Ktos kto mieni sie informatykiem i mowi o Windows, ze to jakas nisza,
jest pajacem i AK czy kultura nie ma tu nic do czynienia :)
Jest pajacem bezwzglednie i bezwarunkowo.
PS: Pajacem lub Ayatollahem (jeden BUC...).

>> , moze bys tak wpierw przetestowal (unitestowo jak najbardziej)
>> ten buz, zgdomadzil maksymalnie (bo wiadomo ze calej "dziedziny"
>> nie pokryjesz, a wazne, zeby to byly miejsca "charakterystyczne" np.
>> blisko koncow przedzialu, jakies inne punkty charakterystyczne)
>> miarodajne dane (czyli wyniki buz() z przykladowego zakresu/zakresow).
>
> No robie to z kodem dobre 20 lat jak nie więcej. I? No wiec zazyczaj
> wtedy mam buz(). A tu nie ma buz(). I dupa z unit testowaniem.
>
>> Oblicz wiec dla przetestowanych unitestowo w buz() przedzialow
>
> Nie da się.

Niby dlaczego. (Prawie) zawsze sie da.
Gdy naprawde ciezko, to mock buza() tez jest pewnym wyjsciem.
Mock chocby wylacznie po tp aby prze-unit-testowac funa()

> Zacytuje klasyka:
>
> "Bo gdy buz będzie
>  definiowana przez użytkownika (np. przez podanie kilkunastu liczb
>  określających współczynniki, wykładniki itp.) - to zwyczajnie nie
>  wiesz co z czym masz assertEqual"

To sobie zgromadz te dane buz()-a dla tychze wspolczynnikow.

> Unit testy z definicji testują *unity* kodu. A nie tajemnicze funkcjie
> podawane przez użytkownia jak u niejakiego sławka.

Te "tajemnicze" funkcje sa _takimi samymi_ jak kazde inne.
Identycznie jak te jawne (z source kodem itp) podlegaja unittestowaniu.

> Od tego są inne warstwy testowania.

Baju baju...
Inne warstwy sluza zupelnie czemu innemu, a nie testowaniu pojedynczych
funkcji.

Ze niby fun() nie jest normalna funkcja?
Chyba sobie kpisz.
Juz lepiej zmock-uj tego buz() /fakt, nie zawsze sie da/ gdy nie chce ci
sie przygotowac _faktycznych_ danych.

>> to moge stwierdzic tylko jedno. Przedszkole, a nie testowanie :(
>
> Nic nie możesz stwierdzić bo nie masz danych. Pokaż buz() to będzie
> rozmowa o uni testach. Nie pokazesz buz() to nie ma unit testów tylko
> wróżenie z fusów

To juz jest horrendum :)
Ze niby musi byc znany kod fukcji, aby ja prze-unittestowac?
Chopie, nie blamuj sie calkiem.

AK

do góry