Názory k článku
Prasit, či neprasit?

> Psaní testů před samotným kódem a důsledné vyvarování se service locatorů znamená, že budeme schopni instancovat každou část aplikace v izolaci. Nejen my, ale i ostatní. V testech, i kdekoliv jinde. To je klíč ke skutečné znovupoužitelnosti kódu.

Klíč ke znovupoužitelnosti a testovatelnosti je čistě funkcionální kód.

Čistě funkcionálním kódem mám na mysli, že funkce by měly být bez side effectů a vrácená hodnota by měla záviset pouze na vstupních parametrech. Lze to dělat i v OOP.

Ještě dodám, že vstupních parametrů by mělo být málo a měly by být jednoduché (tj. aby se nepředával celý svět).

> Ještě dodám, že vstupních parametrů by mělo být málo a měly by být jednoduché
> (tj. aby se nepředával celý svět).

Nevzniklo mj. právě kvůli tomuto OOP?

Ne, to platilo porad.

Právě, že vzniklo. Alan Kay to jednou zmínil (totiž že rozsáhlé používání side-effectů součástí jeho původního plánu na ovládnutí světa nebylo).

Vůbec nechápu, jak s tím souvisí OOP. Můžete to vysvětlit?

IMHO idea, ze funkce maji byt male, delat jednu funkci, a byt bez vedlejsich efektu, je-li to mozne (predevsim v drivejsich dobach bylo ovsem pouzit vedlejsi efekt casto jedina cesta, jak neco delat efektivne), podle me saha az nekam k Lispu.

súhlasím, ale nedá sa to brať dogmaticky. trebars funkcia vracajúca presný čas, alebo náhodné číslo vráti vždy inú hodnotu bez ohľadu na vstupné parametre.

A proto by se měli zamockovat.

> Počítáš ukazatel na objekt „před tečkou“ mezi vstupní parametry?

Ano, počítám.

tá v tom zelenom má pekné kozy

Taky si říkám, že bych ji klidně zprasil. ;-)

Nepoznate ani svoje krajanky? Veronika Zemanova!!!

Mě víc dostala ta s těma flaškama

Mě zase nejvíc dostaly ty flašky.

Mám jeden trochu OT dotaz. Ale už delší dobu mě vrtá v hlavě.

Dokázal by někdo jednoduše popsat výhody should.js oproti klasickému assertu?

Should pochází z Behaviour Driven Developmentu. Cílem je změnit běžné testování stavu typu:

assert.equal abc, def

na formát:

abc.should.equal def

Čímž získáváš super čitelnost a DSL-like syntaxi (jakkoliv BDD toho zahrnuje mnohem víc). Proč psát testy víc jako věty výborně vysvětluje Dan North, autor BDD tady http://dannorth.net/introducing-bdd/

A proč nezavádět věci jako psaní vět objasňuje studium jazyka COBOL.

Miloslav Ponkrác

P.S.: Kdo nestuduje historii, je odsouzen k opakování chyb.

Nemůžete pro nás tupce tu svojí hlubokou myšlenku ještě trochu rozvést?

Klidně. :-)

Prostě kdosi tu pronesl dogma, že je príma dělat programy či jejich části (konkrétně zde assery) jako věty. A že je to nejlepší možná věc.

Já jsem uvedl příklad, že o to už se tu lidé snažili, stačí se podívat na programovací jazyk COBOL.

Pro ty „tupce“, já jsem nenapsal, že je správné první nebo druhé. Jen mě trochu pije krev, že kdosi tu bez důkazu napsal „získáváš super čitelnost“ a zároveň odkaz na to proč „psát jako věty víc“. V poslední době se namísto praktických aspektů z programování dělá ideologie.

Namítl jsem tedy protipříklad – jazyk COBOL se důsledně řídil tím, že „psát věty co nejvíce je príma“. A pokud chcete psát věty víc, swičnutí na jazyk COBOL je nejlepší co můžete udělat. Byl to programovací jazyk, který vznikl právě na základě, že programování by mělo co nejvíce připomínat přirozený lidský jazyk a přirozené lidské věty. Jak se ukázalo, byl to omyl a slepá cesta vývoje.

Bohužel se tento omyl projevil někde kolem roku 1961 a poté co devastoval řadu let nervy programátorů. Nicméně dnešní generace nejspíše na jazyk COBOL a jeho historické poučení už zapoměněla – a tak znovu koketuje s tím, že psát vše jako věty je príma. Doporučuji tedy přejít na jazyk COBOL, navíc je to špičkově placená práce a kdo umí dobře COBOL je velmi luxusně placen. A zároveň nikde nenajdete lépe splněné paradigma, že psát věty je príma.

A nic Vás z tohoto paradigmatu také rychleji nevyléčí. Věřte mi, že po krátké době už Vám to príma připadat nebude.

Ono je hezké psát věci jako věty do té doby, než to lidé vezmou vážně a pak z toho budou mít bolení hlavy.

A to je vše.

Miloslav Ponkrác

Ne programy, ale testy.

Test není většinou kus kódu? Že by mi něco ušlo?

Testy jsou specifické tím, že jsou na sobě nezávyslé. V případě should.js jde opravdu jen o jiný slovosled, nic víc.
should.equal(str, 'foo') je pouze jinak zapsaný assert.equal(str, 'foo')

