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.