Přejít k navigační liště

Zdroják » PHP » Testování a tvorba testovatelného kódu v PHP

Testování a tvorba testovatelného kódu v PHP

Články PHP, Různé

V tomto seriálu se podrobně seznámíme s problematikou testování kódu v PHP, a to od úplných začátků po pokročilé metody testování integrace, mockování a další.

Proč vlastně testovat?

Odpověď je nasnadě – kód píší lidé a lidé chybují. Jsem si vědom toho, že touto větou jsem se jistě citelně dotkl ega některých čtenářů, ale berte to tak, je to pravda. Ano i vy, i kolega sedící vedle vás, za vámi, před vámi, všichni chybujeme. Příčin chybování je obrovské množství. Jsme unaveni, nemáme dobrou náladu, někdo nás vyrušil, chvátáme domů, přecenili jsme svoje síly, šéf či kolega nás vytočil, atd. atp. Dovolím si tvrdit, že počet všech možných situací, které mohou vést k chybě v kódu, se limitně blíží nekonečnu.

Bohužel i přesto, že s předešlým odstavcem drtivá většina (nejen) programátorů souhlasí, je občas obhajoba přínosu testování podobná boji s větrnými mlýny. Je to škoda, protože tato diskuse by měla znít spíše opačně – ti, kdo se testování svého kódu nevěnují, by měli věrohodně obhajovat proč tak činí.

Proč netestovat?

Za celou dobu, co se v PHP zabývám testováním a vůbec tvorbou testovatelného kódu, jsem posbíral několik zajímavých anti-testing argumentů:

1) žere to moc času…

… který můžu raději věnovat psaní kódu. Toto je asi nejčastější z nich a zaznívá tak půl na půl z úst programátorů a managerů. Těm prvním „se to nechce psát“, ti druzí nechtějí čas, který zabere psaní testů, platit. Ano, tvorba testů zabírá určitý čas, ale tento čas je investicí, která se zatraceně vyplácí. A tím nemyslím jen fakt, že veškeré chyby jsou objeveny a opraveny včas, často ještě před prezentací produktu zákazníkovi. Myslím tím i to, že testy jsou jakýmsi průvodcem tvorby kvalitnějšího kódu. Čím více času investujete do psaní testů, tím méně potom budete potřebovat na refaktoring, který si vyžádá nějaká změna.

2) ještě na to nebyl čas

Celou větou – my víme, že je to správné, ale zatím jsme se k tomu nedostali. Touto větou se budete hájit tak dlouho, než si uděláte opravdu velkou ostudu. A jen ostuda to bude v tom lepším případě. I když může vyústit v diskreditaci firmy, pro kterou pracujete. Nedokážu si představit, jak původní větu přetavit ve smysluplnou omluvu faktu, že účetní data e-shopu, který jste programovali, je možné kompletně vyhodit. Finanční úřad nepatří mezi ty chápavé a laskavé.

3) kód mé aplikace je příliš složitý

Snadná odpověď – pak je ten kód špatný. Dobrý kód = testovatelný kód. Zjistíte to velmi záhy, když budete potřebovat provést nějakou netriviální změnu. Ego „příliš složitého“ kódu pro testování bude rázem pryč a vy se budete potit při rozplétání nekonečné pavučiny závislostí.

4) snad vím, co dělám, ne?

Pozor, vstupujete do nebezpečné skupiny programátorů „všeználků“. Toto si ani nezaslouží komentář. Pokud máte v týmu podobně světového člena, zbavte se ho, o jeho výtvory se pak budete muset starat sami.

5) je to nuda

Věřte, že není. Nejen, že budete nuceni občas překonávat skutečně záludné překážky, ale jakmile si testování zažijete, záhy zjistíte, že díky němu píšete lepší kód. Jestli vám ani jedno nic neříká, pak pracujete ve špatném oboru.

Určitě zaslechnete i mnohé další anti-argumenty, jednou společnou radou proti nim by mohlo být – řiďte se vlastním úsudkem a vlastním svědomím. Pokud se rozhodnete pro cestu testovatelného kódu, nebudete litovat.

Druhy chyb

Tak jako každé rozsáhlejší téma, i testování vyžaduje určité teoretické znalosti, o které se v budoucnu budete moci opřít. Tento, úvodní, díl seriálu bych proto chtěl věnovat výtahu toho, co považuji okolo testování za nejdůležitější. Nejprve se pojďme podívat s jakými protivníky budeme mít tu čest.

Syntaktické chyby

