Předsudky programátorů vůči psaní unit testů

Teď běží na zdrojáku seriál o PHPUnitu, tak zkus zabrousit do komentářů a nějaký špeky tam určitě ukořistíš :-) Namátkou mě napadá obligátní „zdržuje to“, „zákazníka nám to neproplatí“, „žádné chyby se tím neodhalí“, „musíme přemýšlet o návrhu“ apod.

Nejenom odpověď na tvou otázku, ale taky doporučené čtení

• http://ondrej.mirtes.cz/…i-unit-testu (http://blog.jtimothyking.com/…-tests-first)
• http://www.robertdresler.cz/…e-testy.html

mkoubik: U nás se tyhle penále strhávaly z platů programátora :-D Proto už tam nedělám :-)

Jinak díky za tipy, až bude čas tak PHPUnit vyzkouším. Ale spíš se dřív podívám na Nette\Tester, i když zatím vypadá hodně jednoduchý ;-)

Osobně to vidím zaměřit se na 2 věci:

• lenost/neznalost/nepochopení vývojáře (je to prapůvod všech výmluv, resp. „má to pro mě opravdu přínos?“)
• velká nedůvěra ze strany vedení (@nanuqcz – vypadá to jako sranda, ale to je realita)

Často bývá problém v různorodosti týmu – někdo by testy psal, druhý lautr vůbec neví, která bije. Ono umět psát testovatelný kód znamená psát kvalitnější kód (spouta vývojářů na to prostě nemá, tak to je). Skutečný přínos by měla nějaká opravdová/případová studie – porovnání vývoje aplikace s testy/bez testů. Vím, že je to asi nereálné, ale chtělo by to něco uchopitelného. Něco, co bych mohl uplatnit u vedení.

22: Mě na testování láká hlavně to, že ušetřím svoje nervy. Spustím Unit testy, Selenium, za 5 minut mám kladný výsledek a jdu s klidem spát. (Taková je moje zatím nenaplněná představa :-))

Asi tak, berte to ekonomicky. :) Jsou weby, kde je cena chyb řádově nižší, než cena psaní testů. U takových webů těžko přesvědčíte vedení, že se má testovat (uvažuje-li vedení racionálně). No a na druhé straně stojí weby, u kterých by byla cena vážné chyby tak velká, že se testy zpravidla vyplatí.

Ale to je IMHO jen jeden z mnoha faktorů, který je vhodné zvážit v rozhodování, zda testy psát nebo ne… Celá otázka zda testovat či netestovat je komplexní problém a fakt asi záleží projekt od projektu, tým od týmu…

Jinak, já po pár zkušenostech považuji za snad druhý největší přínos testů (hned po snížení míry chyb) řádově lepší udržitelnost projektu v dlouhodobém horizontu. Také se mi líbí, že spolu s testy vzniká i jakási dokumentace :), nebo minimálně ukázky užití jednotlivých modulů (tříd, chcete-li).

Já jsem velký příznivec testů, ale po počáteční vlně nadšení nyní rozhodně nepíšu testy bez rozvahy ke všemu. Někde to IMHO vážně nemá moc cenu (v tom ekonomickém duchu).

TDD mně osobně moc nenadchlo. Respektive nadchlo :), ale velmi rychle to opadlo. S TDD se mi prostě ani po zaběhnutí nepodařilo dosáhnout produktivity, jako bez TDD… Ale myšlenka super a vynikající výchovný prostředek. Úplně jako staticky typované jazyky. :)

Editoval Tharos (9. 10. 2012 23:42)

22: Já píšu z vlastní zkušenosti, mám projekt, kde je tolik různých závislostí a variací ve výpočtech, že bych si přál mít testy, abych zkontroloval, jestli jsem při zapracování nového požadavku nerozbil něco jiného. Proto se je chystám testy dopsat… ale právě jen na modelovou/výpočtovou část…

