JANFROG: me na psani testu (vlastne jakychkoliv, at uz unit, integracnich ci end-to-end) prijde jako velka vyhoda to, ze to lidi donuti psat ten kod testovatelnej. To ze vysledna coverage neni 100 a treba ani 70 % je imho vedlejsi. Dava mi to moznost si snadno a rychle nejaky test dopsat, kdyz se jdu vrtat do nejaky featury, kterou fakt nechci rozesrat. Problem te testovatelnosti obcas muze narazet na zvysenou komplexitu do zacatku - treba mockovani casu umi bejt neprijemny. Ale rozhodne je to jednodussi, kdyz je to s tim delany od zacatku, nez se to snazit doroubovat do neceho uz hotovyho.

A stejny pozitiva vidim a stejnej pristup razim u automatizovanyho deploymentu - donuti to vsechny vyrabet ty veci deployovatelne a provozovatelne - myslet na to, co to potrebuje k rozbehu z cisty louky, ze je potreba nejak deterministicky popsat navaznosti co ma startovat po cem. Jak se pozna, ze neco bezi (nebo naopak nebezi) - tj. ty veci mnohem lip ukazujou nejaky metriky. Stejne tak se mnohem driv vyresi jak neco muze bezet ve vic instancich, jak se u toho dela deployment nove verze atd.

Casto to vede k tomu, ze se vyrobej nejaky simulatory trafficu, ktery se pak daj pustit proti devel/integracnimu prostredi apod. A v neposledni rade to vede k problematice pripravy testovacich dat - idealne nejakou anonymizaci dat realnejch, ale to je uz kapitola sama o sobe.

Myslel spis pak sklouzava pocitu falesne jistoty ala SUCHRE. Cim vic low-level vec to je a cim vic je to knihovna (a ne aplikace) tim je to horsi.

Tohleto, spolecne s pouckou ze nemas delat zbytecne abstrakce a featury co ted nejsou potreba a se zaklinanim se Knuthovym "premature optimization" zadelava na vrazednou kombinaci, alespon co obcas (casteji nez bych chtel) vidim.

Takze, kdyz o tom premyslim, mi spis vadi to, jak je to "prodava" (a husti do studentu :-), vetsina knizek / prednasek na to tema to podava jako "the way" a malokdo (nikdo?) nerekne na ferovku ze to ma sve limity a kde. Na to si musi kazdy prijit sam, jenze behem toho prichazeni domrvi dost veci, nejen sobe, ale i ostatnim.

No nic, konec filozofickeho okenka :-)

QWWERTY: no to je to jak jsem to myslel - ne honit se za 100%, ale aby to pokrejvalo potencialni problemy, na kterejch zalezi. jo, nekdy to neni uplne mozny a pak nema smysl delat test kterej testuje syntetickou haluz..

v tom pripade je treba se zamyslet nad tim, zda by jinej test (cojavim, end to end test) neposlouzil stejnymu ucelu "ten vobjekt se asi zpracoval dobre, kdyz vysledek je presne takovej jako by mel bejt".

ale:

SATAI: Já jsem si hodně oblíbil TDD na psaní binárních parserů. Např. TIFF tu je cca od roku 1992 a žádné převratné změny se tam nedají čekat. A ta struktura a očekávání jsou pevně danné.

JANFROG: TDD asi dobrý na business funkcionalitu. Vložím jabko vypadne mošt.

JANFROG: Ono zalezi... (panaka!)

Kdyz to je zmena v systemu, co mu rozumim a je jasne, co se ma menit, tak TDD (nebo jeste lepe testy z venku dovnitr...) je prima nastroj, ktery mi umozni jet jak fretce. Pokud je problem z vetsi casti zkouseni a postupna iterace veeeelkou spiralou k necemu, tak testy zacit neumim a asi ani nechci.

JANFROG: tak to jsou nějaký nástroje, který se snaží naplnit cíl, možná někdy vylévají vánicku i s dítětem, protože jsou v reálným životě nemožný.. ale jde o ten princip, software psaný lidmi má chyby a nezamýšlené dopady, testování je to co pomůže, není to jen testování pro testování..

klíčový je testovat ty důležitý věci a to co nejdřív.

E2E4: Ja se teda priznam, ze TDD (test driven dev) ve sve krystalicke podobe povazuji spis za kontraproduktivni (i tu coverage). Ale mozna je to jen tim, ze jsem to nikdy nepochopil :-)

E2E4: on unit testy nikdo jiny nez programator psat nemuze. Leda jiny programator, pokud zrovna parujete. Nebo mobujete.

KOLCON: moje chápání je, že současná best practices je

1. unit testy píšou autoři
2. integrační testy píšou autoři nebo testeři
3. funkční testy dělají testeři/QA
4. end to end testy dělají QA

pak je tu test driven development, kde se testama začíná a trend dělat testy automaticky jako součást CI/CD, cokoliv co jde je dobrý mít automaticky a čím dřív tím líp.

SPIKE411: Lépe popsáno v Matt Parker: Humble Pi

SPIKE411: Ze cteni o tomhle pripadu jde fakt mraz po zadech.