Styly programování

[listoper]

Právě klasické unit testy funkčnost v rámci workflow naopak ztratily.

Větší blbost jsem hodně dlouho nečetl.

Je to nestastne receno, ale s timhle vice mene souhlasim...
ztratili cast sve hodnoty pro cloveka... (tu sebereflexivni.. jak dobre se pouziva to API ktere jsem navrhl?)
Daleko vice ziskavaji E2E testy.. byly vzdycky drahe na udrzbu, ale ted kdyz to stoji vicemene nic tak se vyplati.

Unit testy pise AI a ja je nectu.. jestli jsou pro ni uzitecny tak at je pise.. ale pro me jsou dulezity vystupu e2e(business scenario testu) a NFR testu

Tady bacha. Hranice mezi různými druhy testů není moc standardizovaná.

Jj. na to tu uz par let obcas narazime, ze si nerozumime..
Ja unit testy nazyvam to jak jsou chapany v TDD. Takove ty ktere pustim jednoduse lokalne bez deploymentu cele aplikace a databaze a omacky okolo a staci mi k tomu v podstate jen ta jednotka kterou testuju (typicky class) a jeji test. Zbytek kdyz je to nevyhnutelne tak se mockuje (a kdyz se moc mockuje tak je to indikator spatneho navrhu... )

Business scenario testy jsou ty testy ktere pokryvaji usecases

A NFR jsou ty ktere pokryvaji nefunkcni pozadavky (performance, security, observability.... )

[Reklama]

[Martin Poljak]

Právě klasické unit testy funkčnost v rámci workflow naopak ztratily.

Větší blbost jsem hodně dlouho nečetl.

ztratili cast sve hodnoty pro cloveka... (tu sebereflexivni.. jak dobre se pouziva to API ktere jsem navrhl?)
Daleko vice ziskavaji E2E testy.. byly vzdycky drahe na udrzbu, ale ted kdyz to stoji vicemene nic tak se vyplati.

Dík. Přesně tak jsem to myslel a vnímám to naprosto stejně. Jenže hrozně miluju ty neustále poněkud připitomělé TDD výkřiky některých zdejších MBA takže jsem to prostě nemohl rozepsat víc. To by se moc podobalo praxi a nezapadlo správně do té povrchnosti

[qelurg]

Na best practices na většině projektů fakt není čas. Výsledkem je skoro vždy nějaký kompromis.

Jasny. to je jako rozepinat poklopec kdyz jdes na zachod... Kdo na to ma cas? Navic si jako bonus ani nemusis umejvat ruce kdyz odchazis.

Pokud to jsou kalhoty od skafandru, tak to může být docela dobrý nápad.

[mark42]

Je to nestastne receno, ale s timhle vice mene souhlasim...
ztratili cast sve hodnoty pro cloveka... (tu sebereflexivni.. jak dobre se pouziva to API ktere jsem navrhl?)
Daleko vice ziskavaji E2E testy.. byly vzdycky drahe na udrzbu, ale ted kdyz to stoji vicemene nic tak se vyplati.

Unit testy pise AI a ja je nectu.. jestli jsou pro ni uzitecny tak at je pise.. ale pro me jsou dulezity vystupu e2e(business scenario testu) a NFR testu

Ak ti AI pise aj testy aj kod tak ty ani netusis, ci sa to sprava, ako sa to spravat ma. A ak su pre teba unit testy, ktore pokryvaju okrajove scenare konkretneho kusu kodu nepodstatne tak by si ich mal mat vsetky pokryte v E2E scenaroch. Tak dufam, ze E2E scenare a testy ti AI nepise tiez, lebo raz ti napise testy s "return(success)" a potom sa budes cudovat.

[listoper]

Samozrejme, ze AI pise i ty E2E a NFR testy... Vstup je nase konverzace s businessem.
Me zajimaji jejich vystupy.. a ty jsou "vytuneny"... Je to dukaz prubehu testu kazdy krok je zdokumentovany a "opakovatelny"
(Neco jako takova ta zelena sipecka v Intellij IDEA kterou se daji spustit testy tak mam v testing evidence, aby kazdy kdo cte tu evidence mohl snadno test replikovat a sledovat prubeh u sebe. )

A pokryti je idealne dostatecny na to, aby jen pomoci featurefiles dal projekt preimplementovat pomoci AI od nuly.. Mam to vyzkouseny jen castecne, ale nevidim duvod proc by to neslo...

[Reklama]

[Ziktofel]

Testy muze psat umela demence, ale nekdo by mel vedet, co vlastne ten test testuje, jinak je totalne k nicemu. E2E je spis takova tresnicka na dortu, protoze pokud spoleham pouze na E2E, tak musim otestovat hodne pripadu, kde mistni speky lip otestuje spravnej unit test. Vhodnej test neblize problemu je rychlejsi a efektivnejsi na chytani vsech zaludnosti (proste ta komponenta, co muze delat nejvetsi problemy, si zaslouzi vlastni sadu testu, ktery otestujou prave ji a pak vim, ze tato komplexni komponenta se chova spravne dle specifikaci).

[Martin Poljak]

E2E je spis takova tresnicka na dortu, protoze pokud spoleham pouze na E2E [...]

