Vlákno názorů k článku Test-driven development v jazyce Java od deda.jabko - Nejak mi chybi vysvetleni, proc nepouzivat JUnit, ktere...

Nejak mi chybi vysvetleni, proc nepouzivat JUnit, ktere je integrovane temer v kazdem IDE. Navic pouzivat automaticke testovani bez nastroju, ktere zobrazi code coverage, je docela o nicem, protoze tak clovek nema poradne jistotu, ze je testovano uplne vse, co by testovano melo byt. A posledni pripominka: Proc, sakra, autor pouziva nazvy trid zacinajici malym pismenem?

Tiez si to myslim. Uplne zbytocny clanok. A to nehodnotim fakt ze assert je primarn urceny na uplne ine veci

Podla mna tiez - "ten klasicky" assert sa pouziva na overenie, ci mi v ramci mojho modulu chodia pripustne odpovede. Asserty su zapnute stale pocas "bezneho" testovania a mimoprodukcneho behu systemu. To znamena, ze ked niekde (interne) pouzivam nejaky objekt, tak takmer vzdy automaticky na zaciatok kazdej metody s nim napise nieco ako assert obj != null;
Ked mam iny predpoklad dany logikou aplikacie, tak ho dam do assertu - to v produkcii nic nestoji a vyrazne to ulahci debug.

Tento assert nie je o tom, ze by sa pustal ako testy - sluzi na to, aby program spadol co najblizsie chybe. U Javy je sice pekny backtrace, ale prechadzat 20 funkcii, cez ktore sa to predavalo, zaberie ovela viac casu ako 20 "automatickych" riadkov.

Assert ma podla mna pokryvat vsetky "ocakavania" vnutri jedneho API. (Ak to je nieco mimo API, tak hadzem vhodnu Exception).

Testy oproti tomu pokryvaju len velmi male casti kodu. V nich snad vobec nema zalezat na assertoch (aky zmysel by toto tu napisane malo bez zapnutych assertov?). Ak si niekto z pre mna nepochopitelnych dovodoch chce robit testy mimo JUnit, tak tam by som namiesto assertov asi skor throw novej Exception, ktora bude podedena od java.lang.Run­timeException.

Ja obycajne pisem 2 nezavisle testy (co do testovanych parametrov) pre kazde ocakavane chovanie. Vyhody su snad jasne - ked sa nieco rozbije, tak sa to casto rozbije tak, aby to cez 1 test zhodou okolnosti preslo. Niekto sa tu pytal, ze preco? Ja to robim preto, lebo mi to hned ukazuje pouzitelnost mojho API (tam, kde ho mam), problemy s nim pri implementacii, robi to ukazku jeho pouzitia a zaroven to odchyti velku cast programatorskych chyb.

Autor článku je zdá se totálně mimo. Nejspíš si zrovna přečetl pár stránek o TDD, napsal Hello world v Javě a rozhodl se napsat tento "článek". To se ani nedá slušně komentovat. Možná úvodník do série článků o "bad practices" v Javě?

Také to vypadá, že autor žádné IDE nepoužívá, jinak by k tomu, aby zjistil, že třída neexistuje, nemusel kompilovat, ale viděl by to hned. Zřejmě také ještě neobjevil klíčové slovo import, jinak by snad nenapsal takovou hovadinu, jako že kompilátor sám někde najde nějakou tridu stejného jména. To leda by se autor náhodou strefil svým balíčkem zrovna do nějakého existujícího na jeho classpath, ve kterém by náhodou byla stejnojmenná třída.

No nemá cenu se rozčilovat, jdu raději spát. Jen mě překvapuje, že na root.cz, který jinak považuju za kvalitní web, pustí takovouhle hrůzu.

Aky zmysel ma pouzivat nieco co je od zakladu zle? Nehladiac na fakt ze zaciatocnik si stiahne ide a tam uz vsetko ma. miesto aby sa to naucil rovno spravne tak sa nedajboze inspiruje vasim "riesenim".

> Kvalita kodu v testovacich tridach je esencialni

TDD mantra podle Becka: red, green, refactor

já teda refaktoruju testy až když uznam za vhodný, tj. klidně hned, ale když je to nějaká prkotina kterou (zatim) nezrecykluju, tak na to ani nemusí dojít

ale nemluvim o konvencích v pojmenování, ale o kvalitě kódu testů

"Není to produkční třída, ale testovací. Tu je možné napsat jakkoli, na kvalitu kódu se nehledí."
Tak tohle me presvedcilo, ze ani clanek nema cenu cist.