Samozřejmě.

A čistý program a naprasený program se od sebe může lišit jen jiným slovosledem. Nebo jinými názvy.

Ale rejpnu si přímo ďábelsky: Obhajujete, že je možné použít jiný slovosled, a že to nevadí, protože je to malý nezávislý test.

Ve větším měřítku by to vadilo? Kdyby to byl závislý kód?

Nenapsal jsem, že jedno nebo druhé je špatně. Pouze jsem vytvořil rovnováhu k reklamně jásavému „proč používat v kódech věty víc“.

Já osobně budu používat vždy assert. Jednak je to IMHO přehlednější. Jednak jakmile vidím v kódu/testu assert, je jasné, že následuje kód pro test. Vizuálně to snadno odliším. Je tak nějak přirozenější v celém OOP jednotně dodržovat, že první název je objekt či modul a akce přicházejí za názvem objekty. Existuje soubor.cti() a klavesnice.cti(). Jedna ze základních zásad pro čitelný (rozuměj neprasácký program) je dodržování stejného code style pro celý projekt. Pokud OOP vynucuje mít název modulu či objektu jako první jméno, pak ve stejném duchu je mít assert vlevo.

Jak by se Vám líbil program ve stylu:

x == y if
file.open();
x > 10 while
file.write(x);

To je totiž ve stejném duchu jako should.

Všichni programátoři očekávají assert na testy. To je obecná konvence napříč všemi programovacími jazyky.

Stejně tak mohu udělat program v C++/C#/Pythonu/Ruby atd., kde protože se mi to líbí změním konvence. Operátor + bude dělit a operátor - bude odmocňovat.

A znovu, mě je jedno kdo si bude používat should a na co chce. Jen by bylo třeba méně jásání typu „proč něco používat víc“ a podložit to nějakými argumenty.

Miloslav Ponkrác

Zrovna syntax:

show results if response.status is yes
renderer.show row if row.active

považuju za jednu z největších vychytávek v CoffeeScriptu, která zdrojové kódy ohromně zpřehledňuje. Vypadá to jako věta. Jen na konec napsat tečku.

to je sice fajn, ale programovani neni psani knihy. Cist stale dokola ty same vety zacne byt unavne a nakonec budete muset vic cist nez budete moct psat. Velka vychytavka. Je v tom takovy rozdil jako mezi zadanim slovni matematicke ulohy a jeji matematickou interpretaci.

Tyto vychytavky jsou skvele, teda az na spoustu pripadu, kdy snizuji citelnost, coz je skoro vzdy.

Je nutne je pouzivat, pokud neni neco lepsiho k dispozici, napriklad standardni funkce zname vsem.

Zarucene tak dostaneme jednoduse citelny kod, jen obcas dost neprehledny, zejmena v beznych pripadech.

Takhle jsem to myslel s tim if na konci radku?

Ještě by se slušelo říci, že bořit zažité konvence a to konvence na úrovni de facto standardu jako je assert chce hodně silný argument, který dává omračující výhodu.

Není-li omračující výhoda tak silného kalibru, že ospravedlňuje zboření v celém oboru zažitého standardu, tedy slova assert – platí zákon Occamovy břitvy.

Proto jsem na obhajobu změny konvence slova assert, který je používán na celém světě všemi programovacími jazyky už celá desetiletí očekával něco trošičku víc a nějaké silné argumenty, tedy hodně silné argumenty, než jenom „mělo by se to používat víc“.

Proč by třeba if nemohlo dělat cyklus? Nebo proč by slovo for nemohlo dělat návrat z funkce? Mohlo. Ale konvence říkají jinak. Nic než konvence. Ale každý tomu rozumí.

Důvod, proč se vyznáte ve svém i cizím programu je v první řadě ten, že dodržuje konvence. Až budete mít skvěle a čitelně napsaný programu, který znamnénkem + násobí, metoda read() bude zapisovat do souboru, metoda getSize() vrátí IP adresu apod., pak pochopíte proč boření konvencí je blbost, není-li pro to opravdu dobrý důvod. Zkuste si takový program napsat a udržovat.

A teď si zkuste udržet program po kolegovi v týmu, který začne konvenci inovovat. Jednu změnu unesete, možná i dvě, ale pak začne být husto.

A dál už přispívat k této diskusi nebudu, nedostatek času.

Miloslav Ponkrác

Díky za vaše komentáře. Ve skutečnosti je syntax assert frameworku málo důležitá. Je to implementační detail. Mocha umí pracovat s různými assert frameworky, já si zvolil should.js, ale klidně sem mohl použít assert. Opravdu, tohle není zas tak podstatné, a hlavně, o tom článek není.

http://twitter.com/timycz/status/132238467492098048

Jenže on má pravdu (minimálně v tomhle případě…).

nemate nekdo horkou linku do pekla ? rekl bych, ze tam asi zaclo mrznout ;-)

Chtěl bych se jen zeptat, jestli to, že COBOL, jenž co nejvíce připomínal přirozený lidský jazyk, což jak se ukázalo byl omyl a slepá cesta vývoje, podpoříš i nějakým odkazem, nebo je důkazem tvé prosté konstatování ve stylu „všichni jste hlupáci“?

Mrtvej jazyk, wtz!