něktří to zase vzali jako flame, to není a nebyl účel… v jedné větě, ať ti, co již testy píšou, sdělí proč a co jim to přineslo, nebo naopak, je píší z donucení, kolik času navíc je to stálo nebo ušetřilo.. a klidně ať to porovnají se stavem, kdy se vrátili k aplikaci za rok a měli ji rozšířit.. (což je s nette malý problém, protože jim běží tak maximálně na Nette 2 alpha a to o DI nemělo ponětí), fakt jsem zvědavý, kdo přijde, a řekne, tohle psaní testů mi ušetřilo čas a peníze anebo jestli někdo přijde a řekne, tak díky tomu, že konkurence ani neumí testy napsat, jsem to vyhráli, ale úpřímně, ty testy tam nejsou vůbec potřeba…

tedy jasně pro a proti bez debilních výkřiků o jaderné elektrárně

22 napsal(a):

Jinak mi to osobně připadá přeceněnné, stejně jako DI.. DI přináší jednu jedinou věc, a to je čitelnost kodu pro programátora, který ten kod v životě neviděl a má s ním pracovat dál, jinak je to spoousta práce navíc, kterou na menších a středních věcech právě service locator zpřehlední a 2 – 3 členný tým si s tím v rámci konvence lehce poradí a právě naopak přidaví mrak nesmyslného psaní pro mnohé začátečníky.

Nestahuj tu diskuzi tímhle směrem prosím. Přečti si tohle a dál se bavme o testování.

Všechny ty krásné přednášky, kde si týpek začne psát testy, pak je nechá projít nějakým dummy způsobem a potom už na to nesáhne jsou jenom takového ideologické špičky, je to pouze směr, né cíl. Takový cíl by byl dost hloupý.

Já testy píšu také pouze pro aplikace a knihovny. 100% pokrytí kódu je vskutku paranoia, ale jsou i projekty, kde se to vyplatí.

Samotné TDD je prostředkem k návrhu interface tříd. To samé mohu udělat v presenteru, prostě tam natvrdo nabouchám nějaký ten výpočet nebo logiku a pak to celé přesunu do samostatné třídy, kterou v tom daném presenteru použiju – už vím co jsem potřeboval a mám to implementované, jenom to učešu. Potom se na to dá napsat hezky test a je hotovo.

Testy samotné nemohou být testovány jinými testy, ty jsou testovány kódem, který testují. Pěkná rekurze, že? Tohle je taky důvod, proč mají být testy tak primitivní. Aby bylo vidět na první pohled, když je v nich krpa. Proto taky nikdy nesmíš změnit zároveň test a zároveň kód a proto musíš každý test vidět spadnout.

Když děláš TDD, tak napíšeš test, spustíš a vidíš že neprojde. Tak ten kód implementuješ, spustíš test a on projde. Potom refaktoruješ. Ale vždy musíš skončit se zelenou a vidět testy padat. Když neděláš TDD, tak si můžeš zkusit vložit špatné hodnoty a až potom správné, abys viděl test padat. Tohle praktikuju já a funguje to výborně. Občas si napíšu test-first, ale většinou test-after.

No a co se týče UI, tak to je dost hloupý argument ;) Testy tě doplňují, kryjí ti záda. V žádném případě testy samotné nestačí na kontrolu, že se ti nerozsypala galerie vizuálně. Samozřejmě co se týče html, tak na to máme Seléniové testy. Javascript můžeš taky testovat, abys veděl, že funguje, ale vzhled si musíš ohlídat sám.

Často se mi stává, že vyvýjím třídu v modelu ještě než pro ni existuje presenter/view (např. se čeká na grafika). Když chci pak zjistit jestli to vlastně funguje, tak mam tři možnosti:

1. Napsat si test presenter (a případně i test view), ve kterém dumpuju různé proměnné a návratové hodnoty metod s tím, že ho spustím jen párkrát při vývoji a pak pravděpodobně smažu.
2. Napsat unit testy (což bude trvat asi tak stejně dlouho jako bod 1), které v projektu již zůstanou a budou kdykoliv k dispozici. Navíc nejspíš třídu otestují mnohem lépe než já pouhým dumpováním.
3. Netestovat vůbec a doufat, že se připadné chyby objeví při implementaci view a presenteru.

Který způsob je podle vás nejlepší? :)

22 napsal(a):

