E2E4: Tuhle tabulku vidím tenhle týden už podruhý s úplně jinýma číslama. Jen 9% v IT nebo dokonce 99 ze sta učitelů si nepřijdou zbytečný? Buď maj rozptyl tak +- devadesát procent nebo to se ptali nějakých zdrogovaných lidí.

zaujalo.

https://www.nyx.cz/discussion/275939/id/57898483

ALMAD: K te korektnosti - na te stejne konferenci byl i typek z Google (Michael cosi) co dela na sandboxu ve V8. Ten rikal, ze pres 90% vsech security issues co maji je ve skutecnosti "correctness issue" a tedy ze security <=> correctnes.

Samozrejme, vsichni vime, jak zakazniky zajima security :-) takze mas pravdu, neni to protiargument k tomu co rika ten clovek z rethinkdb.

CERMI_FOX: Obavam se, ze u tehle typu projektu to neni tak jednoduche jak by se mohlo zdat.

JANFROG: je otazka, jestli v dobe, kdy uz testy prestavaji skalovat, neprestali programatori skalovat uz davno. Neboli mi to prijde jako indikator potreby ten projekt nejak roztrhat, zmodularizovat nebo neco podobneho

JANFROG: Moc ne, je to spis anekdotalni/osobni zkusenost.

Protipriklad ve smyslu ze projekty co se prilis soustredily na korektnost testu misto delivery dost casto neusoely proti konkurenci co to delala naopak.

Mluvi o tom treba rethinkdb tady https://gist.github.com/ramalho/93b87e961b6e019be8e1f6f82864b6f9#wrong-metrics-of-goodness

Ale samozrejme na podporu NOHOUS, tak nejak zalezi jestli se bavime o databazi, kompilatoru, kernelu, webovym frontendu a nebo beznym SaaSu :)

v cislicovych navrzich se jede constrained random a to je taky peklo sveho druhu, ale tam nastesti jakmile design splni specifikaci, uz do nej nikdo nema moc tendenci hrabat. Kazdopadne korporaty jedou v teto oblasti tezky waterfall s oddelenym verifikacnim a implementacnim tymem; priserne je, ze se neda moc testovat inkrementalne, verifikacni tym jede typicky black box integracni test.

JANFROG: Ono jde taky o to jaky testy. On se v podstate zazil jeden typ testu a to regression testy, ale je toho mnohem vic a s jinejma pristupama, jenom se to nikdy nedostalo do mainstreamu.

Jediny co me na tom trapi je, ze ty showcasy co to moc pekne popsaly jsou software projekty co se jaksi neprosadily, myslim ze tam muze byt urcita kauzalita :)

IMHO dva hlavni protipriklady jsou AWS sluzby a TLA+ (ale to uz je spis formalni verifikace nez testy) a SQLite, co to ma imho udelany i popsany moc hezky.

How SQLite Is Tested
https://www.sqlite.org/testing.html

SULTHAN: Neznám jazyk/framework, kde by ten můj přístup nefungoval. Ale těžko ti to vysvětlím, když ho považuješ za damage.

AXTHEB: většinou mi nejlépe vycházelo mockovat věci na rozhraní systémů...

SULTHAN: Vidíš, moje zkušenost je přesně opačná. Jakmile dynamicky mockuješ metody, velmi svižně se dostaneš do situace, kdy tě testy táhnou k zemi, naprosto znemožňují jakýkoliv refaktoring a stane se přesně to, co se tu píše dole - máš kupu náhodně failujicích testů a si v háji. Na druhou stranu, pokud to rozhraní abstrahuješ a uděláš nějakou smysluplnou třídu co tu službu používá, tak se v tom snadno udržuje pořádek a přehled. A když se ta služba změní, stačí opravit ten interface a třídu, která tu službu používá.

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

Třeba v javascriptu se mockuje krásně - tam si vezmeš implementaci služby a dynamicky na ní nějakou funkci změníš na mock a použiješ to v testu. To ale ve většině jazyků udělat nemůžeš, takže abys nějakou službu mohl namockovat, tak její rozhraní musíš abstrahovat (např. Java interface) a mít separátní "reálnou" a "mock" implementaci (některé test frameworky samozřejmě ten "mock" vygenerují z rozhraní samy).
Ale právě ta existence single-use rozhraní ti zbytečně komplikuje kód a je to jedna z nejtypičtějších "test induced design damage".

SULTHAN: netvrdím, že se to neděje, ale přijde mi, že tak 80 procent změn kvůli testovatelnosti bylo k lepšímu

JANFROG: Já mám rád termín "test induced design damage". Obecně jsou to všechny změny architektury, které musíte udělat, aby Váš kód byl testovatelný, například různé dependency injections.
V minulosti jsem nucen psát kód v naprosto nepřehledné a otřesné architektuře, jejíž jediným smyslem bylo to, aby některé normálně neoddělitelné části kódu byly testovatelné samostatně.

ANT_39: Ja myslim, ze nejsme ve pri. Testy pisu, dokonce je pise i kolega co testy v zasade neuznava :-) Sitovej stack je rekl bych stejne peklo jen s jinou prichuti.

Proc o tom mluvim je, ze - alespon co si pamatuji - jsem nikde v zadnem textu / prednasce vysvetlujicim dulezitost testu, TDD apod, nevidel zminen fakt, ze od jiste komplexity toho systemu testy neskaluji.

Jinak to cislo 5% jsem si vycucal z prstu, zadne konkretni cislo nepadlo, mozna je to min, nevim. Spis jsem chtel rici, ze proste nejaka mira failujich testu se proste toleruje. Neco podobneho jak jsi popisoval (flaky vs. non-flaky failures) delaji, ale neni to snadne a uz mas zase nejaky system nad tim, co sbira historicke data a z toho dela statisticke modely co jeste je ok a co uz ne. A to stoji dost energie a co ja vim, neni na to zadna standardni literatura co si prectes a vis jak na to (na rozdil od treba register alokatoru nebo refinements).