Duvod, proc pokus o programovani v "prirozenem" jazyce IMHO selhaly je v tom, ze to plete. Prirozeny jazyk totiz snese drobne odchylky v syntaxi (napriklad zmenu slovosledu), kdezto pocitace ne (specialne COBOL je hrozne citlivy na ruzne tecky). Takze se to pak spatne pamatuje, jaka je presna syntaxe, protoze je prilis podobna te prirozene. Druhy, i kdyz trochu vedlejsi problem, jsou zavorky.

Nemám pocit, že by SQL selhalo nebo že by tam byl nějaký problém se závorky, když se tedy bavíme o jazycích podobným přirozeným jazykům.

Nevim. Prijde mi, ze lide se naopak snazi, sec jim sily staci, se SQL ruzne vyhnout. Ale mozna, ze ty jazyky jsou proste stare.

Ja to ovsem vidim jeste jinde - Common Lisp ma makro "loop", a to umoznuje zapisovat smycky v jakemsi "cloveku blizkem" pseudojazyce. Ovsem pokud si zrovna nepamatujete konkretni idiom, je to dost zkoumani, jak v tom neco zapsat. Prijde mi, ze to plati i o SQL.

Tady je otázka, jestli je SQL tak úspěšné díky tomu, že se podobá přirozenému jazyku, nebo navzdory tomu. Např. mně se na něm líbí, že je deklarativní – ale to, zda ty dotazy vzdáleně připomínají anglické věty nebo ne, je mi celkem ukradené.

Netvrdil jsem, že je SQL díky tomu úspěšné, prosím nepodsouvat. Jen jsem se ptal, jestli Miroslav Ponkrác má v plánu svůj bohorovný komentář i doložit jinak, než tím, že jej podepsal Miroslav Ponkrác. Což bylo pochopitelně hovorová otázka a tudíž na ni nebylo třeba reagovat ;-)

Já bych hlavně netvrdil, že SQL je postavené na přirozeném lidském jazyce. Na první pohled úplně základní syntaxe by tak možná mohla vypadat, ale třeba sloupeček v tabulce se zapisuje "tab.col", nikoli jako třeba v Cobolu "col in tab". Ten posun k lidskému jazyku je tam maximálně na úrovni jaký má Java oproti C++ (tedy sem tam klíčové slovo navíc oproti dvojtečce apod.).

Že se snaží SW vývoj vyhýbat zápisům v SQL (zmíněno někde dříve či později), je spíš snaha se vyhnout zásahům do dalších vrstev kódu, která je obvykle definována deklarativně a oproti business vrstvě může mít odlišnosti, které se vyvíjí nezávisle na vyšších vrstvách. Jinými slovy, proč to dělat ručně, když to není třeba.

Argument, že Cobol není mrtvý jazyk, protože existují pozice pro vývojáře, je absurdní. Cobol je mrtvý, protože žádný nový SW v něm už nevzniká, pouze se udržuje/rozšiřuje stávající (a taky je ten poměr cena/výkon oproti současnému vývoji pěkně drahý).

Jinak samozřejmě 100% souhlas, co se lidského vs. formálního jazyka týče, zkuste nahradit současný jazyk matematiky a logiky jazykem lidským a vrátíte se na úroveň filosofů antického Řecka (no offence).

prijde mi ze je lepsi kdyz se koder nauci jazyk nez kdyz se jazyk snazi simulovat literaturu. Matematika se taky neprizpusobuje tomu kdo se ji zabiva ale naopak.
Napriklad ten kus kodu co jste sem vlepil, nez budu vedet co to dela tak to musim cele precist, musim si precit kazde slovo a spravne si ho zasadit v kontextu.
i++ si myslim je rychleji citelne nez add 1 to i.

Jenže problém je v tom, že:

+ v běžné algebře sčítá a mám za to, že dokonce je v matematice dohoda, že je zakázáno vytvořit takovou grupu, kde by byla operace násobení popsána operátorem +. Neexistuje racionální důvod, proč by někdo přetížil + na násobení.

getSize() vrací velikost. Jiné použití by byl code smell. Tím pádem iracionální řešení.

Zatímco změna pořadí volání, aby kód připomínal víc angličtinu, to je dokonale racionální řešení. Jednou už v programování používáme anglická slova a kód:

if x > y do; echo x + 1; done;

považujeme za kód v pořádku. Pokud by nemělo programování připomínat angličtinu, mělo se zvolit něco jiného.

Místo if třeba #3, do ~1, ; ^7, done &99.

Pak by takový kód vypadal takhle:

#3 x > y ~1^7 echo x + 1 ^7 &99^7

Máte to, už to nevypadá jako anglická věta. Jste šťastný?

> mám za to, že dokonce je v matematice dohoda, že je zakázáno vytvořit takovou grupu, kde by byla operace násobení popsána operátorem +.

+ je jen symbol jazyka teorie grup a není žádný důvod, proč takto omezovat jeho interpretaci

Ohromně se mýlíte.

