JARDABEREZA: test coverage si můžeš vygenerovat úplně v každém jazyce. Pokud testuješ něco většího, tak to není unit test.

SULTHAN: U JavaScript/TypeScript si můžeš vygenerovat test coverage. A místo testu pro tu jednu funkci si může napsat něco většího, kde to bude zahrnuté taky a díky test coverage budeš vědět, že to taky testuješ.

KOLCON: Tak já rozhodně nejsem proti automatizaci testů, jen úplně nesouhlasím s tím, že unit testy jsou vždy ta nejlepší úroveň, kde něco testovat. A i já jsem si prošel obdobím, kdy jsem se snažil mít kód pokrytý z 100%, včetně případů, které v podstatně nemohly nikdy nastat.

SATAI: Tak zrovna ty unit testy jak kde a jak na co.

- některé unit testy jsou vyloženě zbytečné. Když mám funkci na 1-3 řádky tak unit testovat jí je často ztráta času. Nemluvě o tom, že často ani nejde unit testovat jinak než tak, že se přesně zduplikuje její kód.
- pro unit testy potřebuješ většinou mockovat. A mockování je ve spoustě jazyků neřešitelný problém. Respektive je to řešitelné tak, že se všechny závislosti (včetně například konstruktoru pro Datum apod) abstrahují do interface. Zpravidla to architekturu zkomplikuje. Někdy až tak, že se stane totálně nepřehlednou (viz test-induced design damage).
- pokud je kód nějak hodně propojený s nějakým frameworkem, tak většionu nelze úplně oddělit náš kód od toho frameworku. Typický příklad je například jakýkoliv UI kód s nějakým UI frameworkem. Ten UI kód zpravidla nelze oddělit od UI frameworku tak, abys mohl unit testovat výstupy. Důsledek - Frontend se velmi špatně unit testuje.

KOLCON: loser!

KLEINZACH: Byla? Ja mel za to ze jeste nepominula...no jo, asidelam full-remote moc dlouho a ztracim kontakt se svetem (a jeho trendy).

Me osobne na tom funkcionalnim trendu bavilo (bavi) ze obvykle proponent zacinal hanopisem na OOP a pak oslim mustkem presel na na funkcionalni, a oho, solidni matematicka teorie lambda kalkulu atd atp. Tak jsem si vzdycky vzpomel na skvely email Vaslly Bykova o dualite objektu a funkci vyssich radu a dal jel OOP :-)