On 10/10/2019 23:08, AK wrote:
> Ktos kto mieni sie informatykiem i mowi o Windows, ze to jakas nisza,

Możesz udowodnć tezę odwrotną. Zacznij np. od ilosci systemów
operacyjnych w ogóle na świecie w użytku.

Zacznij tutaj:

https://en.wikipedia.org/wiki/Usage_share_of_operati
ng_systems

>> 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

Ale nic o buz nie wiadomo. Tako rzecze szaman który to zadanie postawił.

>> Nie da się.
> Niby dlaczego. (Prawie) zawsze sie da.

Nie, możez sobie pisać *jakieś* unit testy. To zawsze można, choćby po
to żeby zadowolić jakiegoś speca i komisje za zielonym suknem.

> Gdy naprawde ciezko, to mock buza() tez jest pewnym wyjsciem.

Żeby napisać mocka buza musiz wiedzieć jakie przyjmuje stany dozwolone.
Inaczej możesz ten mock wydłubać na return 4; tylko że to co najwyżej
przetesuje nerwy grupy na codereview.

> Mock chocby wylacznie po tp aby prze-unit-testowac funa()

Nie a się go przetestować, szaman Sławek wyjaśnił że wiedza o buz() jest
niezbędna do testowania fun().

>> 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.

Nie ma buz(). Nie ma współczynników. Nic o niej nie wiadomo.

>> 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.

Nie. Jesli to funkcja która liczy sin() to chwilowo nie znamy kątów dla
których jest większa niż 1 wiec istnieje nikła szansa że nalezy testować
fun() na inne wartości. Albo inaczej: można, tylko po h...

Nie, nie każda funkcja jest taka sama.

> Identycznie jak te jawne (z source kodem itp) podlegaja unittestowaniu.

I ich nie ma. Nie ma więc uni testowania, co nie przeszkadza testować
inaczej, jak choćby uzywając jakiś wyssanych z palca constrains, które w
tym przykładzie i tak nie zadziałają bo przykład zakłada jakiś buz() i dupa.

>> Od tego są inne warstwy testowania.
> Baju baju...
> Inne warstwy sluza zupelnie czemu innemu, a nie testowaniu pojedynczych
> funkcji.

To są dwie funkcjie, jedna znany drugą nie. Nie ma jak testować na
poziomie programisty piszącego fun(). Być może jest możliwośc testowania
na poziomie kogoś kto zna buz(), być może to będzie programista, ale to
nie będzie unit test.

Zapewne kiedyś, w dalekkiej przyszłości linkowania kodu, buz() się
ujawni albo może go ktoś załaduje w runtime. To wtedy bedzie testowanie
po integracji.

> Ze niby fun() nie jest normalna funkcja?
> Chyba sobie kpisz.

Ależ normalna, ale niestety nie jest kompletna.

> Juz lepiej zmock-uj tego buz() /fakt, nie zawsze sie da/ gdy nie chce ci
> sie przygotowac _faktycznych_ danych.

Żeby napisać mocka muszę coś wiedzieć. Tutaj nic nie wiemy. Sławek
pewnie niecierpliwie przebiera nogami żeby dowiedzieć się w jakiej
szklanej kuli mam wyczytać co to jest buz(). Chwilowo nawet a Algolu
takiej nie wymyślili.

Więc tak, możesz sobie cośtam potestować unitestami ściemniając że niby
działa bo dla 3,7 i 50000 działa. Ale to nie jest testowanie, to tylko
taki wyścig na ilośc kkloc-ów.

>> 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?

Musisz znać jej odpowiedzi na dane wejściowe, opisane w jakimś specu.
Tutaj buz() jest nieznany. Czy to będzie kod czy specyfikacja, nie ma
znaczenia. Pokaż buz() to go uzyje, albo pokaż speca to sobie mocka napiszę.

> Chopie, nie blamuj sie calkiem.

Patrzysz czasem w lustro jak dajesz innym rady?