Neboli prohřešky proti syntaxi jazyka – chybějící středník, závorka, … Tyto chyby jsou jedny z „nejhodnějších“, protože vás na ně upozorní už kompilátor a díky tomu nepůjde kód vůbec spustit. Tudíž nebude moci napáchat žádné škody.

        echo "foo"
        echo "bar";

Sémantické chyby

Prohřešky proti sémantice jazyka. To je například špatné pořadí parametrů, špatný typ parametru apod. Tady už je situace horší. Ve většině případů nás na podobné chyby upozorní nějaká varovná zpráva nebo upozornění za běhu, ale to už bývá zoufale pozdě. Nehledě na to, že můžete mít zobrazování těchto zpráv potlačeno. Tyto chyby už mohou napáchat opravdu velké škody.

        $joinedValues = "one, two, three";
        $separateValues = explode($joinedValues);

Logické chyby

Jedny z nejhůře odhalitelných chyb, na které ve velké spoustě případů nebudete nijak upozorněni a jejich řádění může mít fatální následky. Patří sem chyby v cyklech (nedostatečný nebo přílišný počet iterací), chybné používání operátorů, neúmyslné přetypování proměnných a mnohé další.

        $values = array(1, 2, 3, 4, 5);
        for ($i = 1; $i < count($values); $i++) {
            echo $values[$i];
        }

Pomineme-li syntaktické chyby, které jsou nejsnáze odhalitelné, na oba nebezpečné druhy chyb bychom měli být dobře připraveni a v ideálním případě být schopni je odhalit ještě před ostrým spuštěním kódu. A to je přesně ta chvíle, kdy na scénu vstupují naši nejlepší kamarádi jménem testy, které nás na podezřelý kód včas upozorní. Pokud ještě navíc přeruší proces nasazení kódu do produkčního prostředí, tak jen lépe!

Úrovně testování

Jednotkové testy

Nejnižší možná úroveň, zde testujeme izolovaně a samostatně jednotlivé třídy. Na této úrovni nás zajímají především správné návratové hodnoty metod v závislosti na vstupních parametrech. Při jednotkovém testování bychom se měli snažit o maximální izolaci testované jednotky, měli bychom se vyvarovat:

  • volání metod jiných skutečných tříd
  • přistupování k síti (internet, intranet)
  • používání databází
  • používání filesystému
  • atd…

Pro simulaci těchto činností se používají falešné objekty, které nevykonávají žádnou skutečnou činnost, pouze splňují nějaké požadované rozhraní. Tyto objekty se označují jako „mocks“ nebo „stubs“ (příp. ještě „fakes“) a bude o nich řeč později.

Integrační testy

Na této úrovni testujeme, jak spolu naše třídy nebo moduly navzájem spolupracují, testujeme, zda jeden modul splňuje požadavky jiného. Oproti jednotkovým testům zde už můžeme používat databázi, filesystem apod. protože nám jde především o testování spolupráce. Jako příklad integračního testu si můžeme představit test, který nám ověřuje funkčnost nového modulu, který pracuje s CouchDB namísto původního MySQL.

Funkční testy, akceptační testy

Nejvyšší úroveň testování, která se mnohdy odehrává na úrovni GUI, testujeme korektnost chování celé aplikace. Funkční testy jsou většinou automatizovány pomocí nástrojů jako je Selenium, Squish a jiné, akceptační testy mohou být i manuální a provádí je produktový manažer nebo zástupce zákazníka.

Regresní testy

Regresní testy nejsou samostatnou úrovní testování. Důvod je prostý – regresní testy mohou prostupovat všemi úrovněmi testování. Jejich významem je testování úspěšnosti opravy nalezené chyby a hlavně – její neopakovatelnosti. Pokud nalezneme v kódu chybu, pak v ideálním případě bychom měli nejprve napsat test (regresní test), který bude umět chybu vyvolat a teprve potom chybu opravit. Jen tak budeme mít jistotu, že chyba je opravena správně. Kromě toho nám regresní test bude hlídat, že si chybu do kódu nezavlečeme znovu (např. jinou úpravou nebo opravou jiné chyby).

Metody testování

Kromě úrovní testování existují i metody jak testovat, resp. jak přistupovat k testování.

Blackbox testing

Jak už název napovídá, testujeme jakoby černou skříňku. Známe pouze veřejné rozhraní této skříňky a ověřujeme, zda dělá to, co má. Zdrojový kód neznáme. Tato metoda se hodí na testování od úrovně integračních testů výše. Na unit testy není moc vhodná, protože bez znalosti zdrojového kódu nebudeme schopni metody pokrýt dostatečným množstvím testovacích případů.

