GOSHEWAN: my máme... cca jak píše satai, ale bez rozlišení oficiální a neoficiální. To dělá účetní firma nějakejma kouzlama

OTAZKAKONCE: `brunch` by byl muj oblibeny benefit

K te angličtině: můj kolega z ukrajiny standardně píše že 'just updated the last changes in brunch XY.. "

Vzhledem k tomu že je na seniorni pozici a je dost citlivej na kritiku, nechávám ho v tom.

Ona i ergonomická myš a klávesnice udělají divy.

CERMI_FOX: a datlej do firemního kompu

JIMX: já nevim, když přijdu někam do programátorský firmy, tak tam většinou vídám v kanclu plno živnostníků, co sedí na firemních židlich, u firemních stolů, pijou firemní kafe a nechávají se ochlazovat firemní klimatizací ... ;)

JIMX: na živnosti jsem pochopitelně židli od Therapie měl

Vy jste teda zpovykaný ... před pár lety seděli programátoři ve sklepě na bedně od PC a pili redbully z plechovky a byli spokojení ... a teď chcete klimatizaci, kafe, ovoce, tělocvičnu ... :-DDD

Tyhlety firemní benefity ... si zase vzpomenu, až si nějakej zaměstnanec bude stěžovat, jak si my živnostníci žijeme skvěle :-)

K těm testům.

Já jsem frontendista. A unit testy na frontendu jsou můj pet peeve. Jasně, pokud píšu nějaký kus business kódu, tak jsou super, ale jinak mi připadá, že jsou pro frontend naprosto nevhodné. Spousta kódu je závislá na nějakém UI frameworku (posílání eventů, rendering) a test často vypadá tak, že se to celé namockuje a pak se v testu explicitně otestuje, že každá metoda byla zavolána se správnými parametry. UI kód prostě nemá rozumný výstup pro otestování.

Jinak hlavní problém unit testů je pro mě mockování. Jsou jazyky, kde se mockuje snadno (např. javascript). A pak jazyky, kde se nedá mockovat skoro vůbec. Pak se kvůli mockování dělají strašné složitosti v architektuře (např. všechno je interface). Má to i hezký název Test-induced Design Damage.
Byl jsem na spoustě projektů, které totálně zesložitily architekturu kvůli testování, a nakonec se tam skoro žádné testy nenapsaly.

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.