Obecně můžete vidět 2 druhy jazyků. Jedny se přibližují "matematickému zápisu" (C, VB, Pascal, PHP). Ty jsou vhodné pro popisy algoritmů. Zápis výpočtů je v nich obvykle velmi dobře čitelný. Naopak na objektové programování se nehodí, protože otravují spoustou syntaktického bordelu (a to si myslím i o C++, C#, Javě).

Pak jsou jazyky, které připomínají běžné věty (Ruby, Smalltalk, CoffeeScript, Self, AppleScript). Ty jsou vhodné pro objektové programování. Objektové programování totiž nění o ničem jiném, než o tom, že A posílá zprávu B a k tomu nepotřebujeme žádné speciální znaky. Na druhou stranu zapisovat v takových jazycích výpočty by byl porod (proto si berou kusy syntaxe z prvních jazyků, takže i v tom Smalltalku můžete napsat 1 + 1 místo 1 plus: 1).

User Stories jsou text. Jsou zadání. Běžné věty. Můžete buďto vzít Story a vyrobit parser a přepsat ho do syntaxe jazyka (jako to dělá Cucumber), nebo můžete přímo upravit syntax jazyka tak, aby zápis programu vypadal jako ta Story (to dělá třeba RSpec nebo Should.JS). Já ten popis beru, šetří čas, kontroluje syntaxi, kdokoliv se s tím setkal, to chápe a velmi dobře se mu to čte.

> Objektové programování totiž nění o ničem jiném, než o tom, že A posílá zprávu B a k tomu nepotřebujeme žádné speciální

A jak do toho zapadají jazyky s multimetodami?

Když se bude dispatch vyhodnocovat dynamicky, tj. ne jen podle typu přijímajícího objektu, ale i podle typů parametrů, tak to budou vlastně taky multimetody ;-) (Jeden z nejrozšířenějších dynamicky typovaných jazyků pro JVM takhle funguje.) Ale jinak tohle považuju spíš za slovíčkaření, v naprosté většině případů lidi, kteří mluví o OOP, mluví o OOP založeném na třídách, což je na jednu stranu nepřesná, na druhou stranu užitečná zkratka.

Čitelnější syntax, nic jiného.

Použít na závěr citaci Uncla Boba a říct, že můžemo volit tak či tak, chce koule. :)

Citace se vztahují k návrhu, k architektuře. Uncle Bob říká, že tam, kde je drahé měnit již vybudované (tj. hmotná díla jako budovy, nábytek), je důležité mít dobrý návrh dopředu. Naopak, že tam, kde výsledné dílo můžeme měnit snadno (u software nebo uměleckých děl), je výhodnější iterativní design.

Uncle Bob neřeší, zda prasit nebo ne. Profesionál neprasí. Uncle Bob neřeší, jestli psát unit testy nebo ne. Profesionál praktikuje TDD. Pseudopragmatické závěry jsou k ničemu. ;)

mozna ze netreba prebytecne koule, mozna ze staci drobny nedostatek v jine oblasti (prekladatelske ci kognitivni schopnosti). ale to nema ten "ring", pravda ;-))

perfektni pouziti slusnyho hlodu ;-)

Diky za super clanek o TDD a doufam, ze si z nej ctenari odnesou podstatu!

S cim vsak nesouhlasim je pouziti dependency injection. Chapu jej jako techniku znamou ze statickych jazyku, ktera usnadnuje testovatelnost, ale proc ji pouzit v Javascriptu?

Spis bych byl pro stub/mock framework, jehoz napsani je v javascriptu pomerne trivialni.

Dependency injection nemá nic společnýho se statickým typováním ani testováním. Je to technika dobrého objektového návrhu.

Mock/Stub framework není v JS vůbec potřeba, díky dynamičnosti a slabému typování jazyka.

Pokud dependency injection nema souvislost s testovatelnosti, tak nevim, proc by DI byl takto obsirne zminen i v tomto clanku, ktery se primarne testovani venuje.

Myslim ze koncept DI ma smysl i v Javascriptu, kdyz chces implementovat napr. Strategy pattern, ale nemyslim si ze je treba jej pouzivat dogmaticky. Vetsinu pripadu bych nahradil prave stubbingem. Viz treba jak to dela Jasmine a jeho spies. http://pivotal.github.com/jasmine/.

Pozn.: Na druhou stranu si nedovedu predstavit jak bych bez DI psal testy napr v C++.

Jenže článek vůbec není o testování. ;) Článek je o prasení/neprasení. Testování, DI, TDD, dobrý OO návrh, to všechno jsou věci které spadají do neprasení.

Pro stubování potřebujete DI, jinak se jedná o monkey-patching.

Pravda, stubovani je v podstate DI :) jen psany trosku jinak (prave diky dynamicnosti jazyka).

Stub je objekt, který nahrazuje závislost systému pod testem. Pokud se tato závislost nahrazuje jinak než pomocí DI, jde o monkey-patching (právě díky dynamičnosti jazyka).

Chapu dobre, ze podle Vas nasledujici node.js kod je spatny a jeho test je monkey-patching?

https://gist.github.com/1606059

Bylo by spravne predat http knihovnu jako dependency do objektu App?

Nikoliv. App je, pokud to dobře chápu, Composition Root aplikace. Otázka, je zda má hlubší smyl App testovat?

Samozrejme se jedna o pomerne jednoduche konstrukce, ale myslim, ze v tymu, kde s kodem pracuje vice lidi, take ruzne urovne, ma smysl testovat vse :)

Spis jsem tim chtel ilustrovat pointu, ze se da psat citelny kod i bez vkladani vsech dependencies. Samozrejme pri modelovani slozitejsich vazem mezi objekty je DI platna a dobra technika v mnoha pripadech.