Whitebox testing

Testujeme přímo kód třídy nebo konkrétní metody. Pokud nepostupujeme metodou Test-driven development (nejprve píšeme testy a kód až následně), tak píšeme testy „na míru“ kódu, tzn. snažíme se o co nejlepší pokrytí kódu testy. Už z předešlé věty je jasná největší nevýhoda této metody („pasujeme“ testy na kód, takže můžeme leccos přehlédnout), ale i přesto bych ji pro unit testy doporučil více než blackbox testing, protože při znalosti kódu jsme schopni vytvořit mnohem více testovacích případů, protože jednoduše vidíme, co metoda dělá.

Pravidla pro testy

Jak se říká – to nejlepší na konec – poslední důležitou kapitolou, kterou bych v tomto úvodním díle rád uvedl, jsou pravidla pro psaní vlastních testů. Tato sada pravidel má pět částí a souhrnně se označuje jako „pravidlo F.I.R.S.T.“ a měla by pro vás být alfou a omegou. Jak si totiž ukážeme později, na mnohá další pravidla a principy dobrého návrhu přijdeme díky této pětici víceméně sami.

Fast – rychlé

Testy by měly být rychlé. Budou-li vaše testy trvat dlouho, pak se vám ani dalším vývojářům nebude chtít je spouštět. A pokud je nebudete spouštět, pak vám nebudou k ničemu.

Independent – nezávislé

Testy by měly být nezávislé – nejen samy na sobě, ale také na prostředí, ve kterém jsou spouštěny. Nesmí dojít k situaci typu: test A nastaví podmínky pro test B, jinak test B neprojde. Závislost testů také může způsobit lavinu „failů“, ze které bude poměrně složité určit prvotní příčinu selhání.

Repeatable – opakovatelné

Stejně jako nezávislé, tak by testy měly být i opakovatelné. A opět – měly by být opakovatelné v jakémkoli prostředí. Test, který dvakrát projde a potřetí selže, je k ničemu.

Self-validating – samovyhodnocující

Za tímto pravidlem se skrývá prostá myšlenka – test by měl buď projít nebo selhat. Žádné romány v konzoli nebo v logu, nad kterými budete trávit hodiny, abyste stanovili, zda test prošel nebo ne. Buď OK nebo FAIL, nic jiného.

Timely – aktuální

Testy bychom měli psát (když ne ještě před vlastním kódem) co nejdříve po napsání ostrého kódu. Jen tak budeme schopni „stíhat“ sledovat, co se v kódu odehrává. Psát testy dodatečně s odstupem několika měsíců opravdu není nijak příjemná práce, nehledě na výslednou kvalitu testů.

Ač tato pětice pokrývá většinu potenciálních problémů, dovolil bych si ji ještě rozšířit o vlastní doporučení:

Krátké

Testy, konkrétně jednotlivé testovací metody, by měly být co nejkratší. Jednak se nikomu nebude chtít studovat test zabírající desítky řádek, kromě toho, jsme-li nuceni vytvořit test, kde desítky řádek slouží k nastavení prostředí pro běh testu, pak zaručeně porušujeme nějaké pravidlo dobrého návrhu nebo dobrého testu (viz. F.I.R.S.T. výše). Puristé tvrdí, že testovací metoda by měla obsahovat pouze jeden assert. To je už malinko extrémistická myšlenka – dovolím si tvrdit, že při tomto přístupu velice brzo narazíte na jeden ze dvou skutečně nejsložitějších problémů v IT – pojmenování (druhým je cache-invalidation :-).

Prosté

Testovací metody by neměly obsahovat žádnou řídící logiku. Mám na mysli podmínky, cykly, apod. Pokud test obsahuje logiku, pak je vysoká pravděpodobnost, že budeme mít chybu v testu, a to je, jak už jsme si řekli, nejhorší, co se nám může stát.

Na téma psaní dobrých testů by se daly napsat celé obsáhlé knihy, ale tím bychom se dostali daleko mimo rámec tohoto seriálu, který vás má především seznámit se základy testování v PHP. Příště už to bude trochu zábavnější a podíváme se na základy práce s testovacím frameworkem PHPUnit.

Komentáře

Subscribe
Upozornit na
guest
34 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
5o

Zacina sa to dobre, konecne nieco poriadne pre PHPckarov na zdrojaku.

anonym

