Vlákno názorů k článku
Naučte se principy moderního JavaScriptu (školení) od Josef Pavlik - Ja jsem na javascript zanevrel zacatkem tisicileti, kdy...

Překlepy, refaktoring, středníky, nedefinované funkce, to všechno za vás udělá(nebo minimálně vás vyřve) IDE. Na JavaScript WebStorm nebo Idea. Případně VSCode, ale to má refaktoring dost mizerný, osobně bych se v tomhle případě držel JetBrains.

pisete 20 let stare nesmysly, ze vy ste se zastavil v roce 2000 je vas problem. dnesni kompatibilita mezi browsery je na velmi dobre urovni co se tyce ES6 (coz je tp hlavni co chcete pouzivat).

Dale si stezujete na staticke typogani a pak mluvite o preklepechncoz vam bezny linter odchytne.

v js se dnes vsude testuje , juknete na jest.

pokud chcete staticky typovani mate tady stale popularnejsi typescript.

ta poznamka o tom ze se vam ten jazyk tehdy libil ze ma koncept je dost srandovni kdyz vezmu v potaz ze puvodni clovek to napsal za 2 tydny a na internetu je to slavna historka. (vtipnejsi uz snad je jen pan lardof s jeho nepochopenim stringunv perlu a pointeru v c++, a jeho nasledny paksvil php).

ja mam mimochodem doma taky knizku s turbo pascalem a veril byste ze v ni nelistuju dneska uz?

Trochu off topic, ale nedá mi to.

Coby vzděláním strojař vždycky pláču, když někdo začne mluvit o testech jako garanci kvality. Každý inženýr z nějakého "hw" oboru, každý kvalitář, i obyčejný mistr ve výrobě vám řekne: kvalita se nedá vykontrolovat, kvalita se musí vyrobit. Testy a kontrola kvality je jen ověření, že to je uděláno dobře. V oboru SW je teď móda přístup "nemám chuť ani čas to po sobě zkontrolovat, tak spustím testy a uvidím". V oboru HW je něco takového nepřípustné. Představuji si zedníka, co něco nahází do míchačky a pak s tím zkusí postavit kus zdi. A když se to rozpadá, tak teprve pak kontroluje, zda tam není třebas málo vápna nebo jestli nezapomněl na cement.

Navíc si na testech vylámu zuby každou chvíli. Doteď kupříkladu nemáme vyřešený problém, že jedna procedure když dostane v jednom parametru místo 1 nebo 2 hodnotu 3, tak to celé zbuchne na "nemůžete vložit NULL do NOT NULL sloupce X v tabulce Y". A experti autoři se už dva týdny nemohou dohodnout, jak to má být správně. Já jediný co po nich chci je rozumná chybová hláška. Třebas "3 není povolená hodnota", nebo "chybí údaje o zákazníkovi", případně "nelze uložit záznam o stornu transakce". Ne, oni už dva týdny řeší, kde v celém to řetězu volání je chyba. Ten řetěz je zrhuba takhle:

1. Hodnota 3 znamená, že se jedná o ověřeného zákazníka. Procedura ale nemá žádný parametr, kam by se to id zákazníka dalo předat.
2. Procedura volá jinou, pro kterou některé údaje dohledá. Ta už parameter s id zákazníka má, jenže je do něj dáno natvrdo NULL.
3. V kaskádě to dojde do místa, kde se ověřuje kredit zákazníka. Jenže tím, že id zákazníka je NULL, tak nejde nic načíst a vyhodí to výjimku NO_DATA_FOUND.
4. Zpět v kaskádě to odchytne výjimku a připraví si hlášku "Customer credit exceeded". Bohužel to po sobě chce zamést stopy a stornovat transakci. Zavolá to proceduru pro storno transakce.
5. Procedura si načte údaje o transakci, mimo jiné částku transakce. Jenže žádná nevznikla, takže částka je NULL. Pak udělá rollback. Jako poslední se pokusí zapsat do tabulky zamítnutých transakcí informaci o tom, že nějaký pokus byl. No a tam je ten sloupec s částkou, který nedovolí NULL a vyhodí to výjimku. A protože ta kaskáda už je v bloku ošetření výjimky, tak to vyhučí až na klienta.

No a oni teď řeší, která z těch procedur je vlastně špatně a jak upravit testy. Já mám pocit, že špatně jsou úplně všechny. Ta první má odmítnout hodnotu 3, protože zákazníka ani nebere. Ta druhá by měla udělat to samé. Ta kaskáda v bodě 3 by také měla být ošetřena jinak a ne se pokusit o čtení a doufat že o dvě úrovně výše to chytne WHEN OTHERS. Bod 4 nejprve vybere špatnou chybovou hlášku (má být zákazník neexistuje, nikoliv že má vyčerpaný kredit) a pak je také otázkou, proč se pokouší stornovat transakci, o které může vědět, že nevznikla. No a bod 5 je špatně tak nějak úplně - tam má být nějaká kontrola, nebo NVL apod. Tahle procedura prostě nesmí skončit výjimkou, protože tím překryje ty skutečné.

