Komentáře k článku

Jak na TDD v JavaScriptu

O problematice TDD toho bylo napsáno již hodně, proto si v tomto článku jen osvěžíme nějaké základní pojmy a ukážeme si, jak aplikovat tuto metodu na konkrétním příkladě napsaném v JavaScriptu za pomocí testovacího frameworku Mocha a knihoven Chai, Sinon.

Zpět na článek

20 komentářů k článku Jak na TDD v JavaScriptu:

  1. Petr

    To mi tedy přijde jako šílená blbost a neuvěřitelné plýtvání časem, abych testy prokazoval nedostatky o kterých vím. A ještě takto inkrementálně. Možná je to dobrá metoda pro cvičené opice v indii, nevím, ale pro inteligentního vývojáře tohle podle mě není.

    1. Martin Hassman

      Re:

      Tak ten příklad byl záměrně jednoduchý, to jistě chápete.

      Nicméně zdá se vám, že tímto postupem opravdu otestujete jen příklady, o kterých víte? (Tip: Uvažujte v čase. A rozsahu.)

      1. V.Novák

        Re:
        Mně to taky přijde trošku přes ucho – když vím, že test neprojde, protože jsem ještě nenapsal to, co testuje, tak nemá vyýznam ho spouštět, ne? Dopíšu i testované – a PAK pustím testy, které mně otestují, co jsem napsal.
        Klidně začnu testama, určitě jsou výborné, pomůžou s definicí, když se budu snažit udělat je pořádně a budou se hodit až za půl roku udělám nějaké změny – a ony přes x, y, z a bflm, psvz ovlivní můj dnešní kód – ale testovat to, o čem vím, že ještě není…

        1. Martin Hassman

          Re:

          Hmm, myslím že teď jsme (snad) narazili na to nedorozumění, resp. na rozdílnost přístupu. Netestujete, co není. Vím, vypadá to tak (a můžete k tomu i tak přistupovat, ale pak celý proces popsaný v článku opravdu nemusí dávat smysl), vy totiž testujete to, co bude. Píšete test na to, co má vzniknout a s vědomím, že to (nejspíš brzy) vznikne a vy ještě než to vznikne pomáháte kódem zajistit (specifikovat/zkontrolovat), že to vznikne správně. Pokud tuhle premisu přijmete, na celý proces se budete dívat jinak. Nepíšete test, protože teď spadne, ale protože (za chvíli) projde. Ale je to o přístupu, pokud tuhle myšlenku nepřijmete, tak tu výhodu zřejmě neuvidíte a pak budete mít (svou) pravdu, že to (vaším pohledem) děláte zbytečně.

          Vím, je to příliš filosofické, jinak to ale nevysvětlím. Rozlousknout by to mohla nějaká tvrdá data. Jak kvalitní kód vzniká, když tenhle postup “testy first” používáte vs. když ne. Nikdy jsem nehledal, zda existují, počítám že někdo to už mohl zkoušet zkoumat (měřit). Třeba se někdo přidá vhodný odkaz.

          BTW to že test neprojde, když nemá projít, netestuje onen nenapsaný kód, ale onen hotový test. Test nyní nemá projít, ale napsali jsme ho dobře? To nejmenší co proto můžeme udělat je ho spustit a sledovat, že opravdu selhal. Časová ztráta minimální.

          1. tacoberu

            Re:
            Já si s tebou dovolím nesouhlasit :-) TDD je o tom, že napíšeš testy pro kód tak, aby až někdy v budoucnosti ten kód změníš/odstraníš, tak aby sis toho všiml. A toho tím, že nenapíšu test abych prokazoval nedostatky o kterých vím nedosáhnu. A když to nebudu psát inkrementálně, tak vždycky něco přehlédnu.

            1. Martin Hassman

              Re:

              TDD je o tom, že napíšeš testy pro kód tak, aby až někdy v budoucnosti ten kód změníš/odstraníš, tak aby sis toho všiml.

              Ano, v tom se shodneme. Zbytku komentáře ale nerozumím 8-)

        2. Jarda

          Re:
          Martin Hassman už to trochu napsal, ale já to chci zdůraznit. Hlavním přínosem pro mě je, že si můžu být jistý, že nemám false positive testy. Mnohokrát se mi stalo, že jsem měl chybu v kódu a test si krásně procházel a byl zelený. Protože jsem udělal v testu chybu, anebo jsem testoval něco jiného než jsem si myslel, že testuju.

          Tím, že nejprve napíšu test první, poté si zkontroluju, že test neprochází a je červený. Teprve poté napíšu kód a přesvědčím se, že jsem opravil ten červený test.

          Navíc pokud použiješ nějaký watcher, tak se testy spouští samy a vůbec nemusíš řešit časovou ztrátu. Na jednom monitoru konzole, na druhém editor. Uložím soubor s testem, testy se spustí a jsou červené, žádná časová ztráta, jen se stačí podívat jak to dopadlo.

        3. Jirka

          Re:
          Zde jde o ověření správnosti testu. Kdyby to bylo jak píšete vy, riskujete následující scénář:

          1. Napíšu test. (třeba expect(true).isTruthy())
          2. Napíšu funkčnost, která ale dělá úplně něco jiného
          3. Pustím test a on projde
          4. Kód ale dělá něco úplně jiného, než jsem čekal

          Proto se prvně píše test, který selhává. Tím vidím, že je potřeba nová funkčnost (nebo úprava stávající).
          Ve chvíli kdy test prochází, vím že mám „hotovo“.

      2. Jirka

        Re:
        Z vlastní zkušenosti vím, že to je právě ta „chyba“ tutoriálů. Jsou moc jednoduché, příjemcům to pak připadá zbytečné. Osvědčila se mi metoda školení tak, že účastníkům připravím nějaký již existující „projekt“ a chci po nich přidání / změnu funkčnosti.

        Má to několik výhod:

        • Odstíním je od problému „jak vše zprovoznit“. (Zprovoznit v tu chvíli znamená git clone; npm install)
        • Nesvádí je to k „To je jednoduché, proč bych pro to měl psát test?“
        • Většinou pak příjemce přijde na to, že testy lze vnímat jako „dokumentaci“

        Stále ovšem bojuji s tím, abych příjemce přesvědčil o tom, že testy nejsou časově náročné. Máte nějaké zkušenosti, případně i rady?

        1. Ondřej Novák

          Re:
          Já stále považuji psaní testu dopředu jako zbytečně časově náročný úkol. Zvlášť pokud jde o nějaké prototypovaní a hledání cesty vývojem. Typická ukázka: napíšu testy. Začnu psát kód. Počas psaní kódu zjistím, že je to totální ptákovina a projekt smažu (opustím). Škoda času na testy. V mém případě je nadpoloviční počet případů jak vývoj začíná. Pokud překonám tuto první fázi, vznikne funkční prototyp. Na něj napíšu testy a začnu ho leštit a vylepšovat

    2. suwer

      Re:
      TDD predevsim neni vhodne pro prototypy, kde si programator ujasnuje dalsi postup. Naopak je vice nez vhodne pro psani ostreho kodu. A tady casto vznika nepochopeni mezi zastanci a odpurci TDD :-)

      1. Franta.

        Re:
        To spíš naopak, ne? Podle mě je hlavní nepochopení to, že unit testy se píší proto, abychom věděli že kód funguje. K tomu ve skutečnosti slouží integrační a end-to-end testy. Unit testy jsou od toho, abychom kód dobře navrhli a dal se v budoucnu udržovat. I když programátor unit testy po dopsání kódu smaže, tak mají smysl.

        1. suwer

          Re:
          Jak sam pises, unit testy slouzi pro spravny navrh objektu (unit). Ale o tom prototypovani vubec neni, proto je zde TDD nevhodne. Pokud uz existuje priblizne jasna myslenka a zacne se skladat ostry kod, tak prichazi chvile TDD.

          Unit testy urcite nedoporucuji mazat. Pro budouciho vyvojare je to prvni a nejrychlejsi moznost, jak pochopit kod a jak si otestovat svoje zasahy do nej. Pak nasleduji IT testy, ktere z podstaty mivaji radove narocnejsi spousteni. E2E testy uz pokryvaji konkretni business casy a samozrejme zaberou asi nejvic casu.

  2. uetoyo

    Co bude příště?
    Pěkný článek. Nejdřív jsem přehlédl odkaz na github, takže jsem chtěl lamentovat, že by bylo dobré někde napsat, jak to workflow vlastně zprovoznit :) Nicméně bude příště popsané jak zapojit webpack, babel atd.?
    Dík!

    1. Oldis

      Re: Co bude příště?
      no to asi snad neni ani potreba, devstacky existujou, treba este, ale to je uz v utlumu protoze vznikla alternativa

  3. Tomáš DusíkAutor příspěvku

    RE
    Díky. Příští článek bude rozebírat Mocha, Chai a Sinon více dopodrobna. Co se týče babelu a webpacku tak na rozjetí testů nebyl potřeba a asi se nechystám do toho nějakým způsobem zapojit webpack/babel.

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=20733