také to ve mne vzbudilo naděje: testování uznávám jako přínosné, ale vždy se najde spousta věcí, u kterých si neumím testy vůbec představit. Doufám, že mne tenhle seriál dokope se na to konečně vrhnout a v nějakém projektu vyzkoušet.

Tharos

Díky za fajn článek a přeji hodně vytrvalosti do dalších dílů. Neodpustím si jedinou oponenturu, a to k tvrzení:

„A tím nemyslím jen fakt, že veškeré chyby jsou objeveny a opraveny včas, často ještě před prezentací produktu zákazníkovi.“

To, že díky psaní testů budou veškeré chyby objeveny a opraveny včas, je IMHO utopie. :)

Aleš Roubíček

Souhlas. Hlavně úplně špatná motivace a nesmysl.

Testy píšeme proto, abychom byli co nejrychleji informováni o tom, že se rozbilo/ něco, co před tím možná fungovalo. Nebo že to funguje jinak než test očekává. Pokud píšeme testy napřed (TDD), je možné, že náš kód bude jednodušší a tím se může snížit i výskyt chyb.

Michal

Je hodne duvodu proc. Ja treba pisu testy protoze jsem linej.
Dokud se web musi rucne proklikavat aby se zjistilo, jestli „ten posledni update nerozbil zase ten form co posledne“, neni u me hotovo.

Behem 2. mesice na projektu uz se testy brutalne vraci v case a hlavne energii.
Proklikavani a hledani chyb manualne je jednou z nevjvice vycerpavajicich praci na projektu a denni energie kazdeho programatora neni nevycerpatelna.

Mimoto se mi uz stalo ze me testy odhalili spoustu chyb, ktere jsem nemel sanci odhalit a 100% by na produkci prolezli.
Neni nad to upgradnout php, spustit testy a vedet, ze ho muzu s klidem upgradnout na produ.

Michal

Sorry za ma cecha ;-)

Sadam
$values = array(1, 2, 3, 4, 5);
for ($i = 1; $i < count($values); $i++) {
  echo $values[$i];
}

Neresim ted to ze :

--for ($i = 1; $i < count($values); $i++) {
++for ($i = 0; $i < count($values); $i++) {

Ale existuje neco jako foreach (http://php.net/manual/en/control-structures.foreach.php)
Kdyz vidim nekde v PHP vypsani pole pomoci for && count tak mam chut vrazdit…

j3nda

nekdy je vhodne pristupovat k prvku primo, jak ukazuje priklad. zde je z pohledu optimalizace spatne jenom to count(), tj.


--for ($i = 1, $maxi=count($va­lues); $i < $maxi; $i++) {
++for ($i = 0, $maxi=count($va­lues); $i < $maxi; $i++) {

hromadadan

Ty blbečku blbá, tohle není článek o cyklech, ale o testech.. „.. mam chut vrazdit“ – silná slova uhrovitého zrzka za poprskanou klávesnicí, že?

Michal

Myslim ze oba byste tech pocitacu meli nechat a jit delat treba myslivce, tam je clovek na vzduchu a vycisti si hlavu ;-)

failer

Ehm. Duvod pro Foreach je schopnost paralelniho behu (pracuje s kopiemi tabulek). Duvod pro bezny For je zajisteni posloupnosti v poli.

Sadam

Pro zajisteni posloupnosti v poli mam snad razeni ;-) (dle klice)
http://php.net/manual/en/function.ksort.php
ktere je treba jen kdyz pole blbe plnim (nebo nejsem schopen zajistit posloupnost pri plneni)

Clary

Ještě bych zmínil, že chyba nemusí být zavlečena nepozorností, ale že prostě v programu uděláme úpravu, která nějakým způsobem ovlivní chování kódu, který napsal kolega. Setkal jsem se s názorem, že k potlačení chyb stačí u psaní přemýšlet a udržet kód v hlavě, ale při psaní projektu v týmu je toto zhola nemožné.

Michal

To o tom premysleni a udržování kódu v hlavě mi pripomnelo pribeh jednoho Ostravskeho tramvajaka, kterej zapomnel pred jednokolejkou vzit mobil a zavolat tramvajakovi co mel jet proti nemu – a taky tam jel ;-) . Lidskej faktor uderi vzdy kdyz to nejmene cekas.

yad

Udržať tesy krátke nie je zasa také ľahké, ak to robí komplexné veci. Napríklad mne sa už podarilo na funkciu s 4 riadkami napísať test o cca. 60 riadkoch a to je celkom stručný a jasný.

Ale súhlasím s tým, že na triviálne operácie držať testy krátke je nutnosť.

arron

Pak je ale otázka, jestli není ta funkce špatně napsaná a nedělá víc věcí než jednu ;-)

yad

Vytvára dotaz na traverzný strom a využíva pri tom ORM. Ale jedná sa o Python, kde ORM frameworky (Django ORM, SQLAlchemy atď. umožňujú zaujímavejšie veci).

arron

Ta otázka byla spíše řečnická ;-) Ono se to takhle z popisu stejně nedá říct, to už je potřeba pak vidět kód :-) Taky mám pár testů, které se trochu rozlezly, ale je to tím, že je potřeba připravit nějakou složitější vstupní strukturu dat na které se pak něco provede…