A víte co je na tom nejlepší? Že tihle lidé zkoumají to, jak by se to mělo chovat, nikoliv ze specifikací, ale právě z testů. Nesnáším testy. Ty mají být na build serveru a má to být předposlední linie obrany. To nemá být nástroj programátora v duchu "když to projde, tak dělám push a pull request". Aby tak použít šly, tak by musely testovat všechny možné kombinace. Jenže to nejde, těch je prostě moc. A není to jen o kombinaci vstupních parametrů, ale i o stavu proměnných, záznamů v databázi atd.

Takže ne, i kdyby se lidé na hlavu stavěli, tak tvrzení "v js se dnes vsude testuje" je nepravdivé (testy pokrývají sotva procento možných kombinací) a hlavně to není cesta kupředu. Proč se tolik programátorů odklání od "dvakrát měř, jednou řež" k pohodlnému "uříznu, změřím a kdyžtak to uříznu znovu"? Před 25 lety byl vtip: programátor je člověk, co umí psát, ale neumí číst. Dnes to není vtip, dnes je to realita. Spoléhat na testy, že vám řeknou, kde máte co špatně? Proboha!

Ano, přesně jak píšete.

Testy jsou specifikace. Pro kombinaci vstupů, kde jako typ autorizace je uvedeno 3 (ověřený zákazník) není test, spadne to na hubu a nikdo vlastně neví, co by to správně udělat mělo. Testů je tam hned několik pro 1 (platil cash) nebo 2 (platil kartou), ale pro 3 tam není nic. Přitom je to povolená hodnota uvedená v seznamu autorizačních metod. Jenže právě jak píšete - nikdo to nepokryl testem a specifikaci po 14 letech nenašli. Tak se teď snaží dobrat k tomu, zda tam hodit podmínku, že to nesmí být 3, nebo zda tam doplnit jako parametr id zákazníka. Bohužel netuší, zda by to pak fungovalo. Respektive ví, že to nefunguje, ale netuší, co s tím. Testy to sice úspěšně projde, jenže to neponíží kredit u zákazníka. Což asi chyba bude, tam zjevně chybí volání nějaké procedury, co k zákazníkovi zapíše, že si koupil cosi za XY korun. Jenže kde a jaká? Test nenapoví.

U odrážek 2 a 3 jsme na tenkém ledě právě u lidí, kteří rezignují na typové kontroly, desk checking apod. a spoléhají se právě na pokrytí testy. Dělají to, co píšete - rozlišují, zamýšlí se. Každé dva roky přijdou s jiným testovacím frameworkem. A celé ty roky to stejně probíhá stejně - vrací se jim tickety, protože aplikace padá. Oni dokonce mají 80% ticketů vrácených už při code review. Jejich typická reakce je "opravil jsem překlep a doplnil test". Kdyby to fungovalo, tak by to přece mělo na testech havarovat a počet ticketů, co to navzdory chybám dotáhnou až na code review, nebo dokonce na QA, by měl klesat, ne? Neklesá. Jen roste počet testů, které stejně nijak nepokryjí tu další chybu, co tam zavlečou. Slušně to zabírá snad jen při refactoringu, ale i tam se jim běžně stane, že test projde, přestože aplikace bliká jednu chybovou hlášku za druhou.

Jediné co se časem zlepšuje jsou testy, co dělá QA. Ti mají nástroje co simulují uživatele, klikají, volají API atd. Jenže to je to nejdražší testování. Tedy ne, dražší je ještě testování zákazníkem, ale tam to naštěstí obvykle nedoputuje.

Osobně z toho viním lidi. A pak média a literaturu, která v těch lidech podporují iluzi, že nějaké Unit Testy, System Testy, Integration Testy atd. mohou nahradit kontrolu kódu. A na tom pak staví ještě šílenější konstrukci, že není potřeba nic jako defenzivní programování, protože chyby odhalí už IDE a co ne, to odhalí testy. A to je to, z čeho mě mrazí. Programování stylem "pokus omyl". Proto reaguji tak podrážděně na všechny "od toho jsou testy".

Mas naprostou pravdu Karle, u vyvoje software se obecne na kvalitu kasle nehorazne.

Ale na root si to psat nemel, to si zase vyslechnes pseudomoudra od lidi co ten zpraseny kod pisi ;)

Chtelo by to fakt zodpovednost pro manageri a vyvojare a realne tresty. Kdyz spadne most, take se vysetruje kdo za to muze.

Kdyz nekdo zmrvi software, kdy to treba milion lidi sroji 5 minut casu kazdy, zodpovednost zadna. A prepocitej si kolik je to zivotu.

*kazdy den