• úvod
  • témata
  • události
  • tržiště
  • diskuze
  • nástěnka
  • přihlásit
    registrace
    ztracené heslo?
    KOJAProgramovani 40+
    Diskuze o obzive programovanim pro starsi a pokrocile.
    rozbalit záhlaví
    SULTHAN
    SULTHAN --- ---
    JARDABEREZA: tak ty testy máš hlavně kvůli regresím. Při vývoji si to samozřejmě otestuješ docela důkladně (když jsi zoodpovědný), ale pokud máš větší aplikaci, tak je strašně snadný něco omylem rozbít.
    JARDABEREZA
    JARDABEREZA --- ---
    SULTHAN: Když jsem používal React, Redux a Typescript s přísným nastavením, tak chyby byly celkem vzácné. Přidal jsem tam Sentry, aby mi to z produkce schromažďovalo chyby a v drtivé většině případů ten problém nebyl v UI a testy na UI jsem dle mého názoru nepotřeboval. Diverzita prohlížečů je čím dál menší problém. Jednak si prohlížeče vynucují automatické aktualizace. A taky Edge s Operou vč. dalších používají stejné jádro jako Chrome. Takže zbývá už jenom Firefox a Safari.
    SULTHAN
    SULTHAN --- ---
    VOY: Děkuju, mám na to úplně stejný názor, že v JS světě byly unit testy hlavně náhradou typů. Jinak ten důvod, proč třeba na webu jsou unit testy nedostatečné, je třeba to, že se musí počítat i s tím, že máš CSS, které ti chování taky ovlivňují (např. klikatelnost, viditelnost) a pak, že každý browser to může interpretovat trochu jinak.
    IMHO unit testy jsou velmi vhodné zejména pro business kód, ale pro FE by měly existovat plnohodnotné UI klikací testy. Bohužel to má ten problém, že tyhle testy se typicky blbě a pomalu píšou, typicky dlouho běží (podle rozsahu až hodiny), občas se špatně paralelizují, a nemáš žádné info o pokrytí. Takže na druhou stranu chápu i tlak zkoušet posunout testy níže.
    SATAI
    SATAI --- ---
    VOY: Uncle Bob je posahany dogmatik, Kent Beck (Fowler...) jsou celkem pricetni pragmatici.
    VOY
    VOY --- ---
    Za tu dobu co to delam jsem se stal skoro stejne skepticky k lidem co nuti test first nabozenstvi jako k lidem co prodavaji teplou vodu SCRUMu. Kdyz jsem byl jeste maly developer tak jsem byl vic ochoten verit, ze kdyz udelam do puntiku co mi kaze Bob Martin a Kent Beck tak na konci bude prima software. Bude to i tim, ze jsem si lepe uvedomil, ze vytvareni kultu a nabozenstvi kolem metodik je mimoradne dobry zpusob jak se v tomhle byznysu dobre zivit.
    VOY
    VOY --- ---
    V dynamicky typovanych jazycich to casto poradne nejde bez testu i pro trivialni pripady. Ve chvili, kdy jsme treba do JavaScriptu dostali typy v podobe TypeScriptu tak jsem se zacal trochu ptam sam sebe jestli pro nektery triviality je vskutku nutny psat stovky radku unit testu, ktere casto nedavaji vic nez falesny pocit, ze se nic nerozbije. Naopak investovat poradne do end-to-end testu, coz zpravidla boli vyrazne vic, se obvykle vyplati a pri vetsich prekopavkach systemu davaji vetsi jistotu nez unit testy.

    Za me rozhodne nejaka kombinace pokryti ruznymi testy, ale v zadnem pripade ne honeni % coverage. A pak jsou samozrejme typy kodu a programu, ktere z podstaty vice benefituji a propujcuji se psani unit testu. Pokud jsem mam problem, ktery jsem schopen z vetsi casti implementovat pomoci pure functions, tak je situace urcite jednodussi. O dost horsi je pokud pisu nejaky glue code, ktery vola spoustu ruznych services se side-effecty a ve vysledku je to same testovani jestli se zavolala nejaka metoda na nejakem mocku.
    SUCHRE
    SUCHRE --- ---
    Mam s unit testy tu zkusenost, ze prilisny duraz na unit testy v dusledku vede k tomu, ze nezbyde cas/budget na funkcni testovani celku a vede k releasu ostre verze, co by nemela projit ani jako beta, protoze tam jednoduse prilis mnoho zasadnich chyb.
    SULTHAN
    SULTHAN --- ---
    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.
    JARDABEREZA
    JARDABEREZA --- ---
    Mě hodně baví dělat test driven development, když píšu binární parsery souborových formátů. Tam je to bez testů sebevražda :-D Navíc souborové formáty jsou velmi dobře popsané. Takže rovnou během psaní vidím řádky, které mi právě psaný kód rozbíjí :-D U jiného softwaru je to otázka...
    JARDABEREZA
    JARDABEREZA --- ---
    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š.
    SATAI
    SATAI --- ---
    SULTHAN: Tak ono zase 100% uz je ten kontraproduktivni extremismus. Ale zkusenost rika, ze co se blbe testuje byva blby kod.
    SULTHAN
    SULTHAN --- ---
    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.
    KOLCON
    KOLCON --- ---
    SULTHAN: Třeba Allen Holub říká, že se má testovat, jestli ten kód dělá to, co chce uživatel, a ne každá picovina....
    SATAI
    SATAI --- ---
    SULTHAN:

    - spíše není pravda
    - není pravda (pokud nemáš nějaký obzvláště dementní jazyk, ale to není problém unit testu)
    - když máš křivou hubu, err, framework...
    SULTHAN
    SULTHAN --- ---
    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.
    SUCHRE
    SUCHRE --- ---
    Tady ani nejde o kritiku nejakeho smeru nebo modniho vystrelku, ale jak tak pozoruju, trendum propadaji typove porad ti sami lide.

    Pragmaticky clovek se soustredi na to, aby reseni bylo funkcni, dobre se udrzovalo, popr. rozvijelo, nevyziralo dostupne zdroje a bylo v co nejvetsi mire efektivni. Pak je zbytek, co se neustale neco snazi zmenit, at uz se to tyka pouzite technologie, metodiky, programovaciho jazyka, atp.

    Zatimco diky prvnim by v odvetvi panovala nuda, diky druhym se musime porad neco ucit, neblbneme a diky nutnosti porad neco nekam migrovat je i dost prace pro lidi, co jsou v oboru dlouho a mileradi si to nechaji dobre zaplatit.
    TECHNOBI
    TECHNOBI --- ---
    ANSI barvičky

    MARASAN
    MARASAN --- ---
    Co na tech seznamech zaujalo mne, ze prakticky nic z toho se neuci na fakultě, naopak vsechno, co mne na fakultě naučili, je pořád platný a užitečný. Scary.

    SATAI: ja bych rekl, ze treba i patterns - hlavne ve forme antipatterns, jsou uzitecny.
    KLEINZACH
    KLEINZACH --- ---
    MLEKAR_STEIN: ou je, na to sem uplne zapomnel! a ruku v ruce s objektovym programovanim z toho vznikla CORBA a tam nekde jsme kolektivne usoudili, ze to asi staci, ze sme nekde museli sejit z cesty ;)

    SATAI: jj, jenom se to nesmi prehanet, to je vse
    SATAI
    SATAI --- ---
    KLEINZACH: pritom tak pulka tech veci (zejmena ty unittesty) dava porad velmi dobry smysl a nedelat je je strilet se do nohy
    Kliknutím sem můžete změnit nastavení reklam