Musím se přiklonit na stranu Martina s tím, že realita je taková že když se tlačí na čas a cenu tak testování je první co se ořezává. Já to třeba vysvětluji tak, že pokud nebudou unit testy tak si musí zákazník dodaný software otestovat uživateslky sám a chyby mu opravím bezplatně pokud se bude jednat o minutovky nebo se domluvíme na vícepracích.
Ve výsledku to většinou dopadne dobře a zákazník ušetří tím že nemá testy ode mě. Spíš mi vzniknou výcepráce protože si to projde podle jeho zadání ale zjistí že něco si nedomyslel, nebo že by to šlo ještě vylepšit a spíš dělám úpravy, které nikdo neuvažoval, za což si zaplatí.
S tím se pojí další komplikace udržovat unit testy aktuální. Dost často něco ladím, zrychluji, refactoriji a pod. Nepíšu nic zas tak super složitého že bych tomu nerozumněl a nemohl to přeskládat jako lego. Pak je to pain udržovat testy ...
Podle mě hrozně záleží na konkrétním případu vývoje podle technologií / použití / životnosti / rozšířitelnosti / počtu vývojářů / integraci CD/CI
Je hezký pushnout z visual studia - udělat pull request a po schválení to letí rovou na release a unit testy to zastaví pokud selžou. Nicméně někdy je potřeba jen zkopírovat exáč z binu na vzdálenou plochu ...
Myslím si že je dobrý být versatilní s tím vysvětlovat rizika i výhody zákazníkům.
Jen pro kontext
Žiju v prostředí - visual studio, c#, desktop aplikace, automatizace, asp.net, git, devops, azure
Projekty od 0 v rozsahu 1-3 týdny do nasazení.
100 Odpovědí
20779 Zhlédnutí