Jenže spyOn není zrovna ukázkou čitelného testu. Zavádí tam "magic" a to může být matoucí.

Jaký konkrétně smysl má testovat Composition Root? To už je jen testování pro testování, obvzlášt, když stejně "závislosti" fejkujete.

Pro me jsou spies citelne, ale to je vec nazoru (zajimalo by me, jak by mohl test vypadat bez jeho pouziti).

Jak pisu, priklad je trivialni, kdybych do metody init() pridal logiku, ktera by napriklad nejakym zpusobem podminovala vytvoreni serveru (napr. overeni, ze options obsahuji nutne parametry), pak nevidim duvod proc netestovat.

A nebo "TDD done right is called TDD. The term BDD wastes a slot in term space."

TDD a BDD jsou dvě zcela odlišné věci.

TDD je praktika iterativního vývoje. Primárně je to nástroj vývojářů.

BDD je framework na psaní akceptačních testů. Primárně je to nástroj testerů a product ownerů.

Testy vzniklé při TDD samozřejmě testy jsou a konkrétně unit testy popř. integrační testy. Takové testy jsou značně low level, ověřují správnou implementaci algoritmů, chování jednotlivých objektů. Naproti tomu BDD slouží k psaní akceptačních testů, které slouží k ověřování business pravidel, chování systému jako celku. Takové testy by měli být srozumitlné i neprogramátorům, expertům z problémové domény.

Ja pridam uz len svoj neoblubeny nazor:
Ako sa da nieco co je napisane v JS alebo PHP nezprasit? To su prasacke jazyky rovno od prirodzenia.

To, že umožňují prasit, ještě neznamená, že to nejde jinak. Prasáckej kód napíšete v každém jazyce. Některé jazyky se tomu jen snaží bránit víc než jiné. Nakonec, článek je o návrhu a ten jde zmršit vždy a všude, na jazyku nezáleží.

Ja viem ale nemozem si pomoct. Ked vidim ako sa snazi niekto dorobit objekty do neobjektoveho jazyka vzdy mi je cudne od zaludka. A to sa naozaj bavime o tych 'neprasackych' verziach toho kodu.

Podporuje object oriented a asociativne polia su skutocna objektova podpora jazyka.

ono sa to nezda ale JSko je skutocne objektovejsie ako vacsina beznych jazykov zalozenych na triedach. prave ten jednoduchy a flexybilny objektovy model js dava programatorovi obrovsku slobodu. ale to pochopis az ked v nom budes dlhsie programovat a zistis ze OOP neni o zapuzdreni, interfacoch a triedach ale o v prvom rade o objektoch a objektovom mysleni.

„Ja viem ale nemozem si pomoct. Ked vidim ako sa snazi niekto dorobit objekty do neobjektoveho jazyka vzdy mi je cudne od zaludka. A to sa naozaj bavime o tych 'neprasackych' verziach toho kodu.“

Pokud si někdo nedokáže představit čístý kód v nějakých běžných jazycích – pak je to proto, že je sám prase. Dál už je to jen efekt hesla podle sebe soudím Tebe.

Objektové progamování nepotřebuje objektovou podporu v jazyce.

Nicméně JS i PHP jsou objektové jazyky.

Přesněji objektově orientované, jinak souhlas.

Proc na nej reagujete? je to nevychovatelnej dogmatik.

Toto nezmyselne pravidlo uz bolo vyvratene a oznacene za antipattern vela krat. 100% pokrytie kodu testami? Aky to ma zmysel? A ked nieje potreba 100% pokrytie, tak ako zistist ci ma zmysel napisat test? Tym ze ho napises skor ako implementaciu, aby si potom v implementacii zistil ze nieje co testovat a tym padom tvoj test (1+1=2, amen) je k nicomu?

No a k tym testom. Co "konkretne" testujes s "click on anchor should call element.query­SelectorAll" ? Podobne veci som videl u svojich prasackych kolegov ktory napisaly platobny system kde test suite mala velkost 4x implementacie, vsetko svietilo na zeleno, akurat ze zakaznikov ten system oberal o peniaze raz tolko ako mal.

Toto sa vola "testing for the sake (and fun) of testing". Inymi slovami, s projektom stravis viac casu nez je treba, bez ziadnej pridanej hodnoty. Testy typu "should call". Potom zmenis implementaciu, trebars nieco zoptimalizujes, stale to bude krasne fungovat ale tvoj "should call" test failne, a budes ho musiet opravit. Presiel som vsetky testy v lightbox-example repo. a je tam toho kopec.

IMHO testovat sa ma to co je viditelne uzivatelovi a na vystupe. V pripade lightboxu:

* kliknutim na link, zobrazi sa?
* kliknutim na next, zobrazi sa dalsi?
* atd.

Kdo ho vyvrátil?

Doporucam precitat http://goo.gl/dXcln . Je proste nezmysel porovnavat abstraktne (len eventualne materialne - maintenance) pojmy ako "kvalita kodu" s materialnymi ako "trvanie a cena vyvoja". Za dalsie, TDD dava zmysel len a len v tazko korporatnom prostredi kde sa vyraba softver ako vo fabrike na beziacom pase. Jeden projekt za druhym, ano vtedy je dolezite aby sa tvoji zotroceni robotnici drzali TDD praktik za ucelom maximalizacie produktivity a "kvality" kodu. Ja osobne sa tesim z toho ze takyto job ma nepostihol, a moja praca je rozmanita a kreativna. A keby som sa tu drzal TDD tak ma trafi slak. Akoby si aplikoval TDD na vyvoj povedzme grafickeho alebo zvukoveho programu? Ako by si testoval ci hra vyzera naozaj naozaj dobre, alebo ci syntezator na ktorom pracujes naozaj znie tak ako chces?