Aleš Roubíček

Refactorovat se mají i testy, ne jen produkční kód.

yad

Je tam subquery a join. Takže sa testuje 5 prípadov – join (2x), subquery+join (3x). Je tam 5 položiek v traverznom strome (čo teraz pozerám) a na každú sa testuje členstvo.

Jedná sa query, ktorá pýta cestu hore pre traverzný strom plus s najbližšími uzlami.

Aleš Roubíček

Sám píšete, že v tom „testu“ je testů hned několik. #testsmell

yad

Pardon. Zle som Vás pochopil.

arron

Tzn. 5 testovacích metod, každá pro jeden případ :-)

Paja

Vyrobim si vlastni err_handler ktery mi vsechny chyby loguje v prehledne forme do databaze a mam i pekny prohlizec tohoto logu.
Loguju vcetne zformatovaneho vypisu debug_backtrace, parametru na vstupu scriptu, to abych vedel co chybe predchazelo.
V programu volam na ruznych mistech trigger_error. Vzdy kdyz nastane neocekavane. Napr. od spoda – v databazovem rozhrani:
if (pg_last_error($this->dbresource)) {
trigger_error(„DB error : „.pg_last_error($this->dbresource).“n$qu­ery“, E_USER_WARNING);
return false;
}
Ale i jinde – napr. pokud cekam, ze dotaz nutne musi vratit nejaka data a on je nevrati :
if (!$data=$db->get($sql)) {
trigger_error(„ne­muzu nacist podrobnosti o baleni toaletniho papiru s id: $this->id“, E_USER_WARNING);
}
A jsem na nervy, pokud mam cokoliv v errorlogu a jdu patrat jak k tomu mohlo k… dojit.

Poznamka: (asi se budu v diskuzich opakovat). Vyrobte objekt v PHP, ktery vyrabi desitky SQL dotazu (pokud mate framework ktery tohle miluje) a mate co testovat. Nebo udelejte view, resp. SQL funkci, ktere vam daji data. Pak se kouknete pri zmenach v databazi, co tohle view dava za data. Na prvni pohled vidite, jestli to view funguje nebo ne. Muzete si na nej napsat i test (nejlepe opet view).
Poznamka_2: PHP nebyl stvoren pro aplikace, ale pro zobrazeni dat. A data se najdou v databazi. Uz jen ten rozdil, ze PHP se vykona cele znovu pri libovolnem kliknuti do aplikace a zacina s cistym stitem. To uz i v perlu bylo fastcgi, ktere je perzistentni (urychleni objektu v PHP se resi cache vseho mozneho, coz jen prinese dalsi nejistou).
Poznamka_2.5: netusim, jak otestovat ze vysledek PHP sccriptu, vypada stejne v ruznych prohlizecich.
Poznamka_3: i ja pisu chyby. Vic nez je mi mile. Priklad z dneska: pri implementaci „do ruky“ a „na postu“ jsem si nevsimnul, ze generator mailu zakaznikum, aby mohli sledovat cestu baliku, rozlisuje postu a PPL podle prvnich znaku cisla baliku (drive BO, dnes DR a NP). A chybou se pro DR a NP generoval v mailu link na PPL. Tri tydny trvalo, nez si nejaky zakaznik tohodle vsimnul. Fakt nevim jak na toto napsat test. Rad bych si nechal poradit.
Poznamka_4 (nijak se nevztahujici k testovani, spise jen povzdech nad projekty kde je prilis mnoho tvurcu a jako zamysleni kam ten vyvoj speje): vcera jsem stravil 4 hodky s pomoci znamemu, ktery si sam udelal eshop nad presto. Problem 1: rozhodli se, ze z verze na verzi zmeni system tak, ze drive byl stav nove objednavky zavisly na stavu skladu. V nove verzi udelaji dva stavy. Prvni jen ulozi do historie objednavky a stav nove objednavky pridaji jako dalsi stav v historii a to na konstantni hodnotu. Dalsi problem byl v nepochopeni, ze uzivatel presta potrebuje, aby se mu pri naskladneni zbozi samy oznacily objednavky, ktere muze vydat. Spojeni toho, ze stav objednavky neni soucasti vlastni objednavky, ale je potreba ho najit v historii jako posledni stav, a mysql ktere neumoznuje joinovat subquery ve view zpusobilo vygenerovani asi 6-ti vnorenych view, ktere dalo ve vysledku: objednavce x nastav novy stav na y. Coz pak zabralo 6-ti radkovy patch do sekce prijmu zbozi v PHP. Fakt jsem byl z toho presta zdeseny, jak je to uzasne modularni system, ktery umi vse.

