43 komentářů k článku Testování v PHP: asserty a constraints:

    1. Josef ZamrzlaAutor příspěvku

      Re: Testování v PHP: asserty a constraints

      @see tl;dr Upozorňoval jsem předem, že (alespoň co se assertů týče) jde o referenční popis.

  1. vidya

    ehmm

    ak si chce niekto precitat/vytvorit pomerne zlozitu aplikaciu tdd stylom, uplne krok za krokom a nevadi mu ze je to pre ruby on rails tak odporucam „Rails 3 in Action“ (zdrojaky). autor pokryva BDD(rspec), integracne testy(cucumber), stubs, mocks, testovanie webservices, testovanie javascriptu … a to vsetko pri vytvarani realnej aplikacie, ziadna referencna priucka alebo trivialne priklady.

    1. prezdivka je povinna

      Re: ehmm

      To jsi tady spatne, pro mistni ctenare je ted aktualni zhava novinka unit testing, behaviour nekdy za 3 roky :-)

  2. Rexxar

    Testovanie

    Neviem si pomoct, ale nejako neviem tomu testovaniu prist na chut…obzvlast pri vytvarani webovych informacnych systemov. Priliz zlozite, zabera to kopec casu a nedokaze to odhalit vsetky chyby. Nebolo by lepsie zaplatit si alfa/beta testerov?

    1. Jerry12

      Re: Testovanie

      Ja jsem toho nazoru, ze unit testy velmi dobre patrej k bussiness logice, ale hnat se bez zamysleni za 100% coverage je u webovejch vetsi casto kontraproduktivni.

    2. vidya

      Re: Testovanie

      ak pouzivas jazyk ktory nie je dostatocne expresivny a fw ktory nemysli velmi na testovatelnost tak to bude tazke. cital som studiu specificky pre rails, vyvoj pri tdd projektoch bol zhruba o 30% dlhsi, ale s o 90% mensim poctom bugov. pri tdd dostanes ako bonus vyrazne lepsiu architekturu kodu, pretoze ak je testovatelny je lahsie modifikovatelny a rozsiritelny a osobne si myslim ze v dlhodobom horizonte sa ten cas na vyvoj este skrati, pretoze ked si zoberiem refaktoring(a hlavne pri dynamickom jazyku) tak neustale preklikavanie vsetkeho co som mohol nejakou zmenou rozbit vs spustenie testov…

      „Our experiences and distilled lessons learned, all point to the fact that TDD seems to be applicable in various domains and can significantly reduce the defect density of developed software without significant productivity reduction of the development team.“ zdroj

      1. arron

        Re: Testovanie

        Mě tu pořád ještě nikdo nevysvětlil, co to znamená „fw, který myslí/nemyslí na testovtelnost“…

        Jasně, pokud budu pracovat ve fw, kterému jenom těžko předám nějaké fake závislosti, tak budou části programu, na které nebudu moc napsat unit testy. Ale tohohle bude ta menší část zdrojového kódu. Zbytek může být normálně otestovaný a fw tomu absolutně nevadí. A ten zbytek se otestuje třeba pomocí integračních Seleniových testů.

    3. arron

      Re: Testovanie

      Jak už tady zaznělo, kouzlo je mimo jiné v tom, že testování nás nutí výrazně zlepšit architekturu. Nicméně je tu i ekonomické hledisko. To, že testy zaberou nějaký čas je jasný. Otázka je, jestli by ten samý čas nezabralo opakované mačkání F5 a pracné hledání těch základních bugů. A potom znovu, když se v programu něco změní. A pak znovu, když se udělá další úprava. A pak znovu… Zatímco test jednou napíšu a pak ho můžu spouštět v řádově kratším čase a řádově častěji než kdybych testoval ručně. Nedovedu si představit, kolik testerů by bylo potřeba, aby provedli komplexní testování systému za třeba 20 minut. A udělali to po každém commitu :-) Ta investice se nakonec opravdu vrátí!

      1. Honza

        Re: Testovanie

        Sorry, ale tady mluvíme o PHP. Jazyku na vytváření webových stránek. Když dělám webovou aplikaci, tak klienta zpravidla nejvíc zajímá, jestli se správně zobrazuje ve všech prohlížečích, a jestli to opravdu dělá to co má je obvykle až na druhém místě. Jak uděláš automatizované testy na to, jestli se stránky zobrazují ve všech prohlížečích správně? Jak vůbec nadefinuješ, co je správně?

        Neříkám, že to nejde, ale vložená námaha by mnohonásobně převážila to močkání F5, i kdybych ho měl dělat několikrát. Nebo snad existuje nějaký software na testování renderování stránek? Dozvíme se o něm v tomhle seriálu? To jsou věci, které mne na testování PHP aplikací zajímají – to co jsme se dozvěděli doteď je poměrně triviální a omezeně použitelné.

        Já osobně PHP aplikace automatizovaně netestuju a dosavadní části seriálu mne nepřesvědčily, abych začal. Podle toho, co jsme se zatím dozvěděli, se tenhle způsob testování hodí na serverové aplikace, které mají jasně definovaný vstup a výstup a dá se deterministicky verifikovat, jestli správnému vstupu odpovídá správný výstup. Optimální pro věci typu DBMS, různé mailservery a podobné „démony“. Pro software typu webových stránek (což je kolik procent věcí napsaných v PHP? že by 100?) naprosto nevhodné. Obecně asi pro cokoliv s UI.

        1. Martin Hassman

          Re: Testovanie

          Myslím, že většina mluví o PHP, jazyku na tvorbu webových aplikací 8-) Což je důvod, proč nerozumíte. Ono u webových aplikací je jedno, zda se přesně správně zobrazují ve všech prohlížečích (protože pokud ne, oprava bývá ve většině případů snadná), ovšem pokud je problém v chování aplikace, může to mít v tom horším případě neblahý dopad na osud celé softwarové dodávky.

          Renderování částečně testovat lze (služby které automaticky provedou screenshoty webu a ty pak porovnávají), ale to už nijak nespadá pod PHP a ani do tohodle seriálu (každopádně to ponechávám volbě autora).

          1. Honza

            Re: Testovanie

            Vtipné slovíčkaření. Když to máte tak jasně rozdělené, tak kde je podle vás ta hranice mezi „stránkami“ a „aplikací“? A dělal jste už opravdu nějakou aplikaci pro někoho za peníze, nebo to máte jen teoreticky?
            Pokud dělám eshop s tisícem funkcí nebo sebesofistiko­vanější intranetový systém na řízení procesů ve firmě, tak se klient stejně vždycky jako první ptá na to, zda se správně zobrazuje, ať už jsou to položky v nabídce eshopu pro zákazníky nebo cokoliv jiného k čemu stránky (aplikace) slouží.

            Ano, jsou věci, u kterých je v principu jedno, jestli se UI renderuje přes prohlížeč nebo přes nějaké jiné rozhraní nebo UI v běžné podobě vůbec nemají a které už rozhodně nejsou „stránkami“, ale řekněme třeba síťovým informačním systémem. To předpokládám spadá do vaší definice „aplikace“. Takové věci se pak určitě budou touto metodou testování testovat dobře. Ale jako sorry, ale něco takového přece nebudu psát v PHP. Pak mi bude strašně překážet volné typování a další skvělé featury, které se pro běžné webové stránky v PHP tak hodí.

            1. Petr P.

              Re: Testovanie

              Než začneš někoho obviňovat z amatérismu nebo z „pouze teoretické“ znalosti problematiky, tak si PROSÍM nejprve svůj výblitek aspoň třikrát přečti. Pokud totiž porovnáš tvůj příspěvěk a Martinův, na který jsi reagoval, tak je nad slunce jasné kdo tu jen machruje… Á propo – co kdybys nás potěšil nějakým opravdu odborným článkem, třeba na téma „Síťové informační systémy“ nebo „Výhody volného typování při vývoji běžných webovývh stránek“? Něco takového bych se opravdu rád přiučil, „volné typování“ bude asi nějaká revoluční novinka, protože PHP zatím patří jen mezi dynamic-type jazyky.

              1. Honza

                Re: Testovanie

                Nikoho jsem neobviňoval, pouze jsem se zeptal, zda už něco v praxi programoval, zvlášť v situaci, kdy přispěvatel není autorem původního článku, od kterého bych nějakou praxi tak nějak očekával. Ohledně české terminologie se celkem nemám chuť dohadovat, pokud není volné typování ten správný překlad „loosely typed language“, který používáte vy, tak sorry, ale předpokládám, že jste pochopil, co jsem tím myslel, takže to asi zas až takový problém nebude.

                Pokud příspěvek někoho urazil, tak se omlouvám (nevím, jestli je třeba Martin Hassman místní PHP guru a je urážkou zeptat se ho, jestli už něco programoval za peníze), každopádně nemusíte zacházet k osobním invektivám, jen jsem se snažil dopátrat konstruktivní diskuzí toho, proč je testování PHP aplikací popsaným způsobem rozumné. Možná ale předbíhám další části seriálu, takže si prostě jen počkám a uvidím. Zatím to má ale celkem sestupnou tendenci, tahle část byla (jak už někdo výše poznamenal) spíš něco jako copy-paste z příručky.

                1. Martin Hassman

                  Re: Testovanie

                  Na hodnocení trendu je zatím u seriálu brzy. Tenhle díl byl v seriálu poměrně logickým krokem. Příručky jsou také potřebné. Je vidět, že to některým čtenářům nevyhovuje – nevadí, autor to vezme v úvahu.

            2. Martin Hassman

              Re: Testovanie

              Pevná hranice mezi stránkou a aplikací není, v tomhle případě jde hlavně o pohled. Je pro vás v e-shopu „přidání do košíku“ nějakým barevným tlačítkem na stránce nebo funkcí v kódu, kterou lze volat a testovat nezávisle na GUI?

              Klient pochopitelně nejdřív reaguje na tu vizuální složku (protože tu na rozdíl od těch hlubších věcí vidí a také ji rozumí – nebo aspoň má ten pocit), ale zatímco vyřešit designerský problém bude zpravidla úkol jednoduchý až triviální a jeho náročnost jeho opravy neporoste s časem, tak oprava chyby v aplikaci se pohybuje na celé škále od triviální po „A neměli bychom to radši celé přepsat?“, „Jakou máme ve smlouvě pokutu?“, „Takže letenku na Bahamy a pryč?“ a navíc s jejím pozdějším odhalením můžou růst náklady a to výrazně.

              Srovnejte si vedle sebe problémy, na které se přišlo několik dní od předání a spuštění projektu:

              – ve vašem e-shopu kvůli nějakému problému s HTML/JS/CSS nešlo nakupovat v IE
              – váš e-shop špatně ukládal adresy zákazníků a nakoupené zboží jste rozesílali do opačných koutů republiky

              Z čeho hrozí větší malér? Co víc klienta naštve? Kde vzniknou větší náklady? Co bude snazší napravit?

              1. Honza

                Re: Testovanie

                Díky za odpověď. Máte pravdu ohledně testovatelnosti – přidání do košíku opravdu testovatelné je. A taky máte pravdu, že větší problém je posílat zboží na špatné adresy než špatné zobrazování v IE.
                Ale na druhou stranu testovatelné jsou rutiny typu „přidání do košíku“, které jsou tak triviální, že testování víceméně nepotřebují. Složitější akce v softwaru typu eshopu zase vyžadují netriviální vstup uživatele, takže se automatizovaně testují špatně. Chyby typu zasílání na špatné adresy jsou opravdu nepříjemné, ale obvykle vznikají tak, že je testy stejně neodhalí – například změnou sazby DPH z 10% na 14% (pokud vás možnost změny sazby DPH nenapadne při návrhu software, tak ji sebelepší test nevymyslí) nebo prostě chybným zadáním od zákazníka (aha, samozřejmě že jsme mysleli, že „adresa“ znamená „fakturační adresa“ a ne „zasílací adresa“, sice jsme to možná řekli obráceně, ale je přece jasné, že jinak to být nemůže, copak vy jste nikdy neprodával dětské oblečení, člověče?)

                Čili závěr – chápu, že to byl jen příklad a že v určitých konkrétních případech se testy mohou hodit, akorát těch případů v běžné praxi moc nevidím.

                1. Martin Hassman

                  Re: Testovanie

                  V tom případně se opravdu neshodneme už onom prvotním předpokladu ‚rutiny typu „přidání do košíku“, které jsou tak triviální, že testování víceméně nepotřebují‘ (vytvořit pro tenhle případ test bude triviální, během vývoje aplikace se může funkčnost takovéhle základní činnosti opakovaně rozbít => nízké náklady na testování => pravděpodobně se vyplatí).

                  Ani v tom, že „chyby typu špatné uložení adresy testy stejně neodhalí“ – právě v tomhle případě jsou testy poměrně silné (máme daný vstup/vstupy a můžeme snadno zkontrolovat, zda s nimi aplikace provedla to, co měla).

                  Můžete dát příklad nějaké té vaší „složitější akce v e-shopu“?

                  1. Honza

                    Re: Testovanie

                    Ok, beru argument, že na otestování triviální rutiny stačí triviální test. Je fakt, že tím, že nejsem zvyklý testy používat mi připadá obecně psaní jakéhokoliv testu jako komplikace a velký problém, je ale jasné, že kdybych si na to zvykl, tak napsání triviálního testu bude stejně snadné jako napsání triviální rutiny.
                    Složitější příklad z praxe mne teď nenapadá a vymýšlet nějaký virtuální asi není potřeba. Počkáme si na další díly seriálu, jestli se dozvíme jak vymýšlet situace, které je potřeba otestovat a jak vlastně ty testy psát.

              2. Honza

                Re: Testovanie

                A ještě k tomu „co bude snazší napravit“. Opravit design bude zpravidla podstatně pracnější.
                Jednak proto, že udělat design tak, aby fungoval ve všech prohlížečích od IE6 až pod nejnovější Chrome je prostě těžké – vyžaduje to opakované testování v různých prohlížečích, protože zejména starší verze IE se chovají opravdu nevyzpytatelně.
                A jednak proto, že pokud se posílá zboží špatně a je to způsobené chybou programování, kterou mohou odhalit testy, znamená to zpravidla nějakou triviální programátorskou chybu typu použití fakturační adresy místo dodací nebo něco podobného, což se zpravidla opraví snadno. Pokud je to opravdu závažná chyba, že se například vůbec nerozlišuje mezi adresou fakturační a dodací, tak to bývá už chyba návrhu nebo dokonce zadání, a tu vám stejně automatizované testy neodhalí, protože se píší právě podle toho návrhu.

                1. Clary

                  Re: Testovanie

                  Když už jsme u těch komerčních aplikací – třeba současná verze Ulož.to byla napsána TDD stylem.

                  Automatizované (unit) testy slouží zejména k odhalení jestli se něco změnilo – například kolega upraví objekt, který já někde používám. Místo aby se on hrabal v mém kódu, jednoduše spustí testy a dozvíme se, které části změna ovlivnila. Je změna objektu triviální programátorská chyba?

                  K tomu zobrazování – my třeba píšeme aplikaci, pro kterou se počítá jenom se zobrazováním v Chrome/Chromium – ostatní prohlížeče nás nezajímají. To – jestli reaguje/nereaguje JS nebo na stránce je/není prvek už testuje např. Selenium.

                  1. Honza

                    Re: Testovanie

                    Tak tohle je docela zajímavé. Takže vy nemáte domluvené nějaké jasně definované rozhraní, které se buď nemění nebo se při jeho změně příslušným způsobem upraví všechna místa použití, ale místo toho prostě jen upravíte objekt a pak pustíte testy jestli to poběží nebo ne? To mi nepřipadá úplně ok, ale vcelku vám do toho nebudu kecat.
                    Spíš je na tom zajímavé, že tedy musíte mít jistotu, že testy opravdu pokryjí úplně každou situaci, která může nastat. Je něco takového v reálu možné? Vy máte úplně jasně definované všechny stavy a případy použití, které může uživatel dosáhnout? A máte je pokryté testy? A jak si můžete být jistí, že máte opravdu všechny?

                    1. Martin Hassman

                      Re: Testovanie

                      Naopak, obecně bývá definované rozhraní a právě nad ním se spouští testy, které během vývoje ověřují, zda se po provedených změnách kódu rozhraní stále chová tak, jak má. (Pokud testy něco testují, tak to současně i nepřímo definují – už nějaká sepsaná specifikace existuje či nikoliv. Čili testy jdou dohromady k definovanému rozhraní a ne naopak.)

                      1. Clary

                        Re: Testovanie

                        Přesně tak. Navíc jak se aplikace rozšiřuje, může se měnit i rozhraní, které za několik měsíců/let vývoje nemusí odpovídat aktuálním požadavkům (závidím všem co si jednou ve fázi návrhu navrhnou rozhraní, které jim vydrží do ukončení vývoje)
                        To že testy testují triviální situace je pravda – protože program má být napsaný tak, že jeho malé bloky, testované právě unit testy mají být triviální.

                        1. Honza

                          Re: Testovanie

                          Aha, tak to potom jo. Přišlo mi, že jste psal „kolega upraví objekt, který já někde používám. Místo aby se on hrabal v mém kódu, jednoduše spustí testy“, tzn. místo aby se staral, kde je to použité a jestli tam není potřeba něco změnit, tak prostě jen pustí testy jestli to funguje nebo ne.

                          1. arron

                            Re: Testovanie

                            Ale přesně takhle to funguje a to je na tom mimojiné super :-D Když vím, že mám dobré pokrytí testy, tak někde něco upravím a spoštěním testů ověřím, jestli to někde něco nerozbilo. Nemusím se nikde v ničem ručně hrabat, selhané testy mi řeknou, co a kde je třeba opravit. Což je prostě boží :-)

                            1. Honza

                              Re: Testovanie

                              Nojo, ale spoléhat jen na automatizované testy, to mi připadá zase druhý extrém, než netestovat vůbec. Vy dokážete mít úplnou jistotu, že máte opravdu všechny způsoby použití toho objektu pokryté testy? Dokážete si být jistý, že vám testy odhalí úplně všechny možnosti chyb? To si neumím v reálu představit.

                              1. Josef ZamrzlaAutor příspěvku

                                Re: Testovanie

                                Honzo, obávám se, že Váš pohled na testování software je poněkud zcestný a pod pojmem „testováním“ máte většině Vámi popisovaných případů pouze akceptační testování. Tedy jakési
                                symbolické „proklikání“ produktu zákazníkem, zda „na první pohled dělá, co má“. Z Vašich vyjádření jsem poněkud zmaten a nedokážu odhadnout čemu se skutečně věnujete. Pokud je to
                                tvorba webových prezentací, tedy ve většině případů příprava šablon pro nějaký framework, pak chápu, že Vám toto téma je na míle vzdálené. V takovém případě Vám ani moc možností, kromě
                                funkčního a akceptačního testování, nezbývá. Funkčními testy si např. ověříte existenci klíčových elementů na stránce (očekávané nadpisy, očekávané odkazy, …), akceptačními
                                testy si ověříte vzhled. Případně ještě využijete nějaký generátor screenshotů abyste si ověřil vzhled ve Vámi podporovaných prohlížečích.

                                Jakmile ale vstoupíme na půdu webových aplikací, tedy projektů, které kromě prostého zobrazování víceméně statického obsahu obsahují i nějakou business logiku, tak už se pohybujeme
                                v prostředí naprosto jiné složitosti. Čím větší aplikace je, tím méně jsme schopni uhlídat všechny aspekty jejího chování. Takovou aplikací může být například Vámi zmiňovaný eshop.
                                Pokud nejde o „eshop“ na prodej CD na webu nějaké amatérské kapely, tak je třeba počítat s testováním na všech úrovních. Pomocí unit testů ověřujeme chování jednotlivých tříd v naprosté izolaci,
                                pomocí integračních testů pak jejich vzájemnou spolupráci, případně funkčnost celého modulu. Až na závěr pak nastupují funkční testy, které ověřují, zda výstup odpovídá očekáváním.
                                A co je nejdůležitější – tato sada testů nás chrání proti zavlečení nechtěné chyby. Mám na mysli třeba Vámi popisovaný příklad s „jasně definovaným rozhraním“. Neznám horší činnost, než
                                muset prohrabávat zdrojový kód (mnohdy psán někým jiným) a hledat, kde všude je to „jasně definované rozhraní“ použito. Vsadím se s Vámi, že vždy později narazíte na řadu zapomenutých míst.
                                Samozřejmě už pozdě. Refaktorovat kód, který je pokrytý testy je proti tomu hračka. Pokud kód pokrytý nemám, raději se do žádné větší změny ani nepouštím.

                                rutiny typu „přidání do košíku“ jsou tak triviální, že testování víceméně nepotřebují
                                Nevím na jakých eshopech jste pracoval, přidání produktu do košíku způsobí hned několik stavů v aplikaci (změna počtu produktů v košíku, změna počtu produktů ve skladu, …).

                                testy neodhalí změnu DPH
                                Vím, jaká je cena bez DPH a vím, jaká má být cena s DPH a toto testuji. Pokud vím, že má dojít ke změně DPH, tak očekávané hodnoty opravím na ty s novou DPH a po změně musí vše opět souhlasit.
                                Pokud ne, je výpočet ceny s DPH špatně.

                                Argument s adresami je úplně zcestný, dobrá sada testů ověří, zda po průchodu celým nákupem uložená data odpovídají předpokladu. Objednané položky odpovídají vloženým do košíku, zadané adresy
                                jsou shodné s uloženými atd. atp.

                                Ještě krátce k Vaší poslední reakci: Dokážete si být jistý, že vám testy odhalí úplně všechny možnosti chyb. Testy neslouží k tomu aby dokázaly absenci chyb, ale naopak – aby dokázaly jejich
                                přítomnost a pomáhaly jim čelit, a hlavně – zamezit jejich opětovnému zavlečení do již opraveného kódu.

                                1. Honza

                                  Re: Testovanie

                                  Díky za obsažný a zajímavý komentář. Určitě si počkám na zbytek seriálu a třeba postoj k automatizovanému testování změním.
                                  Každopádně moje stávající připomínky asi nejlíp vystihuje ten Vámi zmiňovaný příklad se změnou DPH – jak sám píšete, „pokud nevím, že má dojít ke změně, je výpočet špatně“. Tzn. testy pomohou najít jen chyby proti návrhu aplikace, ale chybnou funkčnost aplikace z důvodu špatného návrhu nebo špatného zadání nijak neodhalí. Spoléhat tedy jen na ně, jak navrhuje Clary a nestarat se o kód, jen o testy, mi připadá špatné.

                                  1. Josef ZamrzlaAutor příspěvku

                                    Re: Testovanie

                                    Obávám se, že mícháte dohromady naprosto neslučitelné pojmy. Tím, na co Vy narážíte, tedy jak otestovat fakt, zda aplikace pamatuje na možnost změny DPH, se zabývá tzv. statické testování, ale to už se pohybujeme na úrovni formálního návrhu aplikace. Statické testování nevyžaduje běh reálné aplikace a pomocí tzv. testovacích scénářů se ověřují právě Vámi uváděné možnosti.
                                    Tento seriál se zabývá dynamickým testováním, tedy testováním reálného kódu v konkrétním jazyce.

                2. Martin Hassman

                  Re: Testovanie

                  Nezapomeňte do nákladů na opravu onoho zasílání připočíst i veškeré poštovné za špatně odeslané zboží, komunikaci se zákazníky, ztrátu důvěry (a tím některých zákazníků) apod.

                  Jak je v porovnání s tím oprava nějaké chyby v designu, která by dobrému designerovi neměla dát problém? Dělat weby pro různé prohlížeče (IE6 u nových zakázek krom výjimečných případů dnes už můžeme vynechat) dnes už není těžké. Jejich chování je poměrně dobře zmapované, tipy a triky popsané, případně existují nástroje, které nás od některých odlišností odstíní. Pokud tohle dnes dělá designerovi problém, bude nejlepší mu doporučit nějaké školení (to nemá být urážka, ale dobrá rada).

                3. jos

                  Re: Testovanie

                  myslim že už bys měl radši mlčet a jít pleskat svoje webíky a hlavně si je dokola proklikávat, my ostatní necháme makat procesor a pudem na kafe

                  1. Honza

                    Re: Testovanie

                    No, zatím mne nic, co bylo řečeno, nepřesvědčilo, že by automatizované testování bylo právě na ty webíky tak úžasně vhodné. Malý webík radši dvakrát proklíkám, než strávit dva dny psaním testů. Počkáme si na zbytek seriálu.

                    1. arron

                      Re: Testovanie

                      „Malý webík“ ano. Ale pod tím já si představuju statický web o 4 stránkách a jednom kontaktním formuláři :-) Jakmile je web nasazený na nějakém systému typu CMS, tak tam už se vyplatí mít tento systém otestovaný. A to bez ohledu na to, jak velké weby se v něm dělají.

    1. Martin Hassman

      Re: Luxusni diskuze

      Autor ví, že se nemá nechat nějakými výstřelky odradit. Na tenhle seriál máme obecně dobré odezvy, takže v něm určitě vydržíme.

      1. omelkes

        Re: Luxusni diskuze

        Díky za dobrý seriál, já osobně jsem za něj rád.
        U tohoto článku by se mi líblo nějaké vizuální zdůraznění textů, které nejsou v oficiální dokumentaci, nebo zmíněných odlišností. MYslíte že by to šlo doplnit?

Napsat komentář

Tato diskuse je již příliš stará, pravděpodobně již vám nikdo neodpoví. Pokud se chcete na něco zeptat, použijte diskusní server Devel.cz

Zdroj: https://www.zdrojak.cz/?p=3706