změňme defaultní skeleton

jiriknesl

Navrhuju do skeletonu (do složky app/) přidat složku tests/.

Taky bych bral v dokumentaci vzorové příklady testování phpUnitem, interním unit testovacím nástrojem, seleniem.

Ondřej Brejla

To je moc dobrý nápad, jsem jak pro složku tests (ať už kamkoliv), tak hlavně pro příklady testování…

Patrik Votoček

jiriknesl napsal(a):

Navrhuju do skeletonu (do složky app/) přidat složku tests/.

Proč? co by obsahovala?

Honza Marek

Já bych spíš zrušil FeedPresenter… Složka test v app je asi zbytečná. Osobně bych testy dal někam mimo, aby se nenahrávaly na server.

Ondřej Mirtes

Mám složku tests/ v rootu, tzn.:

app/
document_root/
tests/
libs/

BTW: Těším se na tvojí přednášku o TDD v Nette :)

Editoval Ondřej Mirtes (14. 1. 2010 11:44)

David Grudl

Přidat tests je dobré symbolické gesto :-) Jen bych to umístil do rootu, jak píší ostatní.

Koukám, že se tam někde vytratily adresáře document_root/js a controls. Vrátím je, jen váhám, jestli controls by nemělo jít taky do rootu.

jiriknesl

Po Webexpu bych mohl k dokumentaci (nebo jako článek na PHPFashion) nabídnout vzorovou aplikaci v Nette napsanou pomocí TDD (Test-Driven-Development) a BDD (Behaviour-Driven-Development) s využitím PHPUnitu.

Teda jestli ji do Webexpa stihnu dokončit. :)

Ondřej Mirtes

David Grudl napsal(a):

Přidat tests je dobré symbolické gesto :-) Jen bych to umístil do rootu, jak píší ostatní.

Koukám, že se tam někde vytratily adresáře document_root/js a controls. Vrátím je, jen váhám, jestli controls by nemělo jít taky do rootu.

controls/ == app/components/, ne?

Ped

jiriknesl napsal(a):

Po Webexpu bych mohl k dokumentaci (nebo jako článek na PHPFashion) nabídnout vzorovou aplikaci v Nette napsanou pomocí TDD (Test-Driven-Development) a BDD (Behaviour-Driven-Development) s využitím PHPUnitu.

Teda jestli ji do Webexpa stihnu dokončit. :)

Chysta se neco? Snazim se zrovna rozjet novy projekt nad PHP+Nette stylem TDD a zatim s tim hrozne valcim, hned na nekolika frontach najednou.
Jen tak pro informaci s cim vsim valcim:

phpunit definuje T_NAMESPACE, co se pobije s Nette RobotLoader.php https://github.com/…300c8cbe9c7f (mozna to vyresi prechod na php 5.3?)
pri TDD mi prijde dost neprakticke definovat strukturu databaze v databazi, takze zatim vaham co s tim, nejpravdepodobneji reknu papa dibi a skoncim u nejakeho ORM ktere podporuje generovani DB z modelu (zkousim Doctrine, vypada to nadejne (umi vygenerovat strukturu DB, umi mysql, umi sqlite:memory), ale jsem uplne na zacatku).
Vize je takova ze DB model je definovany v PHP kodu, testy nacitaji modely a pak pred kazdym testem muzu relativne levne (rychle) udelat drop/create databaze nad sqlite:memory, kde pak probehne samotny test. Doufam ze to bude dost rychle aby to treba zvladlo i 500 testu za vterinu, dve. V produkcnim kodu se pak stejnym postupem vytvori ostra databaze (mysql nebo neco jineho, cca. by to melo byt jedno)

Ma s tim nekdo prakticke zkusenosti a jak to resite vy? A je ta vize rozumna, nebo to ma nejaky zrejmy zasadni problem, proc to urcite fungovat nebude?
kosmetika: nelibi se mi moc ten phpunit vystup, jak teckuje jednotlive testy, ma tam hlavicku s verzi a jmenem autora, atd.. a nakonec jeden radek „OK (2 tests, 5 assertions)“, se mi to v tom trochu ztraci.. :) Mne by docela stacil ten posledni radek + chybove mista, ale prijde mi trochu blbe kvuli tomu delat dalsi wrapper nad phpunit ktery by ty vysledky prezentoval jinak. Presto kdyby po tom byla vetsi poptavka a shoda jak to udelat lip, tak bych do toho i sel.
k testovani presenteru jsem se jeste ani nedostal, ale videl jsem neco na foru + mam zdrojaky z webexpo prednasky, takze kdyz vyresim zakladni kolize phpunit vs nette, tak tohle uz asi pujde hladce.
Presto pro jistotu, neni z webexpa i nejake video dane prednasky?

Diky za pripadne rady a namety k premysleni.

Ondřej Mirtes

Tou vzorovou aplikací Jirka myslel asi ty zdrojáky z Webexpa :)

Každopádně jeden takový pokročilý Skeleton píšu, myslí i na TDD (společný bootstrap, skripty pro spuštění testů a reportování code coverage). Vychází ze Skeletonu v distribuci, ale přidává spoustu věcí:

