ALMAD: React má několik jednoduchých principů co se jak dělá a pak se to jen opakuje do zblnutí. A snaží se zůstat v těch mantinelech. Ale vlastně je to fajn. Chceš UI, uděláš vždycky ty stejné kroky, máš UI. A na internetu jsou snad statisíce příkladů.

SULTHAN: tak to opakovane zazivam celkem pravidelne posledni rok, bohuzel ty projekty musim dostat z technologicjeho dluhu do produkce k nam na k8, vcetne prepisu BE a FE, je to ryzi peklo a pouze jistej sklon k perfekcionalite, odpovednosti za provoz a sklony k sebeposkozovani mi umoznuji svuj ukol splnit

btw. zdravim byvale kolegy, kteri vi o cem mluvim

VOY: Upřímně, to se týká prakticky každé FE komponenty, není to nijak specifické pro react. Na jednom projektu třeba máme jednoduché testy storybooku oproti mockům a jejich výsledek se screenshotuje. Nic to moc nebrzdí, ale při pull requestu člověk musí projít diffy a manuálně schválit všechny změny.
Typový systém (tj. asi mluvíme o typescriptu) bych už dnes považoval za standard.

Pro pobavení, teď nedávno mě ve firmě přizvali na post-mortem jednoho incidentu na projektu s obrovským technickým dluhem. Při buildování jim padala instalace NPM dependencí. Indové to vyřešili tak, že smazali package-lock a commitnuli to bez něj. Jako fakt. A spolu s tím začali řešit, že bude potřeba updatnout knihovny a mě si přizvali, abych jim poradil "jak na to". Když jsem zjistil, že tam mají React 13, který byl vydaný před 10 lety a v podstatě to ještě byla beta verze, tak jsem se jim na to vybodnul.

SULTHAN: Za sebe bych rekl hlavne to, ze kdyz clovek nejakym zpusobem unit testuje reactove komponenty tak casto dojde do stavu, ze ho ty testy znacne brzdi v refaktorovani. Za sebe volim radeji kombinaci kontroly typovym systemem a E2E testu. Tam clovek ma z me zkusenosti vetsi jistotu, ze kdyz testy prochazi tak veci opravdu realne funguji.

VOY: prostě je to šikovné pravidlo, se kterým je potřeba zacházet jako se všemi šikovnými pravidly: "to záleží" ;-)

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).