17 komentářů k článku Neprofesionální kód: Když chybí testy a standardy:

  1. Vít Heřman

    Pokrytí testy
    Pod skutečně vše bych se podepsal, až na jedno: Pokrytí kódu testy. Nejsem si jist, zda jste psal o užitečností testů v některých případech nebo jste měl na mysli snahu o maximalizaci počtu testů obecně. Soudě podle literatury a různých školení jsem zcela systematicky došel k názoru, že se až na výjimečné případy smysl testů jakožto jediného řešení kvality nadhodnocuje. Silně typové jazyky, programování odolné nekontrolaným null hodnotám, využívání typovaných struktur a jejich bezpečných transformací, vhodná architektura, vhodné teoretické výpočetní modely jsou nástroje daleko užitečnější, než většina tzv. učebnicových testů. Klasické automatizované testy jsou vhodné až jako řešení, pokud předchozí nástroje nelze použít. Tedy z principu nechci počet takových testů maximalizovat, ale spíše minimalizovat. Přesto v řídících systémech letadel nebo v medicíně nepopírám nutnost maximalizace testů jako nutnou redundanci vzhledem k riziku. V běžném zakázkové software typu administrace nebo webové stránky nikoli.

    1. Vladimir Kloz

      Re: Pokrytí testy
      Je třeba najít určitý balanc – primární výhodu testů vidím osobně v několika oblastech:

      • Pohodlnost budoucích změn – pokud mám testy a rozšiřuji funkcionalitu pak vím, že předchozí záměr zůstal zachován (nebo byl modifikován záměrně)
      • Občas píšeme testy, které developera vedou v rozšiřování funkcionality stylem – fail – zkontroloval jsi tohle a tamto?
      • Lepši struktura kódu – k tomu, aby bylo možné snadno testovat je většinou třeba SRP – psaní unit testů toto enforcuje – samozřejmě používání základních paternů to řeší samo o sobě, ale kolik lidí toto skutečně umí a dělá? S rozmachem IoC kontejnerů se to lepší, ale…
        • Samozřejmě 90% code coverage znamená jen jediné – všechny bugy programátor zamýšlel jako feature a z pohledu uživatele to nic neznamená
      1. Vít Heřman

        Re: Pokrytí testy
        Pokud k tomuto účelu používáte testy, je možné, že:

        • Zatím vývojář nedokáže zadání dobře vyjádřit samotným kódem napřímo. Aneb nějak začne psát kód, až dokonverguje k tomu, aby to dělalo, co chce. Kód pak nereprezentuje přesně to, co je zadáním, ale obsahuje vnitřní konstrukce, které navenek pravděpodobně plní původní záměr, avšak s velkou mírou nejistoty, že správně a s jistotou, že se jedná o zbytečný balast, který by se měk tak jako tak odstranit. A pokud jsou k tomu testy, jsou změny nakonec pohodlné ještě méně
        • Pokud píše testy jiný programátor, tak testy už smysl mohou dávat. Ale nepůjde nejspíš o unit testy.
        • Psaní unit testů skutečně nutí kód k rozkladu. Bohužel často daleko více, než je vhodné. Jak poznám, kdy je rozkladu moc? Podle toho, že pro názvy funkcí/metod potřebuju až příliš velké, podivné a jednoúčelové abstrakce (abstraktní názvy), které nejsou obsaženy v původním zadání. Krom toho snadno degraduje k situaci, kdy jsou napsané špatně testy i kód

        Nic z toho nemusí být Váš případ. Ale už jsem byl nesčetněkrát svědkem toho, co popisuji. Proto mívám v aplikaci testů skutečně málo (řádově jednotky), a to zejména pro složitější knihovní funkce jako např. formátovací funkce, parsery, apod. Ale implementace business procesů a zpracování business dat obvykle testy nepotřebuje. Prostě se rovnou zapisují a když se správně zapíší a jdou zkompilovat, unit test už je pro daný případ nesmyslnou redundancí. Už jen proto, že i zákazník si funkčnost ujasňuje až hotovou implementací a přepisovat k tomu dokola testy je čirý nesmysl.

        Proto tvrzení v článku, že pokrytí testy je znakem profesionality považuji za nesmyslné. Opak je pravdou. Profesionál ví, kdy testy použít a kdy existují lepší způsoby pro zajištění kvality a udržitelnosti.

        1. ivan

          Re: Pokrytí testy
          Souhlasím. Působí to tak, že z testování, užitečného nástroje zodpovědných programátorů, se stává rigidní náboženství kněží. Místo promyšlení nejvhodnějšího postupu pro danou situaci, je tu dogma, které musí být následováno. Kdo nenásleduje, je neprofesionál.

  2. Stano

    Priznám sa, že patrím k tej skupine čo zatiaľ nemá vžité hneď písať testy. Práve tu pod článkom som čakal nejakú diskusiu, prípadne veselé príhody z praxe ktoré by ma presvedčili začať sa tomu venovať :-) No škoda…

  3. Sprostý dělník

    Testy
    Teorie je hezká věc, ale v praxi u nízkorozpočtových aplikací bez nějakého fatálního dopadu při selhání zákazník ty testy prostě nezaplatí. Musíte to napsat dokonale na první dobrou. Chyby vám snižují výdělek.

    1. Daniel Rusnok

      Re: Testy
      Dle mého názoru zákazník nemusí ani vědět o způsobu, jakým přistupujete k vývoji softwaru. Automatizované testy nezdržují vývoj. To už bylo několikrát dokázané. Ano, pokud nejste zvyklý je psát, tak ze začátku to je zdržení, protože to neumíte. Ale tak je to na začátku s každou technikou.

      1. Vít Heřman

        Re: Testy
        To dokázané nejen že nebylo, ale navíc je to obecně nedokazatelné. Maximálně lze prokázat, že v některých případech skutečně ke zlepšení kvality došlo. Klíčové je to slovo některých. A zcela určitě také není pravda, že testování zpomaluje jen toho, kdo to neumí. Také zpomaluje toho, jehož dovednosti jsou na takové úrovni kvality a disciplíny, že přidané testování již kvalitu nezvyšuje. Senior vývojář obvykle umí kód psát s minimální chybovostí, kde nějaká maximalizace pokrytí testy by byla totálně non-sense, je to skutečně dáno dlouhou praxí. Juniora testy mohou lecčemus naučit, ale nemusí to být konečná na cestě k efektivitě…

      2. Vít Heřman

        Re: Testy
        Dal jsem si vaše jméno do Googlu a přečetl pár vašich příspěvků na Dotnetportal. Začal jste testovat teprve před cca rokem a půl. Bojoval jste s tím, že Vás to moc nebavilo. Patrně procházíte klasickým vývojem, kterým jsem prošel také. Dokonce jste uznal, že ne vše stojí za unit testy. Přistoupil jste k rozumnějšímu rozsahu unit testů. Asi jste také začal nově přemýšlet o kvalitě kódu. Pokud v tomto budete pokračovat, dostanete se podle mne dříve nebo později k poznání, které popisuji. Aby bylo jasno, píšu z pozice toho, který se TDD naučil, provozoval a začal postupně opouštět ve prospěch zajímavějších způsobů. Nejde o žádný odpor k neznámému…

    2. Vít Heřman

      Re: Testy
      Taky myslím, že to je správná cesta. A hlavně, dnes jsou už nástroje natolik vyspělé, že mohou maximálně pomáhat napsat to na tu první dobrou. Zbytečné chyby odchytí lint, kompilátor, apod… A před těmi ostatními testy samotné neochrání…

      1. Pavel Kříž

        Re: Testy
        Ahoj Vítku,
        já jsem testy vždycky chápal jako něco, co dělám pro někoho jiného. Pro kolegy nebo svoje budoucí já, které za pár měsíců nebude znát detaily dané funkcionality a nějakým zásahem ji naruší. Řekl bych, že správně napsané testy, v těchto případech, snižují pravděpodobnost, že přidáním nějaké funkcionality rozbiji jinou. Proti tomu se zase asi dá argumentovat schopnostmi vývojáře, který do cizího kódu zasahuje a čitelností/návrhem samotného kódu. To asi ano. Máš s tímto jinou zkušenost?

  4. Stará škola

    Re: testy
    No líbí se mi věta: Lepsi zadny test, nez spatny test.
    Protože špatný test jsou vyhozené peníze. A zobecňování, kdo nedělá testy, je špatný, se mi nelibí. Uvedu 2 klasické příklady. Práce pro zákazníka na zakázku, kdy zákazník přímo specifikuje, co chce vidět, co chce aby kód dělal a pro davy. Pro davy, zde není moc odezva, pokud je odezva, tak v případě negativní odezvy je po produktu. Tedy dovolit si vypustit kód bez testování je sebevražda.
    Pro zákazníka – považuji za nutné minimální testování a stačí testování programátorem. Ten musí spustit a najít chyby. Ale skutečně minimální. Protože:
    – Zákazník myslí A, říká B a programátor rozumí C, pokud do toho vložíte konzultanta, který informaci předává, dostaneme se až k písmenu F … tedy testovat musí zákazník, zda mu to splňuje ono A
    – Při práci se složitějšími aplikacemi (dělám ERP), existuje několik cest, jak nějakou věc udělat. Testeři nikdy nejdou stejnou cestou jak uživatelé.
    – Viděl jste někdo uživatele co testovali? Já znám jednoho, kdo si ten čas najde a udělá to. Většina to nechá na ostrý provoz a pak se diví.
    Byl jsem ve firmě, kde testy byly modlou. Velká spolupráce s auditorkými společnostmi. A jsem statistik. Takže rád věci měřím a analizuji. Výsledek několika let statistik: Pokud na testování věnuji stejný čas jako na programování, eliminuji cca 5% chyb. Nebo lépe řečeno ušetřím 5% z výsledného času oprav. Neboť poměr oprav po testech a oprava bez testů byl ve firmě s rozsáhlým testováním a dokumentací skutečně jen o cca 5% nižší, než následně u nás, kde testy minimalizujeme co to jde. Jen u riskantních věcí. Čas uspořený testováním je ale obrovský.
    A tvorba dokumentace – vždy mě to štvalo, a protože jsem měl možnost změnit kód nástroje na tvorbu dokumentace, zapnul jsem sledování jejího využití. Rok jsem nechal běžet a pak se těšil na výsledky. A lidi jsem do výkazů donutil rozlišovat čas trávený programováním, testováním a tvorbou dokumentace (nebavím se o komentářích v kódu, ale popis funkcionality bokem, help chcete-li). Všem doporučuji sledovat a pak argumentovat. Výsledek. Nad tvorbou dokumentace se strávilo cca 5% z celkového času programátorů. Několik stovek hodin celkem. Počet čtení a vyhledávání – 7. Já z toho 5 (testování mé funkcionality). Vedení okamžitě tvorbu dokumentace zakázalo. Já sám u sebe ji dnes také nepraktikuji. Tak asi tak …

    1. shemale01

      Re: testy
      nemám statistiku rád (podle mě je to pavěda s neúplnými daty), ale to je jedno ;-)

      Jsem rád, že konečně někdo zmínil jak to je. Jsem programátor přes 25 let a ještě jsem nikdy neviděl případ, že by testy byly 100%. Takový test vlastně ani napsat nejde. Možná na nějaké jednoduché funkcionality, ale komplexní testy už budou tak složité, že to opravdu nepokreje přínos psaní testů. Prošel jsem asi klasickým vývojem jako většina programátorů, když jsem je neuměl psát, nesnášel jsem je, pak se to zlepšovalo a dnes od nich opouštím z důvodů, který tu už někdo psal – typování, refaktoring na malé jednoduché části. Testy mám jen opravdu na kritické věci.

      V hodně firmách jsem viděl testy typu assert(true), takže výsledek byl sice „PASSED“, ale test je k ničemu. Nebo se otestuje jen jeden případ.

      Rozhodně se nemohu ztotožnit s názorem „Ten, kdo nepíše testy, není profesionál“. Za mě mi to přijde fakt směšné a spíše opovrhuji člověkem, který si toto myslí… :-D To je jako bych řekl, neprogramátoři jsou looseři… Nebo, že Ti co používají odsazování pomocí tabu, že jsou amatéři… Profesionalita se rozlišuje podle jiných kritérií a testy nebo jejich kvalita či počet nemá na to vliv.

  5. L.

    Jak už napsali předřečníci teorie je jedna věc a praxe druhá.

    Psát kód pro kolegy a ne pro počítač je jistě dobrá myšlenka. Jenže coding standards jí nijak zvlášť nepomáhají. Protože „přehlednost a pochopitelnost“ se těžko nějak definují. Takže to většinou skončí u formalit typu „Za IF a ELSE nesmí být jednotlivý statement, ale musí tam vždy být blok“. Pro zajištění takových standardů se většinou použije nějaký automatický formáter a často se dokonce v CI kontroluje, že jím máte kód opravdu zformátovaný.

    Jenže pak nastane situace, kdy v kódu máte pole strukturovaných položek (typicky objektů) a pro přehlednost samozřejmě chcete, aby byly všechny naformátovány jednotně. Jenže jejich obsah má různou délku, takže automatický formátter některé z nich naformátuje na jeden řádek a jiné na několik řádků. A přehlednost jde do p**, coding standards tak přehlednosti kódu naopak škodí. To není žádný umělý příklad, to se mi několikrát stalo v praxi.

    Ohledně testování tu už bylo pár příspěvků napsáno a jen je potvrzuji. Automatické testy mohou pomoci, ale nedá se z nich dělat modla. Samotná coverage a úspěšné testy nic reálně nezaručují. Jsou věci, které se automaticky testují lépe a ty, kde automatické testy moc smysl nemají. Snad jediný poznatek co ještě nezazněl: Dobře se testují čisté (pure) funkce a programátor by se měl snažit je psát, kde to dává smysl. Pak budou i automatické testy efektivnější.

    Na konec jsem si nechal bonbónek největší: code review. Teoreticky dobrá myšlenka. Reálně ale programátoři tráví hodiny a hodiny debatami o formalitách, které mají naprosto minimální reálný dopad. A i přes spoustu času stráveného na code reviews do programu klidně projde prasárna, pokud není vidět na první pohled. Není to zkušenost z jedné firmy, ale z několika různých, lidi jsou prostě lidi. Plus code reviews znamenají nutnost přehazování kontextů (autor než čeká na PR nesedí se založenýma rukama, ale dělá něco jiného, hodnotitel buď přeruší práci, nebo dílčí úkol dokončí, ale to zase znamená velké zpomalení vývoje). Tahle nutnost přepínání má také negativní vliv na výkon.

    Co s tím, přiznám se, moc nevím. V některých případech jsou PR dobré, typicky u nováčků nebo když někdo hrabe (i) do něčeho, čemu úplně nerozumí a někdo jiný ano – tak mu dá kód na review. Ale cena za ně je opravdu hodně vysoká.

  6. Peter Humaj

    Testovanie a prehladnost kodu
    Zdravim vsetkych,
    nie som cisty IT, ale robim v oblasti automatizacie. Uz 16 rokov vyvijame SCADA/MES system, ktory zacal v 1993 v jazyku Modula-2 na OS/2, neskor (1998?) premigrovany do jazyka Ada na Windows NT. Momentalne platformy Win32/Win64/Linux/Raspberry.

    Pisem novy kod (prevazne komunikacne ovladace) a udrzujem kod po kolegoch (niektori uz nie su vo firme). K udrzovatelnosti podla mojho skromneho nazoru (popri kulture programovania) znacne prispieva prave pouzitie jazyka Ada. Predtym som bol C-ckar, co je jazyk umoznujuci v porovnani s Adou neskutocne kompaktny zapis, ktory vie byt neskutocne chybovy, neprenositelny a necitatelny.

    V Ade sa clovek viac napise, ale zase sa to ovela lepsie cita ako C-cko. Navyse Ada chrani pred roznymi blbostami typu pristup za hranice pola, typova kontrola a podobne.

    Co sa tyka testovania – zase, v oblasti komunikacii sa daju robit „nejake“ unit testy, ale tie najzaujimavejsie chyby su spojene s realtimom a najlepsie sa odladia na produkcii. Bohuzial. Takze aj kod, ktory vo firme alebo u jedneho zakaznika funguje, moze mat problemy a skryte vady, ked sa bavi s niecim inym. To je zivot. Snazit sa vsetko 100% otestovat pri vyvoji by bolo jednak nemozne, jednak prilis drahe. Dolezitejsie je, ze vieme pri nabehu komunikacii chyby rychlo najst a opravit (rychlo sa mysli, ze spravim patch do hodiny/dvoch, v horsich pripadoch do niekolkych dni).

    Niektore chyby su potvory – sam som opravoval chyby (po sebe), ktore boli v 10-rokov starom kode a prejavili sa v specifickej konfiguracii. Najst toto pomocou testovania – sorry, bez sance.

  7. jakub

    Testy ze správné strany
    Obávám se, že článek nedělá testům příliš velkou službu, protože stejně jako software je nástrojem na zvýšení efektivity lidské činnosti, tak testy jsou kontrétním softwarovým nástrojem na zvýšení efektivity lidské činnosti programátora. A stejně jako není efektivní používat software při sázení stromů do země, není potřeba mít test na každý vývoj softwaru.

    I ta úvodní metafora v tomto pokulhává, protože právě medicína je dobrým příkladem, kde se spíše s testy výrazně cílí a šetří. Když stejně jako dalších X milionů lidí v ČR letos chytíte rhinovirus (nachlazení), tak vás nepošlou na testy všech nemocí, které mají podobné příznaky, ale domů, ať pijete teplý čaj. A i když jsou testy na kdeco, tak test na (doplňte si vlastní nemoc počátečními symptomy podobnými nachlazení) se plošně neprovádí, protože je nákladný a má nějaké procento false positives (a to si myslím, že zdaleka ne tak velké jako testy softwaru).

    Ten problém vidím ve větě „…považuje v roce 2019 psaní byť jenom unit testů za zdržování a otravný úkol…“. Já se naopak snažím prosadit směr opačný – první a nejdůležitější je akceptační test zákazníka, aneb „jak poznám, že je výsledný software užitečný“. Tento test je vlastně větší kus zadání. Je-li některá úroveň testování ta kritická, tak je tato úroveň.

    A jako další věc teprve řeším automatizaci tohoto testu. Nepokouším se ohnout co se testuje, jenom proto, abych mohl test automatizovat.

    Až mám toto, řeším další úrovně testování. Testy UI bývají důležité v mém zaměření (webové aplikace), kde je sice krásné, že funkce spočítá DPH správně, ale celá ta věc je trochu nanic, když uživateli chybí pole pro zadání sazby DPH (klasická stižnost „to mělo přece programátora napadnout!“). Užitečné se mi v praxi ukázaly automatizované integrační testy na webové služby – nepříjemně často někdo mírně rozbije rozhraní na druhé straně, což se špatně poznává.

    Jednotkové testy se sice dobře ukazují v tutoriálech, ale pokud zrovna není programátor součástí technologického startupu, tak bez zajištění těch výše zmíněných vyšších úrovní si obsah jednotkových testů cucá z prstu.

    To se naneštěstí někdy děje, i když ty akceptační testy napsány jsou. Což je jedna z těch tragičtějších věcí, co jsem viděl v praxi – nový kus kódu, u kterého projdou všechny jednotkové testy, ale zkusil jsem provést první krok z akceptačních kritérií, a zobrazuje se jiný než očekávaný výsledek.

    Navrhuji tedy alternativní část neprofesionality k řešení v roce 2020 – pokrýt kód akceptačními kritérii.

Napsat komentář

Tato diskuse je již příliš stará, pravděpodobně již vám nikdo neodpoví. Pokud se chcete na něco zeptat, použijte diskusní server Devel.cz

Zdroj: https://www.zdrojak.cz/?p=23456