ALMAD: Nejsem sokovany. Proto mi prijde vsechna ta ideologie o testech co se nesmi napsat pokud neprochazi ponekud akademicka. Zaroven fandim TDD, ale obavam se, ze jsem za svou karieru v tech potkal opravdu naproste minimum lidi co podle nej jedou. Myslim, ze to neni nahoda nebo vyber firem, proste to z nejakeho duvodu ve stretu s realitou neni moc prakticke. Smutnym faktem je, ze kdyz se blizi deadlines a zacne jit do tuheho tak testy se seskrtaji jako prvni. Znovu rikam, je to pouze pozorovani reality, ne muj nazor.

VOY: tomu se rika stret reality s ideologii :-)

Urcite se vam nekdy stane, ze prijdete ke kodu, ktery funguje, chcete do nej udelat nejake zmeny a nema zadne testy. Pak prirozene clovek dopisuje testy, ktere prochazi. Chce to nepochybne obezretnost, aby skutecne testovaly co maji, ale takove momenty taky prichazi. Vetsinou AI naznacim kodem co sam napisu jak bych si to asi predstavoval hlavne co se tyce mockovani a pak uz to typicky funguje slusne. From scratch bychom se ale asi daleko nedostali a nebo s hroznou kvalitou kodu.

Teď jsem nedávno dělal review pull requestu, kde byly FE testy (playwright) vygenerovaný přes AI, a bylo to utrpení. Jako jo, nějak se to UI prokliká, ale kód to byl příšerný - elementy se hledaly přes nějaké strašně složitě zanořené CSS selektory a byly tam úplně WTF věci, jako třeba try-catch uvnitř testu (asi aby test nefailnul) nebo prostý return (konec testu) pokud se element nenašel.

VOY: To mi taky fungovalo, založil jsem prázdný soubor na testy s odpovídajícím jménem. A pak jen spustit "GitHub Copilot: Generate Tests" a ono to něco udělá. Ale nebyl jsem s tím úplně spokojený. Vyšlo mi líp napsat jeden vzorový a pak ty další vypadali víc podle toho prvního, takže to např. nemockovalo, pochopilo jaké property má ten objekt atd.

JARDABEREZA: Klicovy je to “kdZ to clovek zkontroluje”.

IMHO hlavni uzitecnost testu je ten design proces, a osobne neverim zadnymu testu kterej sem nwvidel failnout.

Pokud to clovek nedela, tak se imho ma aspon na unit testy vykaslat a zustat u tech integracnich/system testu (kde teda llm umi pomoct dost).

AXTHEB: Da se to pomasirovat contextem, a je to celkem uzitecny na integracni testy typu cypress.

Ale obecne v prumeru souhlas, vychozi stav je ze to generuje testy co nemaj existovat. Navic kdyz agent iteruje nad padajicima testama, tak pokud ho explicitne nenavigujes, tak klidne skoncis s tim ze vsechno co pada zamockuje a skoncis s assert true == true, akorat na padesati radkach a naprosto nezjevnym zpusobem.

Delat v dnesni dobe code reviews je radost, to nemohu rict.

JARDABEREZA: No navrhne ti hromady testů na každou blbost, takže když budeš chtít něco zrefaktorovat, tak ti začnou padat testy, i když se chování appky jako takové nezmění.
Případně se to změní business požadavky, takže něco, co mělo být kladné číslo najednou může být i záporné, tak to změníš a najednou ti popadají zástupy testů.

velmi mi to fungovalo u projektů, kdy bylo třeba přepsat řešení do jazyka XY. Máme funkční testy, které se tomu nasypou a přepíše je to.
Zkontrolovat je to potřeba, ale ten ušetřeny čas tam je.

JARDABEREZA: No, dělá to úplně nahovno testy, jejichž jediný efekt je, že překáží při refaktoru.