Ve chvili kdy se o ten kod budete muset delsi dobu starat, rozvijet ho a opravovat, tak se vam pojem "kvalita kodu" zmaterializuje hodne rychle. A TDD je jeden ze zpusobu jak docilit aby to nebylo moc drahe. Troufam si tvrdit, ze pro dodavatele netrivialniho softu je jen otazkou casu, kdy jim to dojde.

TDD se nejak vylucuje s rozmanitosti a kreativitou?

Ze nevidite uplatneni TDD pri vyvoji grafickeho programu mi naznacuje, ze vubec nemate predstavu a fantazii co je tim mysleno, tedy pochybuji i o vasi kreativite. Berte to jako podnet k vlastnimu rozvoji.
K vlastni otazce - az ten graficky program zacne opravdu neco umet, budete tam mit treba konvolucni filtr, muzete si na to napsat tridu, ktera ho bude pocitat a muzete si napsat UT, ktery vam otestuje ze ma vhodne rozhrani, ze dostane vse co potrebuje a ze dava spravne vysledky. Jeste driv nez ji vubec zavolate z GUI.

K tomu korporatnimu prostredi - na pohovory nam chodi 3 typy kandidatu - ti co maji OOP, navrh, TDD apod. v malicku, ti co se k tomu blizi, maji chut na sobe pracovat a naucit se nove veci. Tretim druhem jsou ti co je takove podruznosti nezajimaji a nepotrebuji to k tvorbe genialnich programu - bez vyjimky to jsou neskutecni patlalove.

Si vlastne rozumieme. Takze aky zmysel ma "A should call B" ?

Píši to v článku, ale klidně to zopakuji.
1) nemusíte spouštět celý program, abyste si ověřil požadované chování jedné jeho části
2) a nemusíte si to ani pamatovat, test si to pamatuje za vás
3) to, že každý řádek třídy musíte otestovat, vás nutí udržovat třídy jednoduché
4) až budete refaktorovat kód, nebudete si muset pamatovat co se kde volá, testy si to "pamatují" za vás

Poznamenal bych, ze 4) netrepi ty, co pouzivaji staticke typovani. Ostatne casto uvadena vyhoda testu pri refaktorovani plati jen pokud nema jazyk dobry typovy system a dobre IDE.

Dobrá poznámka. Avšak netýká se Javascriptu, tedy pokud není použit Google Closure Compiler například :)

Spis divialni postreh ;)

Na to bych vám mohl reagovat, že článek vyvracející 100% pokrytí testy..., už byl také vyvrácen - http://blog.8thlight.com/uncle-bob/2012/01/11/Flipping-the-Bit.html. Nejsem si ale jist, zdali by taková forma diskuze, byla přínosná.
Jestli sem vás dobře pochopil, tak jste myslím smysl unit testů dobře nepochopil. Snažíte se jim přisuzovat nadpřirozené schopnosti. Přiznávám, opravdu netuším jak bych napsal unit test, aby "hra vyzerala naozaj dobre".
To ostatně smysl unit testů ani není. Jak bych TDD aplikoval na vyvoj grafickeho nebo zvukového programu? Úplně stejně. Copak grafický nebo zvukový program, není zase jenom kód?

To bolo pointa, ja len nesuhlasim s pravidlami TF a TATFT, a 100% CC. Pretoze TF ma velmi blizko k "premature optimization" (zvysok poucky poznate, konci to slovickom evil). Unit testy pisem ked mam hotovy prototype (sketch code), a to len pre tie casti programu ktore povazujem (zo zkusenosti) za problematicke.

Ten člověk má pravdu a zřejmě nebyl pochopen.

Na jednu stranu je spousta lidí, kteří netestují – špatně. Na druhou stranu je mnoho lidí, kteří testování považují za boha - ještě horší.

Jsem ze starší školy. Jedna matematická poučka zní – neexistuje – a to je prosím seriózně matematicky dokázáno – možnost jak otestovat na 100 %, že v programu není chyba a že běží správně.

Jinak řečeno, nějaké pokrytí 100 % testy je víra nepodložená realitou. Můžete pokrýt 100 % kódu testy, ale je otázka, zda je to vždy potřebné, účelné a nutné. Ale hlavně, vždy a jakékoli testy odhalí jen zlomeček možných chyb. Přesněji odhalí ty chyby, které předpokládáte a na které si uděláte testy. Což je zlomeček chyb, které mohou nastat.

Z tohoto pohledu se dělání testů zaměňuje za test kódu. I testovat se musí umět.

Dále, abych interpretoval kolegu, kterého jste utřel, ale nejsem si jist zda správně. Existují programy, které nemají výstup testovatelný programově, ale přitom tento výstup je jejich účel. A zrovna občas grafické nebo zvukové programy alespoň část takové funkce mají.

