Já testuju nadvakrát - nejprve kód, který zrovna píšu a potom i aplikaci jako celek. Všechno ale dělám ručně, jediná "automatizovaná" věc, kterou používám, jsou scripty, které generují náhodná data a cpou je aplikaci do chřtánu - a já sleduju jestli to někde vyplivne chybu.
Zatím jsem nenarazil na rozumný návod jak psát nějaké lepší testy. Hlavně v případě PHP mám pocit, že testování není moc v módě.
aura:93
V PHP v módě není, to je pravda, i když se Jiří Knesl snaží ze všech sil... :) Já jsem to dělal podobně, no a jednoho dne mi došlo, že vlastně píšu unit testy bez štábní kultury (plné "die()" a "print_r()"). A stačilo už jen dodat tu "kulturu" (v podobě nějakého nástroje pro unit testy), podmínky nahradit assert(), a měl jsem s minimální prací krásné strojové testy i s přehlednými výsledky. A psaní testů? Jakmile se pro ně člověk nadchne a baví ho, tak mu to jde už jen líp a líp... :)
Existuje spousta zpusobu, jak testovat. Ten uplne nejjednodussi zpusob vypada nejak takto:
function check($msg, $condition) {
echo ($condition ? "OK\t" : "FAIL\t"), $msg, "\n";
}
check("value je cislo", is_numeric($value));
check("uzivatel byl prihlasen", $login->is_logged_in());
check("html bylo vygenerovano", strpos($html, '<body>')!==false);
aura:93
má někdo tip na prostředí pro unit testy v javascriptu? něco, co bude chodit na všech prohlížečích, bude se s tím hezky delat, asynchronost nebude problém?
dík
aura:93
Ten jsem četl.
JSUnit - potřebuje tomcat
FireUnit - potřebuje firefox
QUnit - potřebuje jquery, což bych mu odpustil, ale je "... právě pro testování tohoto frameworku", ale já potřebuju testovat cokoliv jenom je jQuery
Já ale potřebuju něco co, co je univerzální jak přes webové prohlížeče, tak přes použité knihovny a pokud možno to nemá serverovou část.
dík
aura:93
U JSUnitu není, jestli tomu dobře rozumím, ta serverová část povinnáů ta slouží jen jako "sběrač dat" při distribuovaném testování...
Doporučuji JSTestDriver http://code.google.com/p/js-test-driver/
... Řekněme, že budeme testovat HTML generátor, který generuje stránky ze záznamů v databázi. Namísto objektu, který přebírá data z databáze, podstrčíme „mock“ – jednoduchou třídu, která má stejné rozhraní, ale na getTextById() vrátí testovací „Lorem ipsum“. ...
PROČ? Píšu-li aplikaci pracující s databází, mám testovací databázi a pracuji přímo s ní. Nemám-li databázi, píšu něco jiného. Tahle část unit testingu mi přijde zcela pošahaná - pokud mi něco chybí, tak to někde splaším nebo napíšu, proč psát nadvakrát mock a pak vlastní komponentu?
aura:93
Jednotkové testování je od toho, aby testovalo jen konkrétní jednotku, proto mock.
Představte si, že v té databázi budete mít políčko, a v něm "maximální počet přečtení článku". Třeba 10. Každé vygenerování článku a poslání uživateli toto číslo o 1 zmenší, pokud bude 0, vrátí se chybová hláška, že už nelze číst.
Když to budete testovat s reálnou databází, musíte ji před každým testem naplnit testovacími daty a po proběhnutí testu ověřit, že se změnily tak jak se změnit měly (a na to abyste měl další test, že?) Testovacích případů je v jednom testu třeba třicet; pro všechny budete naplňovat databázi připravenými daty a pro všechny budete kontrolovat, zda se změnily požadovaným způsobem. To je obrovské množství závislostí, které se mohou na testu projevit - databáze nebude dostupná, spoléháte na to, že databázová mezivrstva funguje spolehlivě, atakdál... Mock naproti tomu bude v podstatě jen "return testovaci_data".
Naprostý souhlas. Pokud spoléhám na databázi, musím zajistit že je v každém okamžiku testování konzistentní a naplněná daty která očekávám. Když použiju mock, neřeším databázi vůbec, poběží to všude (na stroji vývojáře, na serveru s continuous integration), poběží to svižně. Odhalím chybu v kódu, ne v připojení, ne ve špatné databázi. A to je to co potřebuju. Kdybych chtěl do testování zatahovat databázi, už to nebude unit test, testuji pak funkčnost celého ekosystému...
mastodonte sám si pošahanej
makam tady na projektu, aktuálně máme 1808 unittestů, podle tebe bych měl pro každej test inicializovat testovací databázi a ještě k tomu dost možná pokaždý jinak; ani nápad
test používající databázi není unittest!
přečti si TDD by example
aura:93
OT: Všimněte si, že poslední věta by rozhodně nevyzněla tak útočně, kdybyste ji napsal jako "V TDD by example je to vysvětlené", ta pasáž "podle tebe..." by určitě vypadala líp, kdyby byla formulovaná obecně, nikoli jako ukazování na někoho (třeba "v takovém případě bych musel..."). No a k tomu pošahání - chápu, že to je reakce na mastodontův komentář, kde tohle slovo použil, ovšem v souvislosti s věcí, nikoli s osobou. Kdyby byl na konci smajlík, tak by to neznělo jako útok...
Zkuste se, prosím, zaměřit raději na podstatu problému a vyhnout se "komentování komentujícího". Děkuji.
Zajímavé je, že v článku (a nejen tam, obceně) se propagují hlavně unit testy. Nevím, jestli je to jen má zkušenost, ale většina mých testů jsou testy integrační, které testují více "jednotek" najednou - samotné unit testy používám velmi zřídka a ještě je dost šidím (dělám do nich více assertů, což by být nemělo atd.).
V praxi se mi integrační testy osvědčily více, jelikož s kvalitními a podstatné věci pokrývajícími unit testy je nesrovnatelně více práce.
V poslední době jsem též přišel na chuť testům uživatelského rozhraní, na které se všem doporučuji podívat - ať už Selenium, nebo Code UI Tests ve Visual Studiu - ušetří to spoustu času při proklikávání u větších webových aplikacích, a i když vytvoření testů trvá třeba celé odpoledne, velmi brzy se tato investice vrátí.
Mimochodem v článku zmiňovaný příklad s CAPTCHA mi nepřijde moc šťastný - zrovna funkce, která generuje captcha nebude mít téměř žádné závislosti na okolí, takže tu bych klidně jednou po dopsání otestoval ručně a pak se s ní vůbec nezabýval - změna kódu někde jinde ji velmi pravděpodobně neohrozí.
Testovat bychom měli začít od věcí, u nichž čekáme, že se nám budoucími úpravami kódu rozbijí, a psát testy tak, aby nám pomáhaly a šetřily čas, tzn. například podívat se do source control, ve které třídě pořád něco opravujeme, a zkusit ji otestovat.
aura:93
1. Proč unit testy? Protože v mnohých jazycích / frameworcích je jejich podpora zabudovaná a je relativně snadné s nimi začít. Na webu, kde polovina čtenářů "prostě netestuje" (viz loňská anketa) je asi nejdůležitější prolomit tuhle averzi.
2. Pardon, ale větu "integrační testy se mi osvědčily více, protože s unit testy je víc práce" jsem buď nepochopil, nebo jste měl slabší chvilku při jejím psaní. :) Vždyť každé testy testují něco jiného a mají jiné použití, to je jako říct "těstoviny se mi osvědčily víc než maso, s masem je spousta práce". Tyhle věci patří k sobě, jedna nenahrazuje druhou (viz pohádka, kde král nahrazuje sůl kořením).
3. Selenium a spol. je rovněž velmi zajímavá oblast a určitě se k ní dostaneme.
4. Příklad s CAPTCHA je reakce na komentář Franty Kučery u předchozího článku - jako modelový příklad toho, kde unit testy (budeme-li je psát) mají skončit. Franta totiž použil generování obrázků (konkrétně grafů) jako příklad toho, kde budou unit testy mnohem složitější než knihovna sama - ovšem problém byl opět v doslovné, mechanické aplikaci teorie: "Otestovat všechny výstupy strojově".
1. Myslím si, že unit testy u mnohých tu averzi ještě prohloubí, protože člověk se rozhodne začít s testováním, ale hned narazí na problém s tím, že je třeba se nějak vypořádat se závislostí na databázi apod. A když googlí články o testování, tak najde převážně kopec příkladů, které testují třídu na sčítání dvou čísel (která tedy nemá žádné závislosti). Takový člověk pak může snadno propadnout zoufalství a na testování se vyprdnout. Nebo taky začít více hledat a ptát se zkušenějších (moje cesta).
Co tím chci říct? Unit testy jsou sice základ a na úplný začátek se hodí s nima člověka seznámit, ale co nejdříve bych takovému člověku ukázal integrační testy, který mají IMHO větší výkonnost (poměr užitek/čas).
2. Můj pohled je prakticky stejný jako Tomáše - přistupujeme k testování pragmaticky. Začal jsem psaním integračních testů, kde mám v jednom testu více assertů a píšu je dodnes.
Jak člověk do testování praxí pronikne, tak mu začne být jasné, že jdou testy psát lépe (tj. psát i unit testy), ale nemyslím si, že je to vždy nutné (vzhledem k úsilí, jaké musí člověk vynaložit na napsání supr-dupr unit testu).
Btw. když má člověk pokrytí unit testy 100 %, pokrytí integračními testy 100 %, jaké je celkové pokrytí? 200 % [joke] :-)
aura:93
Souhlasím a myslím, že to je dobrý námět na článek... Je tu nějaký dobrovolník, který pracuje jako vývojář a má s tíémhle zkušenosti? ;)
> ale hned narazí na problém s tím, že je třeba se nějak vypořádat se závislostí na databázi apod
Ak narazi na takyto problem, potom ma zly navrh aplikacie. To znamena, ze ten test este ani nanapisal ( pretoze ma problem ), ale uz ma vysledok ( je to zle ).
Tiez som si volakedy daaavno myslel, ze testovanie nesmie mat dopad na navrh/kod samotnej aplikacie. Opak je vsak pravdou.
Aplikaciu (moduly) je potrebne navrhovat tak, aby sa dala jednoducho unit-testovat. Vysledkom takehoto navrhu nie je iba usetrenie casu pri pisani unit-testov, ale castokrat aj cistejsi/jednoduchsi navrh aplikacie, ktora sa lahko udrziava/modifikuje, ma ciste komunikacne rozhrania.
Riesenim pre mna bol dosledny prechod na pattern DependencyInjection/Inversion of control
Souhlas - chtěl jsem to napsat do toho mého prvního komentáře, ale zapomněl jsem na to :-) Tj. závislosti v aplikacích musí být dostatečně volné, aby bylo možné aplikaci rozumně otestovat.
aura:89
Pokud se jede podle TDD a testy se píší před kódem, tak funguje "magie", že netestovatelný aplikační kód prostě nenapíšete. Ono je to docela logické.
Selenium testy jsme začali používat relativně nedávno. Je to kus práce napsat test dobře, tak aby nebyl plný nepodmíněných čekání a nerozpadl se při prvním zásahu do ui. Na druhou stranu opravdu ušetří kupu klikání a provádí se sám, "zadarmo", při každé nové revizi projektu. Selenium jsme si také přizpůsobili druhé formě testů, té "kouknu a vidím". Udržujeme v chodu něco přes 20 webů a není v lidských silách po každém updatu sledovat jestli se něco nerozsypalo (layout, chybí obrázky, přetékají bločky). Proto jsme spustili selenium grid, do něj zapojili virtuální stroje, generujeme tři sady screenshotů vytipovaných důležitých stránek. Jednou pro linux/ff, jednou win/ie6 a jednou win/ie9. Tyhle obrázky se po vyrenderování natahnou do jednoduché stránky, kde není problém je za chvilku proběhnout a očima zkontrolovat, že se nic nerozpadlo. Nemusím nikam klikat, nic načítat, jen buším do mezerníku a listuju sadou obrázků. Celý proces se spouští z continuous integration serveru s commitem do stable větve gitu. Během 10 minut se vrátí email s linkem na přehled. Chce to jen zodpovědného člověka, co to na konci opravdu proběhne a podívá se že to dopadlo ok.
Formuloval jsem to nešťastně - testovat každou jednotku mi přijde velmi pracné a místo 150 unit testů je podle mě efektivnější (lepší poměr pracnost x užitná hodnota) napsat několik integračních testů, které testují ty samé jednotky, ale po skupinkách, a už simulují nějaké reálné scénáře. Kde je chyba, to zjistím snadno i z integračního testu, a to je cílem testování - lokalizovat chybu a umožnit její opravu.
Takže to není jako s tou pohádkou.
Ještě jsou tu ale případy, kdy pro test nemůžeme využívat obyčejné instance tříd, ale musíme dělat mocky a unit testy psát.
Typicky v situaci, kdy se třída nechová deterministicky, je její sestavení příliš náročné, nebo je prostě používání klasických instancí výpočetně příliš drahé.
V takovém případě se hodí psát unit testy.
Ale souhlasím v tom, že integrační testy odhalí více chyb než unit testy. Unit testy pomáhají spíše návrhu.
aura:80
Ja osobne kdybych delal generator CAPTCHA, tak bych si na to unit testy napsal, krome zakladnich ktere by porovnali jestli vraci obrazek pozadovane velikosti bych pak generator pustil s nejakym fixnim nastavenim a vygenerovany obrazok rucne skontroloval a pouzil jako "expected" pro novy unit test.
Pro uplnost ("triangulaci") bych to udelal jeste jednou pro jinou sadu parametru.
Takze kdyz treba v budoucnosti vypadne z bezne instalace pozadovany font nebo se zmeni verze graficke knihovny a bude tam chyba, tak vim ze mi unit testy neprojdou a budou hlasit nesrovnalost v obrazku. Kterou jednoduse rucne skontroluji a budu alespon tusit co se deje.
Tohle uz neni uplne unit testing, to je spis QA testing, ale vzhledem k tomu ze vetsina zapeklitych chyb ktere jsem kdy ve svych aplikacich resil pochazela prave od treti strany (upgrade knihoven, platformy, chyby v kompilatorech a pod.) a ve svem kodu temer zadne nedelam, tak radeji pisu unit testy spis v "QA" rozsahu. Setri mi to pozdeji pri udrzbe spoustu casu, kdyz presne vim kde se nejaka nesrovnalost zacina projevovat, nez ji hledat nekde o nekolik vrstev dal pote co odchylka projde nepovsimnuta skrz muj kod.
aura:90
Ad 4) jen taková poznámka: ten můj komentář byla odpověď na otázku: „Můžete mi uvést příklad, kdy trvá řádné napsání testů dvě hodiny, A ZÁROVEŇ je možné vše, co testují tyto testy, otestovat "ručně během dvou minut"?“
Sám od sebe bych s tímhle tématem nepřišel ;-)
Ja v PHP testuju cca pul roku. Driv jsem psal stylem "pisu, pisu", f5 - vidim.
Takovy postup Zaprve hazarduje s vysledkem v pripade, ze vyvyjim slozitejsi veci s vrstami logiky (99%) a za druhe unavuje, protoze rychlejsi psani kodu je neblaze vyvazeno hrubym odhadem 30% energie spotrebovane na soustredeni pri manualnich kontrolach funkcnosti.
Z testu pouzivam samozrejme unit (ktere vyuzivam i na blackbox testy) a potom BDD behat.
Musim doporucit tenhle trial http://www.slideshare.net/avalanche123/clean-code-5609451?from=ss_embed
...od Chucka Norrisa :-)
ahoj Martine, nechci urazit, ale poslední dobou pozoruji, že se ze Zdrojáku stává něco jako tvůj blog místo IT serveru.
ne že by to občas nebylo zajímavé, ale uvítal bych trochu profesionálnější formu -- psát to víc formou článků a méně zápisků do blogu.
Titulek tohoto článku taky zní jak kdyby to byl nějaký dlouhý komentář do diskuse, který nakonec vyšel samostatně.
Tak mi přijde, že se zdejší komunita trochu uzavírá do sebe a žije sama sebou -- takové to "oni nám napsali nesmysli do diskuse, tak jim to vysvětlíme v článku"
a pod tím článkem je zase další diskuse... a tak pořád dokola.
Nemyslím si, že autor by měl diskusí pohrdat a vůbec tam nechodit -- to by měl, a měl by snad i odpovídat, ale asi ne touto formou.
Co se týče obsahu, taky mi přijde, že to má trochu sestupnou tendenci. Jasně, chápu, že vysoce odborné články nepřitáhnou dost lidí a reklamy...
nějaký ten "povídací" článek občas může být, ale raději si přečtu dobrý technický text než špatnou glosu - a to i kdyby ten článek byl z jiné oblasti, než kterou aktuálně řeším
aura:93
Ahoj Opravdový Odborníku Se Smajlíkem,
tak už to v životě chodí. Víš, čtu reakce "Zdroják se poslední dobou zvedl, víc takových článků" a čtu i reakce "Piš si to do blogu!" A víš čím se já řídím? Řídím, se, a odpusť mi, Opravdový Odborníku, ostřejší slovo, příslovím: Čůráme jen tak vysoko, jak můžeme. Jistě si to dovedeš přeložit z obrazného vyjádření...
Pokud chceš ale nějak víc přispět k oživení Zdrojáku, ať už radou, či pomocí, uvítám tvůj návrh na redakčním mailu redakce@zdrojak.cz.
(a prosím nehledej v mé odpovědi žádnou ironii nebo kousavost, myslím to naprosto vážně)
aura:93
Dovol mi ještě PS, ano? Začneme seznamem článků za poslední měsíc:
14.2. Cappuccino: prohledáváme Twitter
15.2. HTML5: První krůčky s FileSystem API
16.2. WordPress knižně (MM)
17.2. Přechod z MySQL na CouchDB, část první
18.2. IPO48: startupy ve znamení marketingu a UX
21.2. S3: hostujeme statický web v cloudu během pěti minut (MM)
22.2. Přepínání vykreslovacích režimů Internet Exploreru
23.2. * Ako sa nerobí startup alebo poučte sa z mojich chýb
24.2. Přechod z MySQL na CouchDB: Druhý díl
25.2. * Konec starých programátorských časů (MM)
28.2. 15 cest k lepší přístupnosti vašeho webu - I
1.3. Praktické použitie MongoDB v .NET
2.3. * Vybíráme jméno pro web
3.3. Provozujeme internetové aplikace bezpečně a dlouhodobě udržitelně
4.3. * Uniformita degeneruje myšlení (MM)
7.3. 15 cest k lepší přístupnosti vašeho webu - II
8.3. Javascriptaření: nejen jQuery živ je JavaScriptař (MM)
9.3. Python 3: Úspěšný ponor (MM)
11.3. *Co zaujalo Jiřího Knesla
14.3. *Ještě k testování (MM)
Hvězdičkou jsou subjektivní (6), označené jsou moje (7), moje glosy jsou celkem 3. Celkem vyšlo 20 článků. 35% článků jsem tedy napsal já, 30% je subjektivních, 9% jsou moje glosy. Neměl bych mít na blogu tahle čísla někde u stovky? ;)
Čímž nijak nepolemizuju s tvým dojmem, rozhodující je, jak to na čtenáře působí. Ony ty subjektivní glosy přitahují pozornost, proto si je snáz zapamatuješ, a za týden si vybavíš jen je. Po pravdě řečeno já si dnes ze starých IT periodik taky vybavím jen Kofránka, Zajíčka, Maniše, Straku a Koubskýho. :)
Schválně jsem se dnes podíval na titulní stránku -- odshora až dolů Martin Malý (až na jednu výjimku). Chtělo by to s tím něco udělat. Taky zkusím něco napsat...
mě to přijde v cajku. článek sice reaguje na komentáře, ale je dost obecnej, takže to není nějaký dohadování uzavřený skupiny lidí, jak píšeš. nemám pocit, že je to tu blog p. malýho. jeho glosy jsou mi někdy sice proti srsti a nesouhlasím s tím co píše, ale rád si je přečtu. čistě technickejm článkům tu taky nemám moc co vytknout. to, co tu p. malý dělá, mi přijde jako rozumnej kompromis mezi čtivostí a odborností a u mě jako dobrý.
Zajimalo by me jestli ma nekdo nejaky napad, jak rozume testovat aplikaci psanou v databazi. Klientska cast se v podstate nemeni, ale veskera logika aplikace je napsana v databazi v ramci funkci a triggeru, prav...
Na funkce, ktere nevyzaduji data z aplikace samozrejme unit testy napsane mam, ale jakmile jsou potreba nejaka data v databazi, ktera se navic v case meni, jsem nahrany. Bylo by mozne bud data v databazi testovat s minulym casem - na serveru nastavit napr. rok 2000 a ten tam porad udrzovat, nebo neustale aktualizovat data v databazi (v mem pripade se jedna o databazi s cca 150 tabulkami, cca 600 triggery vcetne funkci a cca 400 dalsich funkci). Mam sice napsanych i nekolik dalsich testu, ktere poustim vetsinou na realnych datech (ktera se prubezne meni a akceptuji zmenu data) ovsem vysledkem je ze nad testovani stravim nekolik hodin, protoze si zduvodnuji jednotlive chyby, ktere vlastne ani chybami nejsou, ale holt v te databazi je to nastaveno jinak, nez jak jsem cekal a testoval u predchozich 20 jinych databazi.
V podstate narazim na to ze zatimco u testovani funkce nezavisle na databazi mam nekolik promennych, u funkce na databazi zavisle mam promennych nekolik set, na coz je nerealne napsat testy a pokud se nejake nekompletni testy napisou, nemaji velky vyznam.
Pokud je to takhle zapečené všechno dohromady, tak bych to asi udělal tak (neznám přesně tvoji situaci), že bych měl vedle testovací databázi. Testovat něco jiného než read-operace na živé databázi mi nepřijde dobré (ale chápu, že okolnosti tě tam mohly dohnat).
Testoval bych pak asi nějaké use-cases a test by vypadal takto: uvedení databáze do potřebného stavu, spuštění use-casu, vyhodnocení.
Tak nějak si představuji programátorské peklo ;)
aura:90
Když jsem pracoval na podobném systému, měli jsme pravidlo, že se v procedurách nesměl používat SYSDATE (nebo jeho ekvivalent v jiném SŘBD). Pokud procedura měla provést akci k určitému okamžiku, dostala přesná čas jako parametr. Nejde jen o nějaké testy, ale i o to, že je možné synchronizovat různé databáze a neohrozí to ani taková „maličkost“ že se na jednotlivých serverech rozjedou hodiny.
V triggerech je to horší, ale tam by zase šlo místo volání nativní časové funkce volat nějakou vlastní – ta se na testovacím serveru přepíše tak, aby vracela něco jiného – třeba pořád stejný čas.
Pro spouštění testů bych klidně použil JUnit framework. Nebudou to sice klasické jednotkové testy, protože se bude testovat i komunikace mezi Javou a databází, ale to ani není na škodu. Testy se dají podědit, takže toho psaní bude málo – budou téměř zcela deklarativní – jen napsat vstupní parametry a očekávaný výstup.
U nas v praci jsme si udelali build skript, ktery vytvori cistou DB (nekolik schemat, x set tabulek, funkci, procedur a baliku) a pak se do ni naimportuje testovaci sada dat (dataset). Pokud to jde tak by to melo probehnout co nejrychleji aby clovek nemusel zbytecne cekat. To jsme castecne vyresili pouzitim RAM disku + optimalizaci nastaveni Oracle tak aby vytvarel objekty s minimalni velikosti.
Vzhledem k pouziti datasetu, jde lehce dohledat jake data bude nove vytvorena DB obsahovat a ty pak jdou vyuzit v testech. Po kazdem testu se v teardownu zavola ROLLBACK. Pripadne pokud se testuje neco co bezi v autonomni transakci tak si to test po sobe uklidi rucne.
+1 za osvetu (unit)testovani. :) Hezky clanek.
Osobne za nejvetsi vyhody, ktere mi TDD prinasi pokladam:
1. Pokud neco prestane fungovat, tak mi Unit-Test s velkou presnosti ukaze, kde je problem.
2. Pokud je psani nektereho testu problematicke, beru to jako upozorneni na chybu v designu. (funkce/metoda/objekt toho dela vic nez by mela, ma zbytecne moc zavislosti, atd...)
3. Nejdriv resim CO od nove psane metody/objektu ocekavam, a az pak to, JAK to budu implementovat.
4. Kdyz mi projdou vsechny testy - vim ze mam hotovo.
...
X. U web aplikaci nemusim po kazde zmene klikat jako cvicena opice dokola na to same :)
A opět tady vidíme v akci skvělou fíčuru "zašedivíme jiný názor". Usabilita naprd, informace nulová, akorát to překáží ve čtení.
jiny nazor. ale mne spis pripada, ze zasedivuji nahodne vybrane! jinak souhlas, je to k nicemu, ve cteni to prekazi a pouzitelne to neni.
Zdroják (www.zdrojak.cz), o tvorbě webových stránek a aplikací. ISSN 1803-5620
Vydává Devel.cz Lab s.r.o. ve spolupráci s Internet Info, s.r.o. Všechna práva vyhrazena. Powered by Linux.