více nastavení v configu, např. povolení rout, vynucení rout (pro případ, že selhává mod_rewrite detekce), gzipování, vynucení environment módu – pro případ, že chci na dev mašině vyzkoušet ErrorPresenter či si na produkční mašině potřebuji zobrazit laděnku
integrované Texy (třída BaseTexy pro základní nastavení, AdminTexy pro redaktorskou část a PublicTexy pro veřejné diskuse – dostupné přes helpery texy a texyPublic)
podpora pro Google Analytics – kód uživatele se píše do configu ;)
integrováno několik šikovných komponent – HeaderControl, WebLoader – pomocí něj minifikuji na serveru CSS a Javascript zdrojáky (opět přes nastavení v configu)
pohodlnější práce s formuláři – každý formulář představuje samostatnou třídu s dvěma metodami – addFields() a handleSubmit($values) – díky BaseFormu se nemusím starat o nějaké předávání errorů formuláři, stačí vyhazovat v handleSubmit metodě výjimku IOException a její text se automaticky předá do formuláře jako error – tohle ušetří hodně řádků kódu v Presenteru :)
vyřešená ochrana proti spamu – stačí zavolat addProtection (která je v BaseForm překrytá) či podědit od ProtectedForm a kromě CSRF máte ochranu i proti spamu :)
připravená podpora pro AJAX (jQuery, jquery.nette.js)
nastylované flash zprávičky

Co je potřeba dodělat:

vymyslet a implementovat unifikovanou podporu pro autentizaci a ověřování práv uživatele (kontrolovat každou akci v BasePresenter? Kontrolovat povolení jen u akcí, které mají @secured anotaci?)
lokalizaci – rád bych jednou pro vždy vyřešil překlad aplikace a hlavně detekce a přepínání mezi jazyky
dodělat a integrovat komponentu SiteControl – dají se z ní generovat breadcrumbs, <title>, menu i mapa webu
vyřešit sofistikovaněji vykreslování šablon v komponentách – rád bych si ušetřil řádky jako $this->createTemplate(), $template->setFile() a $template->render() a pracoval s tím jako v Presenterech

S čím mám problém:

Nefunguje mi testování jiného než HomepagePresenteru – viz https://forum.nette.org/…tingresponse
Rád bych tam implementoval toto: https://forum.nette.org/…zpet-a-vpred, ale nevím jak na to
Mám problém s licencemi – „Improved Skeleton“ obsahuje spoustu věcí od třetích stran – Nette, dibi, Texy, jQuery, JavascriptPacker (asi zaměním za JSMin), HeaderControl (dobře, ten je ode mě, ale jde o princip :)) a WebLoader + pro sebe tam mám 960.gs CSS framework (který do finální verze na GitHub asi nedám), tak nevím, v jaké podobě to commitnu na GitHub, až s tím budu spokojený… mám dvě možnosti:
- Složky, kde jsou tyto věci od třetích stran, nechat prázdné a nechat programátora, ať si je sám postahuje – to je hodně zdlouhavé a nepohodlné
- Najít společný průnik jednotlivých licencí a uveřejnit Skeleton v kompletní podobě pod takovou licencí, která by neporušila žádnou z ostatních licencí – nevyznám se v nich a potřeboval bych s tím od někoho pomoci…

Cílím na vývoj podle best practices, takže všechen kód komentuji, do šablon připisuji, jaké všechny proměnné jsou v nich k dispozici, atd. Snad to brzo dotáhnu do konce :)

romansklenar

Testování s sqlite:memory, kde mám cca 25 testů a před každým se provede v setUp() import cca 10 sql dumpů (dohromady asi 1000 řádek) pomocí dibi se dokáže protáhnout až na minutu a s každou další metodou v testu roste. Ani si netroufám hádat, jak dlouho by to trvalo, pokud by se fyzicky zapisovalo na disk.

Na škaredý výpis výsledku testů je jednoduché řešení – Netbeans – mají pro testování skvělou podporu, vypadá to dost podobně jako testování v jUnitu i s grafickým výsledkem testu včetně pokrytí kódu. Dobře se tak odhalují slepá místa aplikace.

Patrik Votoček

Ondřej Mirtes napsal(a):

– Najít společný průnik jednotlivých licencí a uveřejnit Skeleton v kompletní podobě pod takovou licencí, která by neporušila žádnou z ostatních licencí – nevyznám se v nich a potřeboval bych s tím od někoho pomoci…

Tady není moc co… Texy! je GNU GPL v2/3 takže…

Ped

roman: ten import radku pro unit testy ja nepotrebuji, tam mi nevadi kdyz kazdy test zacina v prazdne tabulce, takze ja budu „jenom“ vytvaret strukturu mezi testy. Vetsi mnozstvi radek budu importovat jenom pro QA testy, ktere bych v ramci TDD nespoustel, jenom pri nejakem „finalnim“ commitu nebo tak jednou denne. O par tydnu se snad budu moct podelit s nejakymi praktickymi zkusenostmi jak moc tohle funguje.