enumag

Mohl by mi autor vysvětlit tento výrok?

„Čím více času investujete do psaní testů, tím méně potom budete potřebovat na refaktoring, který si vyžádá nějaká změna.“

Když něco refaktoruju, tak to zpravidla znamená změnu API. A když změním API, musím změnit i volání v příslušných testech, tedy na refaktoring potřebuji naopak VÍCE času než kdybych testy nepoužíval. — Budu rád když mi to někdo vyvrátí. ;-)

5o

Tak toto je jednoduché, ak píšeš aplikáciu iba pre seba tak to je pravda. Ale predstav si napr. niektorý framework alebo plugin/modul bez testov a urobia refaktoring niektorej metódy (verejné API sa nemusí nevyhnutne zmeniť). Ako si bez testov môžeš byť istý, že si nevydal spätne nekompatibilnú verziu príp. s bugom, ktorý je už niekde v issue trackery.

enumag

Ano, to mi došlo také. Pod refaktoringem si ale představuji spíše rozsáhlé změny které většinou znamenají i určitou změnu API (popřípadě úplně nové API). U mne jsou tyto případy mnohem častější než refaktoring bez změny API. Takže jsem měl vlastně také pravdu (bohužel) a testy mi to v těchto případech zkomplikují.

Na druhou stranu je fakt že díky TTD by kód mohl být od začátku lepší a podobný refaktoring by neměl být potřeba nijak často.

arron

Autor tím chtěl IMHO říct to, že když máš testy a změníš cokoliv v aplikaci, tak Ti testy ušetří práci v tom, že poměrně rychle (a automaticky) zjistíš, jestli se někde něco nerozbilo. A to něco vůbec nemusí přímo souviset s tím, co se změnilo.

Refaktoring je naopak potřeba skoro pořád. Nikdy se nic nepovede napsat ideálně napoprvé a kód je potřeba průběžně udržovat. Já třeba zpravidla zjistím, že nějaká metoda je potřeba ještě rozdělit a nebo že některá funkčnost bude vhodnější vyčlenit do samostatného objektu. Ačkoliv tedy neměním funkčnost, tak mi testy pomůžou v tom, že vím, že to pořád všechno funguje správně.

No a v Tvém případě víš, že změna API Ti nezbourala úplně druhý konec aplikace. A ano, to se běžně stává :-)

Clary

Nelze než souhlasit. Většina knih co se zabývá refaktorováním je z první poloviny o tom jakým způsobem nacpat hnusný špatně testovatelný kód do testů, aby následně bylo možno refaktorovat (tj. přepsat na čistší kód bez změny funkčnosti aplikace).

5o

Je rozdiel medzi prototypovaním a písaním znovupoužitelnej jednotky. Pri portotypovaní sú testy zbytočné. Potom, keď som spokojný s API začnem písať testy a následne kód refaktorujem, čiže API je zmrznuté, ide čisto iba o vylepšenie kódu. A keď sa jednotka osvedčí a je treba ju prepísať, napr. kóli novému frameworku, napíšem prvý test a na to triedu. Keď viem čo chcem je písanie testov hračka.

jos

„Takže jsem měl vlastně také pravdu (bohužel) a testy mi to v těchto případech zkomplikují.“

neměl, sorry, ale vůbec nevíš o čem testování je, což neví nikdo dokud to nezkusí ve velkým

enumag

V tom že nevím o čem je testování máš rozhodně pravdu. :-) Proto se to snažím naučit.

jos

„Tak toto je jednoduché, ak píšeš aplikáciu iba pre seba tak to je pravda.“

ehm, když po dvou letech přídeš k aplikaci kterou sis napsal „iba pre seba“, tak ty testy oceníš taky

5o

suhlas :)

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.