… a klidně ať to porovnají se stavem, kdy se vrátili k aplikaci za rok a měli ji rozšířit.. (což je s nette malý problém, protože jim běží tak maximálně na Nette 2 alpha a to o DI nemělo ponětí)

OT: teď jsem koukal na kód bakalářky, kterou jsem začal programovat v roce 2009 a DI tam normálně používám (kromě presenterů, tam používám $this->model = new model();).

Nechci tu moc „flejmovat“. Takže jen čistě a prostě popíšu, proč testuju já a proč nemám 100% coverage (a nesnažím se jí dosáhnout).

Vyvrácení mýtu „testy nikdo nezaplatí“

Řekněme, že do své aplikace doděláváte anketu a najednou zjistíte, že vám to nefunguje tak, jak má.

1. člověk praktikující DDD

Vleze do zdrojáku, přidá někam dump($foo);. Zmáčkne Alt+Tab, aby se přepnul do prohlížeče. Tam dá F5, aby se mu to načetlo znovu. Pak klikne na akci, která nedělá to, co má a zkontroluje dump. Teď zjistí, že v tomto dumpu je všechno ok. Takže se vrátí do editoru, přidá další dump. A opakuje kolečko s Alt+Tab, F5, kliknutím a kontrolou dumpu. Tohle opakuje, dokud mu data s dumpu nezačnou vracet chybnou hodnotu. Pak někde něco pozmění a opět Alt+Tab, F5, klik a kontrola. Tohle opakuje s přidáváním dalších (pomocných) dumpů, dokud chybu neopraví.

Pak vyčistí zdroják od dumpů, commitne a je hotovo.

Nechtěl bych být v kůži onoho člověka, kdyby to celé bylo ještě obaleno AJAXem.

2. člověk praktikující krokování

Vleze do zdrojáků, přidá někam brejkpojt, nastaví pár vačrů, spustí debug. Alt+Tab, F5, klik, Alt+Tab (návrat do IDE) a kontrola hodnot ve vačrech, případně přidání dalších. Pak zabije proces. Opraví něco ve zdrojáku a spustí debug. Zase Alt+Tab, F5, klik, Alt+Tab a kontrola hodnot. Tohle opět opakuje, dokud není chyba opravena.

Pak akorát vyhází brejkpojnty (případně pročistí watchery). Commitne a je hotovo.

3. člověk píšící testy

Vleze do testů. Napíše test, u kterého si myslí, že vyvolá onu chybu. Zmáčkne Alt+F6 (spuštění testů) a koukne, že test prošel. Takže napíše další test. Opět Alt+F6. Opakuje, dokud mu test nezačne failovat. Pak opraví něco ve zdrojáku. Zase Alt+F6. Tohle opět opakuje, dokud test neprojde.

Commit a je hotovo.

V tomto případě ale pomíjím to, že s velkou pravděpodobností tahle chyba nikdy nenastala, protože ji s velkou pravděpodobností (Neříkám že na 100%) pokryli testy daleko dříve, než existoval kód (TDD).

Shrnutí

Co se týká času, který jednotliví lidé strávili nad tímto úkolem. Tak věc se má následovně:

• 1. člověk strávil nad úkolem přibližně stejnou dobu, jako 3. člověk.
• 2. člověk byl nejrychlejší
• 3. člověk má navíc záruku, že se stejná chyba znovu nevyskytne

V příkladu jsem navíc nebral v potaz, že se při různých vstupech může chyba chovat jinak. Otestování různých vstupů má 3. člověk o hodně usnadněné díky testovacím frameworkům, které většinou umí Data Providery (PHPUnit).

Další výhodu má 3. člověk, pokud někdy v budoucnu bude dělat refactoring onoho kódu. Má totiž větší záruku, že se někde něco nepokazí.

100% coverage

Nemám 100% coverage a vůbec mě to nevadí. Jsou totiž části kódu, u kterých zkrátka nevím, jak je otestovat (až to zjistím, tak testy dopíšu). A nebo jsou části kódu, u kterých to postrádá smysl.

Taková ta místa, kde to velmi často postrádá smysl, jsou například „prázdné“ settery a gettery. U nich to je totiž jednoznačně kontraproduktivní. Na překlepy mě upozorní IDE. Stejně tak v případě chybějící závorky nebo středníku (na to mě může upozornit i lint – php -l filename.php).