Ondrej: z tech licenci co znam vidim problem s Texy, zbytek je myslim bud ideove ok (jeste muze nekompatibilni samotna licence, az tak je z pameti neumim), nebo ho neznam (v podstate vse od jQuery dal … jQuery ma myslim tu hezkou licenci jenom pro dobry software, ne? S tim muzes mit teoreticky taky problem).

Jinak to zni hodne dobre, jenom pokud muzes, tak bych poprosil o tak kvalitni dokumentaci, aby nebyl problem z toho vykuchat nekterou vec kterou nechci (treba si reknu ze Texy nechci .. tak dokumentace kde vsude je potreba neco zmenit/smazat).

Na ten problem s testovanim presenteru se v prubehu 2–4 tydnu asi budu sam divat, tak dam vedet na co jsem prisel. Ted experimentuji hlavne s testovanim DB, mam pocit ze pro TDD je docela klicove abych tohle mel vyresene opravdu dobre. A nerad bych delal nejaky DB_mock_engine ktery by simuloval MySQL, takze zatim smeruji ke znasilneni sqlite:memory, co by melo byt zhruba presne to same jako nejaka mock DB pro testy.

Ped

jenom takove kratke pouceni z krizoveho vyvoje…

pouzivate phpunit?
A neco se zacalo chovat hrozne divne a neco z toho mate v globalni promenne?
Zkuste nejdriv –no-globals-backup, jestli se chovani nezmeni.
Nekterym slozitejsim objektum (treba sqlite driver z doctrine) nedela serializace moc dobre a nejakym zpusobem ktery jsem ani nedokazal dohledat se neco zmeni a nefunguji uplne dle ocekavani.
(takze jsem connection prestal tahat z globalni promenne a v kazdem testu se na ni znova zeptam Doctrine_Manager::getInstance()->getConnection(‚nazev‘); … pak funguje vsechno dle ocekavani … stejna vec ulozena do globalni promenne jaksi „zvetra“, asi jako pivo)

Honza Marek

DibiConnection dokonce rovnou při pokusu o serializaci vyhodí výjimku.

Ped

Honza Marek napsal(a):

DibiConnection dokonce rovnou při pokusu o serializaci vyhodí výjimku.

To aspon hned vis ze je neco spatne… :) Ten doctrine nad MySQL funguje dle ocekavani, nad sqlite jako by ztratil pojem o aktualni databazi a asi pak dela treba createTables nekam do rootu (neoveroval jsem), protoze v mnou zvolene datazi nevznikne nic, pritom ta promenna z globals je funkcni a kdyz vytvorim tabulku primo, tak je tam. Cim vic nad tim premyslim, tim vic mam pocit ze je to spatne udelana serializace v doctrine sqlite driveru. Ale az tak temto vecem nerozumim, abych se tam podival do kodu a nasel to.

Ped

romansklenar napsal(a):

Testování s sqlite:memory, kde mám cca 25 testů a před každým se provede v setUp() import cca 10 sql dumpů (dohromady asi 1000 řádek) pomocí dibi se dokáže protáhnout až na minutu a s každou další metodou v testu roste. Ani si netroufám hádat, jak dlouho by to trvalo, pokud by se fyzicky zapisovalo na disk.

Tak jsem krome jinych veci jiz napsal nejake prvni ostre testy s prvnim modelem a je to fakt hruza.
4 testy s 9 assertions:
2 testy vytvori kompletni tabulky v DB a jeden radek ulozi/vyberou zpatky
2 testy si vystaci s $x = new XModel() a operacemi nad nim (de facto bez jedineho SQL prikazu)

= +60msec.

Ted mne napadlo jeste zkusit ty 2 co vytvari model osobitne a je to ono, kazdy z nich prida cca. +30msec.
Takze testovani modelu jenom nad instanci je temer zadarmo, testovani nad DB je drahe hrozne moc. (pravdepodobne ten parsing souboru modelu z disku + jejich zpracovani + create tables, i kdyz zatim to je jen jeden model = 1 tabulka)

Jeste jsem zvedav jak moc bude vlastne v testech potreba zapisovat do DB.

U klasickych „ciselnikovych“ objektu to mozna nebude tak spatny, vlastne staci zkusit vytvorit+zapsat a zpatky porovnat, jestli se korektne zapisuji/nacitaji v jednom testu. Zbytek testu muze snad vetsinu casu pracovat nad zrovna vytvorenym modelem v pameti. Jsem zvedav na prumerny pomer testu co si vystaci s instanci vs testy co potrebuji mit i neco v DB.

Jeste by slo v pripade nouze takove testy shlukovat do jedneho velkeho (FUJ!) a nebo ted mne napadlo ze mozna @depends nebo ta druha moznost s prenasenim mezivysledku mezi testy by mohla snizit pocet kompletnich inicializaci DB (male fuj, v pripade ze testy zacnou trvat neunosnou dobu, tak to asi udelam).
Jsem to chtel narychlo zkusit, ale vypada to tak ze vsechny moznosti stejne volaji tearDown, t.j. DB mi to mezi testy zrusi. (alespon @depends urcite)