Tak ony hlavně nejsou jen end-to-end testy a unit testy. Což jsou dvě krabice, do kterých se během let skoro každý uzavřel a odmítá teď z toho lustru slézt. Oprávněné to bylo před AI. Ale právě v době AI začaly mít smysl testy, které nejsou vysokoúrovňové ale ani netestují jen základní units, testují větší -- ale ne úplně základní ani ne úplně velké -- funkční celky. Což může vypadat jako nesmysl ale je to přesně mitigace toho, aby AI byla dostatečně autonomní ale zároveň dostatečně pod kontrolou. Na jednu stranu to má nevýhody obojího, na druhou stranu výhody obojího. Trade-off je to vždycky tak, jako celý vývoj. Což je ostatně hlavní práce vývojáře.

[Zopper]

Ak ti AI pise aj testy aj kod tak ty ani netusis, ci sa to sprava, ako sa to spravat ma.

Když použiju nějakou knihovní funkci, tak taky netuším, jestli se chová, jak má. Ty si sám píšeš testy i na každou vnější závislost, nebo taky spoléháš na to, že to otestoval někdo jiný - a šťourat do toho začneš až když nějaký test na vyšší úrovni nebo praxe ukážou problém?

[BoneFlute]

Ak ti AI pise aj testy aj kod tak ty ani netusis, ci sa to sprava, ako sa to spravat ma.

Když použiju nějakou knihovní funkci, tak taky netuším, jestli se chová, jak má. Ty si sám píšeš testy i na každou vnější závislost, nebo taky spoléháš na to, že to otestoval někdo jiný - a šťourat do toho začneš až když nějaký test na vyšší úrovni nebo praxe ukážou problém?

já třeba jo

Zvláště u webservis oni rádi mění api a chování aniž by dali vědět.

[cznarg]

Ak ti AI pise aj testy aj kod tak ty ani netusis, ci sa to sprava, ako sa to spravat ma.

Když použiju nějakou knihovní funkci, tak taky netuším, jestli se chová, jak má. Ty si sám píšeš testy i na každou vnější závislost, nebo taky spoléháš na to, že to otestoval někdo jiný - a šťourat do toho začneš až když nějaký test na vyšší úrovni nebo praxe ukážou problém?

já třeba jo

Zvláště u webservis oni rádi mění api a chování aniž by dali vědět.

Něco jiného je testovat závislost kterou nemám pod správou (web api etc.) a něco jiného je knihovna. Kterou pod správou mám přesnou verzi a když neprovedu upgrade, aplikace bude fungovat dál. Osobně to nikomu neberu, ale kde je ta hranice? Za chvíli někdo může psát testy jestli se compiler chová tak jak se chovat má...

[BoneFlute]

kde je ta hranice?

Ekonomie?

Mám knihovnu, a pro ni mám testy.
Pak mám aplikaci, která tu knihovnu používá, a napíšu si testy znovu. Párkrát se mi to už vyplatilo.

Běžně to nedělám. Spíše výjimečně. Ale když by šlo třeba o medicínský software, nebo raketoplán...?

Pointa je v tom, že na takto kritický software použiji více jak testy. Protože testy jsou tak nějak z definice neúplné, že.

Programátor který píše "obyčejnou" aplikaci to otestuje tak, aby se mu to vyplatilo:
1/ co se testuje snadno a má největší dopad
2/ co se testuje hůř ale má velký dopad
3/ to ostatní

[Kit]

Zvláště u webservis oni rádi mění api a chování aniž by dali vědět.

Něco jiného je testovat závislost kterou nemám pod správou (web api etc.) a něco jiného je knihovna. Kterou pod správou mám přesnou verzi a když neprovedu upgrade, aplikace bude fungovat dál. Osobně to nikomu neberu, ale kde je ta hranice? Za chvíli někdo může psát testy jestli se compiler chová tak jak se chovat má...

Někdy dělám i testy na používané knihovní funkce, abych měl jistotu, že se budou správně chovat i při upgrade té knihovny.

[Jiří Havel]

Osobně to nikomu neberu, ale kde je ta hranice? Za chvíli někdo může psát testy jestli se compiler chová tak jak se chovat má...

A co třeba testovat, jestli se compiler chová tak, jak čekám? V některých jazycích má až překvapivou volnost (třeba C). Tam může update překladače udělat zajímavé věci. Ono třeba stačí aby se trochu změnila ochota inlinovat a nějaká kritická část kódu může být násobně pomalejší.

A překladačových bugů jsem už taky pár potkal. Ale tohle jsou věci tak nepředvídatelné, že tu preventivní test nepomůže.

[vrit]

Doporučuju dobré video proč nepoužívat clean code.

Clean code, horrible performance
https://youtu.be/tD5NrevFtbU?si=2NGwwfGr3vcXoUCX

[Kit]

Doporučuju dobré video proč nepoužívat clean code.

Clean code, horrible performance
https://youtu.be/tD5NrevFtbU?si=2NGwwfGr3vcXoUCX

Jediným argumentem je benchmark? Schválně si vybral případ, který nejlépe vyhovuje jeho záměru, pak na to aplikuje Fly Weight, ale jen na tu jeho verzi. Nevěřím benchmarkům, které si sám nezfalšuji.