class Foo extends \Nette\Object
{
	private $bar;

	public function getBar()
	{
		return $bar;
	}

	public function setBar($bar)
	{
		$this->bar = $bar;
		return $this;
	}
}

Zkusil jsem psát testy a trvá to déle než DDD

Jako všechno, tak i psaní testů se člověk musí naučit a musí si to osahat – a to nějaký čas trvá. Pokud jste zkusili týden psát testy a zpomalilo to vaši produktivitu, tak věřte, že to není nic divného. Musíte si to zkrátka vžít. Urychlit to můžete tím, že si objednáte / zajdete na školení.

Závěrem

Pokud píšete špagety a procedurální kód, je více než jasné, že se vám bude testovat hodně špatně. To samé platí i o kódu, který je prošpikovaný neprůhlednými závislostmi (např ServiceLocatorem – $this->context).

Testy vás donutí psát čistší kód. Lepší kód. Pomohou vám odhalit bezpočet chyb (mnohdy ještě před tím, než vzniknou). A hlavně vám v co největší míře pomohou zabránit znovu zanesení již opravené chyby a dodržení zpětné kompatibility.

22 napsal(a):

Tohle je opravdu vlákno, vzhledem i k avizovanému řešení testování „made by nette“, které stojí za to sledovat. Já si myslím a odpověď sám neznám, kdy vlastě začíná mít význam při vývoji webové aplikace, psát testy.. je to rozpočet, project manager, nebo jen nějaký blb, který o tom slyšel a pak při chybě chce slevu? Nebo kdy se vlastně tohle začíná finančně rentovat? To je asi alfa a omega problému. Většina z nás řeší malé a střední weby a vystačí si s Laděnkou, takže co vás nutí vyvíjet aplikace s testy? Uvádějte příklady.. pojďme to rozpumpovat, jestli a kdy má vůbec význam se tím zabývat..

Obecně vzato, pokud nepřemýšlíme o tom, že by jsme u projektu řešili QA, tak nemá ani smysl projekt budovat. Ve výsledku se může předražit a nebo vývoj i přerušit.

Jasně, co malé projekty či stávající kód, který 3 roky běží a nic se nestalo? Features by měli být rozděleny min. do dvou kategorií „must hava“ a „nice to have“ – je dobré se zaměřit na to co je core projektu zvážit – kolik nás to bude stát, když se zde najde chyba – pokud je levnější napsat test, než test opravit – hurá dotoho.

U déle běžících projektů, které jsou tzv. otestovány uživateli, to v rámci stávajícího kódu není finančně výnosné ( psaní testů je investice ) – pokud připisujeme nové features=otestujme je, pokud něco upravujeme, napišme na to test.

Určit kdy a co testovat není zas tak složité.

snake.aas napsal(a):

No osobně unit testy nepoužívám a to přesně z důvodů řečených na začátku (nikdo to neproplatí, zdržuje to). Ale nemyslím to tak, že testy jsou špatné – to vůbec ne.
Ovšem pokud si člověk píše testy sám, tak má pořád tendenci mít trochu „tunelové vidění“
( Prostě ho nenapadne, že by tam mohla jít vložit taková hodnota, která projde a nemá, a naopak )
Ono umět napsat testy dobře je taky tak trochu umění a psát je jenom proto, že „se píšou“ mi nepřijde jako moc dobrý nápad.
Ale jak říkám, unit testy v žádném případě neodsuzuji a věřím, že u nějakého většího projektu (příp. ve spolupráci s více lidmi) bych na nich asi taky začal trvat – prostě je dobré si nechat projet testy u tříd které jsem n nepsal sám a vidět že všechno je v zelené – fakt člověk líp spí :)

Yes!

to je jeden z důvodů, proč ve firmách existuje QA deparment. Programátor by si měl pokrýt test unit způsobem – QA pokrývá testy vyšší úrovně, protože vydí jinak, testuje hraniční hodnoty apod. Je to poměrně stejné, jako codeReview – to je tzv. testy čtyř očí. Kód pošlete do codeReview a kole vám na to napíše doporučení, že mu něco třeba nechodí, něco by šlo udělat lépe apod. Posíláte do codeReview kód, který je dobré zlepšit úmyslně? aby se kolega nenudil? ne :-)