Já bych přidal ze svého pohledu ještě další věc. Jsou programy a rutiny, kde není rychlostní rezerva na to dodržovat všechny zásady aby šlo do toho snadno vložit unit test. Každá abstrakce a každý luxus programátora má dost často jako za následek nižší výkon programu. A někdy se to nehodí. Třeba doporučuji si pokusně stvořit článek – jak bych použil unit testy na video kodeky. Pohoříte jako papír. Nic uvnitř rozumně neotestujete, pouze celý kodek jako černou skříňku. Ani není prostor na to uvnitř dodržovat pravidla pro to aby unit testy bylo snadné použít.

Beru ovšem, že tento článek je pro TDD, kde testování je základ. Takový vývoj není vhodný pro každý projekt ani každý program. Dokonce bych řekl že pro většinu není vhodný. Nicméně pro enterprise projekty nebo běžné desktop programy celkem ano či je to dokonce jedna z nejelpších metodik.

Metodu 100 % pokrytí testy bez přemýšlení považuji osobně za dogmatickou ptákovinu.

Miloslav Ponkrác

Jenže 100% CC nezaručuje to, že se v kódu nevyskytují chyby, ale to, že se tam nevyskytují známé chyby. Když píšete kód pomocí TDD, řídíte se nějakým UseCase, který obsahuje očekávané chování a některé výjimečné situace. Ty pokryjete testy. Pokud bylo v Use Case něco opomenuto a projeví se to jako bug, napíšete padající test, který bug reprodukuje, fixnete ho a máte jistotu, že když se bug opět objeví, tak se o tom velice rychle dozvíte.

TDD není Bůh. Nemůžete věřit, že s TDD bude SW bez chyby. Ale je dokázáno, že SW psaný pomocí TDD obsahujě řádově méně chyb, a oprava chyb nalezetých je také řádově snažší (tj. levnější oprava). Ale kdo rád tráví hodiny s debuggerem, pro toho TDD samozřejmě moc není.

Ale pozor na to. 100% CC neznamená psaní tuny zbytečných testů. Psát dobré testy je dovednost, která potřebuje znalosti a praxi.

Ad výkon. Vy jste jistě z velmi staré školy. Dnešní iPad 2 má tolik výkonu, že by v devedesátých letech patřil mezi top 50 superpočítačů. A to je jen blbej tablet. Abstrakce v kódu nám umožňují oddalovat rozhodnutí o detailech, které mají vliv na výkon. Je dokázáno, že změnou architektury můžete ovlivnit výkon řádově lépe než mikroptimalizacemi. A potlačování vhodných abstrakcí je mikroptimalizace.

Ano, jistě jsou časově kritické aplikace v letadlech nebo jaderných elektrárnách. Jenže pochybuju o tom, že by si tam někdo dovolil do produkce nasadit kód, který před tím neotestoval. Pevně v to věřím.

+1

Nechceš tyhle poznámky někdy napsat jako článek (je jedno, kde vyjde)? V komentářích to zapadne.

OT: Pomalu s tou matematickou karou. Samozrejme, ze existuje moznost dokazat, ze program pobezi vzdy spravne. Jen to omezuje mnozstvi programu, ktere lze napsat.

Ad „Samozrejme, ze existuje moznost dokazat, ze program pobezi vzdy spravne.“

A test taky považuješ za program nebo ne?

Pokud ano, pak je potřeba otestovat i ten test – dalším testem, který je opět potřeba otestovat…

Pokud ne* tak test považujeme za nějaký neomylný překlad analýzy (zadání, požadavků) a nekriticky věříme v jeho 100% správnost – věříme, že ten, kdo test psal, zcela pochopil analýzu a bezchybně ji vyjádřil formou testu.

Vlastně akorát víru v dokonalost programátora nahrazujeme vírou v dokonalost testera. Tím nechci říct, že testování nepomáhá zlepšovat kvalitu, ale že 100% bezchybnost je prokazatelně** nedosažitelná.

*) s čímž tedy nesouhlasím, ale budiž

**) ačkoli bezchybný program může existovat, nemůžeme se 100% jistotou dokázat, zda nějaký konkrétní program bezchybný je nebo ne.

Spatne. O konkretnim programu lze nekdy dokazat, ze je bezchybny (pokud neverite, tak vemte trebas vypocet faktorialu, napiste si invarianty a pouzijte indukci). Neexistuje postup, jak to delat pro libovolny program.

Ale pořád to stojí na předpokladu, že tester pochopil zadání a napsal správně test – v tomto případě: že ví, co je to faktoriál, ovládá základy matematiky a nedělá ve svých rovnicích chyby. Můžeš tento předpoklad 100% potvrdit? Nebo je to opět jen víra?

Take musim napriklad verit, ze se mi nezdate.

pokud neci argumenty neustoji ani kritiku vyplodu jeho predstavivosti ...
aneb tva reakce vyvolava "obrazek" psa jak si leha na zada a chcije na sebe.

Testy testuje implementace.

To je asi jako říct, že implementaci testuje kompilátor :-) (což je částečně pravda, ale opravdu jen částečně).

Trochu to souvisí s tím, co psal Daniel v článku: „nikdy nevěřte testu, který neselhal“.

