SULTHAN: pak nechápu, proč jsi jmenoval Javu, kde to fakt nemusíš řešit jako příklad něčeho, kde to dělat musíš

AXTHEB:
SATAI:

Budu se opakovat: Hodně záleží na tom, v jakém jazyku a frameworku pracuješ.

SULTHAN: nic takového v Javě dělat nemusíš

SULTHAN: jsou i codebase v typescriptu kde bys tenhle damage našel :-)

JANFROG: Jo, noise u testu je problem. Napsal jsem robustni a spolehlive, ale treba v mym pripade konkretne jde o testy sitovych zarizeni a linuxovyho sitovyho stacku, a ty sitovy veci proste jsou spis noisy. Je tam kupa ruznych timeoutu, je to slozitej dynamickej system. Ted ty testy se pousti na milionu ruznych typu HW, ve virtualkach ruznych konfiguraci, na HW switchich, s offloadama... Cili je tezky udelat skutecne robustni test. A kazdej test je v dusledku proste kod, kterej je treba maintainovat, kterej bitrotuje, a jehoz samostatna existence tim padem neco stoji.

I tak se velice vyplati kazdou featuru mit testama pokrytou, pokud mozno. Aspon v Linuxu se ten sitovej stack furt hejbe, a zaroven je tam dost vzajemnych zavislosti, a zpusobu jak to nakonfigurovat, a ktery casti v tom kernelu mit a ktery nemit, a pak do toho jeste vstupuje jakou trafiku na tom poustis. Tam se nejde s zadnou mirou jistoty podivat na patch a vedet, tohle bude fungovat a nikoho to nerozbije. Potrebujes testy.

Plus ty testy funguji jako navod, jak tu featuru pripadne nakonfigurovat, implicitni dokumentace!

Ty delas myslim dost toolchain, prekladace, VMka, tenhle druh veci, tam si dovedu predstavit, ze je to podobna cerna magie napsat robustni test, protoze z verze na verzi bude prekladac prekladat mirne jinak, a jde o to, jestli se tim trefi do tolerancniho okna toho testu. Nemluve pak o vecech jako testovani, co ja vim, instruction schedulingu. Vlad Makarov delaval (a mozna porad dela, ale uz nejsem v RH) perf testy GCC, a zminoval, ze dosadnout reproducibility je velkej problem.

Takze ad tech 5 %... hele, mas notoricky flaky testy, ty by pochopitelne bylo dobry fixnout, aby prestaly byt flaky, ale kdyz ti v mergi popadaji tyhle, asi se nad tim da pokrcit rameny. Pokud mas byt 2 % failu v "cistejch" testech... ehh, asi bych spis nemergoval :) Ale neznam podrobnosti. Jsem si jistej, ze to je nejakej kompromis mezi tim, aby se maintainer nezblaznil a koza zustala cela.

Vetsina z nas stejne dela na softwaru nebo systemu, kterej je zbytnej a jestli funguje dobre nebo spatne, je ve finale uplne jedno, protoze nejde o zdravi ani zivot.

Mimochodem GraalVM je skvela vec, nechapu, proc ho u jednoho z minulejch projektu porad ignorovali, kdyz to zlepsovalo vykon bez nutnosti optimalizovat jejich prumernej kod v jave.

AXTHEB: Jo, protože nejpozději při code review ten kód (statisticky řečeno) budu stejně měnit, a ty testy jako když najdu. A pak znovu, až se to pošle do upstreamu, kterej (statisticky řečeno) taky bude mít $názory. A pak až to bude interní downstream za rok integrovat.
Uznávám, že náš workflow je specifickej, ale málo co se vyplatí tak jako pořádný testy, na který se dá spolehnout.

Já se to snažím spíš redukovat... pokud něco neumím vyřešit dnes, tak to nechám ve stavu, že je to dojebané jenom na jednom místě a ne na 7 místech ve 4 souborech :-D. A hlavně dokud to nefunguje, nedělám comit, abych měl šanci to odjebat :-D S tím se dá usínat.