@Patrik

Praktikuji to obdobně. setters a getters se proveri integracne. Settery testuji v případě, že checkujou typ. Testovat by se melo nabizene verejne rozhranni, testuji tedy metody typu public. Nic mene, cas od casu se dostanu i k protected metodam, protoze obsahuji nejakou logiku, co vetveni ( neresim otazku navrhu kolegy ) – zde mi dava smysl, pres public metodu pokryt i protected.

@RDPanek příště to zkus napsat v jednom.

@Patrik Votoček: Na ignorování omáčky se dají použít annotace. Ale jinak moc pěkné shrnutí. +1

Editoval HosipLan (10. 10. 2012 17:01)

Z celé téhle diskuze mám pocit, že většina zaměňuje Unit testy a testy (obecně). Je zřejmé, že těžko budu používat Selenium testy pro knihovnu nějakých výpočtů. Tam bude mít Unit testování největší zastoupení a dále tam bude integrační.
Stejně tak záleží na testování blackbox vs. whitebox. Pokud píšu blackbox, tak na napsané testy už NIKDY nesahám (kromě rozšíření rozhraní). Proč? Protože to nedává smysl. V to případě se totiž jedná o whitebox test a u něj platí, že s úpravou kódu pravděpodobně musím upravit i test.
Osobně si myslím, že se vyplatí testovat jen ty metody, které:

• dělají nějaká rozhodnutí (if, switch, …),
• cyklí přes pole nebo kolekci (for, foreach, while, …),
• provádějí nějaké výpočty nebo
• (jak už napsal RDPanek) kontrolují datové typy.

Poslední bod bych navíc zobecnil na citlivost na datový typ, protože PHP (jak jistě víme) nekontroluje základní datové typy. Tím spíš pokud nějakému argumentu metody dáme jako výchozí hodnotu NULL (a to i když je kontrolován typ). Je pravda, že v takových metodách bývají i podmínky, ale pro úplnost je tady raději uvádím.

Přečetl jsem celé vlákno, opravdu zajímavé a též musím souhlasit s Patrikem opravdu skvěle vystihující a krásně se v tom vidím, bohužel ale v bodu číslo 1 v DDD a zároveň můj stav i krásně vystihuje druhý nadpis Zkusil jsem psát testy a trvá to déle než DDD – zkusil jsem testy, líbí se mi, ale zpomalují mi vývoj resp. bez větších zkušeností mi trvá napsání testu mnohem déle než aplikační kód.

Z počátku bez větších zkušeností člověk prostě neví, jak testy správně uchopit. Pár testů jsem si napsal na několik výpočetních tříd, které si o tyto testy přímo říkali, ale na většinu aplikačního kódu si převážně nedokážu ani představit jak testy napsat. Webové aplikace, které jsem vyvíjel jsou převážně plné exportů / importů, či jednoduše vytažení některých dat z databáze a jejich zobrazení ⇒ tohle je v podstatě problematika většiny webových aplikací → vybrat korektní data z databáze a ty správně zobrazit, a opačně → vzít data od uživatele a ty uložit. Na tomto základě pak unit testy je problematické psát → na databázi se „nepoužívají“ resp. musí se nějakým způsobem mockovat, ale to už pak člověk nemůže moc efektivně napsat test.

V podstatě veškeré chyby vznikají hlavně při výběru nekorektních dat z databáze – úložiště, či naopak špatného uložení dat od uživatele. Takže otázka jak efektivně testovat repozitáře, zda vrátí opravdu korektní data. V praxi bych si to představil leda tak, že bych měl databázi plnou různých dat, a testoval repozitáře zda vrací korektně data. Na druhou stranu můžete podotknout, že tohle by měla hlídat integrita dat, či podobně, avšak jak již jsem uvedl, z praxe hlavní problémy a chyby v kódu, alespoň u mě, jsou že se vybrala nějaká nevalidní data (chybějící podmínka, rozdílný stav, neočekávaná data).