To je dobrá rada a je dobré se jí při testování řídit (buď psát nejdřív testy, nebo si aspoň zkusit udělat v programu dodatečně chybu a zkontrolovat, že testy spadnou). Ale opět to není nic 100% – tímto způsobem otestujeme test jen na některé chyby, které v něm mohou být – rozhodně ne na všechny.

BTW tu větu má Dan ode mě.

Přestaňme žít v iluzorním ideálním světě a začněme chápat, že nemít 100% jistotu je mnohem lepší než mít 100% nejistotu.

Ale o tom tohle vlákno vůbec není. Začalo to pod větou Miloslava Ponkráce:

„neexistuje … možnost jak otestovat na 100 %, že v programu není chyba a že běží správně.“

které někteří začali oponovat. A já k tomu napsal důkaz, že 100% jistotu bezchybnosti opravdu mít nelze.

Takže bychom to asi mohli uzavřít s tím, že 1) testování je dobré, protože snižuje pravděpodobnost chyby 2) ale nesnižuje ji na 0%. OK?

Věta „neexistuje možnost jak otestovat na 100 %, že v programu není chyba a že běží správně.“ byl takzvaný hastroš (tedy něco, co odpůrce nikdy neměl na mysli a nic v tom smyslu neřekl), kterého následně Ponkrác polemicky vyvrátil, aby dokázal, jak se odpůrce mýlí.

az na to ze ho nevyvratil ale pouzil jako odrazovy mustek ...

vsetko pekne pani. len teoria tu trochu nakopla prax.

oba ukackove lightboxy nefunguju na ipade. podotykam, ze som este nenasiel znamejsie obdoby lightboxu, ktore by nefungovali. a ak aj nespustia js, tak mi aspon dovolia otvorit odkaz a zobrazi sa konvencny, sposobom obrazok.

dakujem za clanok, toto je len poznamka, ze sa oplati kod testovat.

Po nějaké době se mi na iPadu rozchodily, ale jinak bug potvrzuji.

To je přesně ono – dneska lidi často napíší* jednotkové testy a myslí si, jak mají otestováno…

*) a to většinou jen jako, aby vykázali 100% pokrytí – jestli to ale skutečně smysluplně testuje, je jim jedno.

TDD není primárně nástroj pro quality assurance proces (ve smyslu dodání bezchybného produktu), ale *návrhový* proces. Co se kvality týče tak spíše zajišťuje, že nová verze produktu je stejně tak dobrá/stabilní jako minulá.

Nemluvil jsem o TDD, ale o testování jako takovém. A narážím na to, že si hodně lidí myslí, že testování = jednotkové testy.

Lightbox je především nehorázná prasárna z hlediska UX.

Souhlas. Ale jak to řešit lépe, aby uživatel mohl přecházet z jednoho obrázku na druhý, zpátky, aby si mohl zobrazit všechny náhledy…?

Možná by server mohl posílat nějaké zvláštní HTTP hlavičky, kde by byl odkaz na další a předchozí obrázek a odkaz na galerii – a www prohlížeč by se pak postaral o zobrazení obrázku ve vhodném rozlišení + vykreslení tlačítek + případného pásu s náhledy atd.

Nebo by www prohlížeč mohl nějak inteligentně rozpoznat, že se jedná o galerii obrázků, a přidat tlačítka další/předchozí sám (to myslím dělá Opera).

Případně použít FTP/WebDAV/… a galerii otevřít ve skutečném prohlížeči obrázků (ne ho parodovat v HTML), klidně zasazeném do panelu www prohlížeče, nebo otevřeném v novém okně, podle přání uživatele.

Tohle mi zase nevadí – když si prohlížím obrázky, tak nechci, aby mě rušily ostatní prvky na stránce.

To máš pravdu. Jenže "prohlížení obrázků" je zřídkakdy primární funkcí dané stránky a ve všech ostatních případech je lightbox vopruz (typicky eshop, zpravodajské weby, osobní portfolia, atd.)

Prohlizec v opere stoji za prd. Kdyz se kouknu na czc a nebo alzu, oboje je na prd, v czc jdu pres x dalsich stranek a nakonec skoncim v novem okne abych mel obr pres celou stranku. na alze to same jen je tam o jednu stranku mene. princip light boxu si myslim je dobry, neopoustim aktualni stranku, takze se k ni nemusim vracet, zakryje pozadi a do popredi zobrazi obrazek tak jak se vejde no view, neroztahne se vic a kdyz sou ovladaci prvky stale na stejnem miste je to idelani.

Zacilnal som s PHP a pisal som proceduralne webstranky. Teraz robim OOP s PHP a bez unit a integracnych testov si neviem predstavit continuous integration.

Unit testy mi z velkej casti nahradili debuging, nutia ma pisat jednoduchsie triedy a kazdy riadok ma presne dany zmysel, nie je priestor pre prasaciny + reporty mess detector, code violations, checkstyle atd. je neskutocna pomoc ak chcete softwer vyvijat dlhodobo.

V takomto prostredi vyzera vyvoj nasledovne: developer v SDK naprogramuje balicek s testami. Ked su u neho testy passed posle commit do repozitara. CI server potestuje balicek a urobi build balicka a ostatnych zavislych balickov. Ak vsetko svieti OK moze sa spravit release. Odkedy toto dodrzujem moj zivot programatora ma opat zmysel.

S TDD viem ze si mozem dovolit refactoring a neboli ma od strachu zaludok.