Na navigaci | Klávesové zkratky

Translate to English… Ins Deutsche übersetzen…

Proč používám Nette Tester

„Přesvědč mě, proč bych měl používat Nette Tester, v čem je lepší než PHPUnit?“ Tyhle otázky mě vždycky trošku uvádějí do rozpaků, neboť nemám potřebu nikoho přesvědčovat, aby Tester používal. Sám bych se bez něj ale neobešel.

Samotné testování je poněkud zakletá věc. Pět let se na všech konferencích stále dokola mluví o testování a přitom skoro v žádné firmě se kód „netestuje“. Píšu to v uvozovkách, protože ve skutečnosti všichni programátoři dnes a denně testují, co ale nedělají je, že nepíšou testy v PHPUnit, z mnoha důvodů. Pravda je, že sám jsem v oné krátké době, kdy byl Nette Framework testován PHPUnitem, také ztratil chuť testovat. Přičemž testování je pro vývoj frameworku natolik zásadní prvek, jako třeba verzovací systém.

Ale popořadě. Proč všichni programátoři testují, i když „netestují“?

Představte si, že naprogramujete funkci foobar()

function foobar($x, $y) {
    // tady se počítají nějaké věci
    return $val;
}

První věc, kterou každý programátor udělá, je, že vyzkouší, jestli to funguje:

echo foobar(10, 20);

Spustí to, vypíše to 30, což je správně, vypadá to, že to funguje a třeba ještě vyzkouší pár jiných vstupů.

Jinými slovy funkci otestuje. Tedy testuje!

Potom následně udělá to, že testovací skript smaže. A to je právě průšvih! Všechny ty argumenty vývojářů, že na testování nemají čas, v tento moment padají, protože realita je taková, že na testování čas je, dokonce jsou napsané i testy, jenže pak je programátoři smažou. Ironie.

Testem není pouze třída v PHPUnit, testem je i tento jednořádkový skript. Přesněji řečeno, test musí obsahovat ještě informaci, jaká je správná návratová hodnota, takže by vypadal takto:

assert( foobar(10, 20) === 30 );
assert( foobar(-1, 5) === 4 );
...

Až někdy v budoucnu upravím implementaci funkce foobar, nebo do ní sáhne kolega, stačí tento skript spustit, a pokud vyhodí warning, hned vím, že je funkce rozbitá.

A to je vše. Tohle je testování. Tak je to jednoduché. Děláme to všichni, bohužel hodně z vás si ty testy pak maže.


Časem se nám nahromadí obrovská spousta takovýchto testovacích skriptíků a vznikne otázka, jak je spouštět hromadně. Dá se to řešit nějakým shell skriptem, já jsem si na to napsal PHP skript. Jeho podstatnou výhodou je, že umí testy pouštět paralelně (běžně spouštím 40 vláken), což otestování celé sady dramaticky zrychlí. A taky přehledně vypisuje, ve kterém souboru kde přesně došlo k selhání.

Také místo PHP funkce assert jsem si napsal vlastní funkce (třída Assert), které se liší především v tom, že při selhání hezky a čitelně vypíšou, co funkce měla vrátit a co místo toho vrátila, abych rychle věděl, kde je problém.

A ten spouštěč, třída Assert a ještě dalších pár věcí tvoří zmíněný Nette Tester. Čtyři roky spolehlivě testuje Nette Framework.


Když mi někdo nahlásí, že ve funkci foobar je chyba, že pro vstupy 0 a -1 vrací prázdný řetězec místo čísla -1, tak začnu tím, že to nejprve ověřím:

Assert::same( -1, foobar(0, -1) );

Spustím to a skutečně, vypíše se:

Failed: '' should be -1

Tedy jsem napsal failující test. Neudělal jsem to proto, že v příručkách o testování se píše, že test musí nejdřív failovat, nebo proto, že bych se řídil TDD, dělám to proto, že mě nenapadá, co jiného by se dalo dělat, než prostě napsat krátký kód, který bugreport ověří, tedy failující test.

Chyba tam vážně je a je třeba ji opravit. V IDE začnu kód krokovat a hledám místo, kde je zakopaný pes. (O programátorech, kteří píší kód v poznámkovém bloku, ať už se jmenuje TextMate nebo Sublime, namísto plnohodnotného IDE, a nemohou proto kód krokovat, napíšu článek někdy příště.) Ano, kde je chyba bych asi zjistil i bez krokování, zíráním do kódu a umisťováním var_dump, echo nebo console.log, ale trvalo by to mnohem déle. Chci zdůraznit, že krokování a testování nejsou alternativy, ale zcela odlišné činnosti, které je fajn používat dohromady.

Odhalím a opravím chybu, Assert::same je spokojený a do repozitáře komitnu nejen opravu funkce foobar, ale také onen soubor s testem. Díky tomu se tahle chyba už nikdy v budoucnu nevyskytne. A věřte mi, že chyby mají tendenci se opakovat, dokonce pro tento jev existuje název: regrese.


Tohle povídání vám asi muselo připadat strašně samozřejmé. A to je dobře, ono je samozřejmé a já chci bourat předsudky a obavy z testování. Ale stále jsem neodpověděl na úvodní otázku: proč nepoužívám PHPUnit? Protože s ním takto přímočaře pracovat neumím.

Abych mohl otestovat foobar, musel bych napsat celou třídu, která dědí od jiné třídy, jejíž jméno si nejsem schopen zapamatovat. No budiž, použiji šablonu. PHPUnit neumí testy spouštět paralelně, takže otestování celé sady trvá násobně déle. V případě Nette Frameworku jde o 35 sekund versus 2 minuty, což už saje. Ale především, testy psané v PHPUnitu lze spouštět jen v PHPUnitu, nejde o samostatně spustitelné skripty. Takže není způsob, jak napsat failující test a potom ho úplně snadno krokovat a hledat výše uvedeným způsobem chybu.

Nejjednodušší řešení proto bylo napsat si vlastní triviální testovací udělátko. Za ty čtyři roky velmi pozvolna vyspěl v plnohodnotný nástroj, už ho nevyvíjím sám a díky klukům z Oracle má dnes integrovanou podporu v NetBeans 8.0. Jelikož generuje výstup ve formátu TAP, neměl by být problém ani s integrací do jiných nástrojů.

Nebudu vás přesvědčovat, abyste používali Nette Tester, ale rád bych vás přesvědčil, abyste si testy, které píšete, nemazali :-)

Komentáře

  1. Honza Marek http://www.janmarek.net #1

    avatar

    Já si zase nedovedu představit, že bych psal testy bez těch test case tříd. Na názvech těch metod je aspoň pěkně vidět, co vlastně ta třída má umět.

    PHPUnit mi z hlediska použití nikdy v ničem nevadil. Neumim napsat stořádkovou metodu, takže mám sníženou potřebu krokování.

    To krokování bude předpokládám pravý a jediný důvod, proč jsi se pustil do vývoje vlastního nástroje. Občas přemejšlim o vyzkoušení Nettetesteru kvůli tomu paralelnímu spouštění, ale zatim mě to tak netrápí.

    před 3 lety | odpovědět | reagoval [2] David Grudl
  2. David Grudl http://davidgrudl.com #2

    avatar

    #1 Honzo Marku, TestCase třídy mají v mnoha případech smysl, proto jsou i součástí Nette Testeru. Jen je není nutné používat.

    Krokování kódu nemá s délkou metod naprosto nic společného. To je prostě jiný vhled do programu. Pod krokováním myslím i break pointy, sledování obsahu proměnných, prostě řádově komfortnější proces, než je dumpování na výstup. Btw, kolikrát je zajímavé si prokrokovat odladěný program, protože teprve při krokování ti dojde spousta věcí, které by se daly vylepšit.

    Ale jinak ano, nemožnost ladit testy (ať již krokováním nebo metodou dump'n'refresh) byl hlavní důvod, proč jsem opustil PHPUnit.

    před 3 lety | odpovědět | reagoval [4] Filip Procházka
  3. Filip Procházka http://filip-prochazka.com/ #3

    avatar

    Je potřeba také zmínit, že i Nette Tester podporuje TestCase třídy a na rozdíl od PHPUnitu má tato třída pouhých 170 řádků, kdežto v PHPUnitu se skládá z několika desítek souborů.

    Dvě největší výhody Testeru jsou paralelnost a jednoduchost testů.

    Na druhou stranu je potřeba také zmínit, že IDE podporují debugování jednotlivých metod i v PHPUnitu. Podpora je tak dobrá, že ve složce s testy si kliknu pravým na název testovací metody a dám run nebo debug a pustí se jenom bootstrap + tato metoda. Zajímalo by mě, jestli tohle implementovali kluci z Netbeans i pro Tester.

  4. Filip Procházka http://filip-prochazka.com/ #4

    avatar

    #2 Davide Grudle, „debugovat nepotřebuju“ je argument každého správného Sublime/TextMate hipstera :)

    před 3 lety | odpovědět
  5. David Grudl #5

    avatar

    #3 Filipe Procházko, vtip je v tom, že tohle implementovat nemusíš, to prostě jde z principu, že test je spustitelný soubor.

    A které IDE umí debugovat PHPUnit? Hodilo by se mi to, když komituju do jiných projektů.

  6. Filip Procházka http://filip-prochazka.com/ #6

    avatar

    #5 Davide Grudle, Na 100% to umí PhpStorm, označíš složku v projektu jako že obsahuje testy „project files > pravý na složku > Mark directory as > Test sources root“. Potom si otevřeš test, dáš pravým na tu metodu a máš tam v nabídce debug
    https://dl.dropboxusercontent.com/…A44%3A49.png
    Kdyby to tam chybělo, tak proto, že PhpStorm nenašel phpko v systému nebo to pouští se špatným configem, což se dá snadno fixnout
    https://dl.dropboxusercontent.com/…A49%3A11.png

    Nebo to jde i když pustíš všechny testy a pak chceš ty co failují debugnout
    https://dl.dropboxusercontent.com/…A46%3A48.png

    Do Netbeans jsem to reportovat, ale nesleduju jestli už to implementovali.

    před 3 lety | odpovědět
  7. Jakub Mh. #7

    avatar

    Nette Tester je obrovsky užitečný nástroj a obdivuji lidi, kteří si jeho potřebu uvědomili a dotáhli ho do použitelného stavu.

    Nám starým kořenům to moc neříká, máme svoje více či méně obhajitelné zvyky a žijeme si svůj programátorský život nějakou tu dekádu. Víte, ale existuje i druhá strana mince.

    Dělám v jedné firmě, mám pod sebou tým pilných programátorů a snažím se je během práce i něco nového naučit a posunout je dál.

    Testování byl vždy problém. Psát phpunit testy není tak triviální, práce to je otravná, zanáší to příliš problémů a lidi, kteří programují rok, dva s tím prostě bojují ač si řikáte co chcete. Test napsaný z donucení či z povinnosti je odfláknutý, krátký a člověk cítí, že i s testy to není ono. Nemluvě o „složitosti“ používání phpunitu.

    Zkoušeli jsme různé alternativy, před několika měsíci jsem ale udělal několik ukázet nad nette Testerem, trochu jsem je v tom zaškolil, ukázal jsme jim jak mají v práci postupovat. A co to nevidím po několika měsících, hoši prostě třídy rovnou „dumpují“ v testech a jsou strašně nadšení a spokojení. V prohlížeči si to mohou f5tkovat, mají k tomu fešnou laděnkou a nedokážou si představit, že by pracovali jinak.

    Nic proti pánové, tohle jsem nikdy s phpunitem neviděl. Děkuji za tak výtečný nástroj.

    před 3 lety | odpovědět | reagoval [8] Honza [10] Honza T
  8. Honza http://blog.fineboard.cz #8

    avatar

    #7 Jakube Mh., Díký, převědčil jsi mě!

    před 3 lety | odpovědět
  9. arron #9

    #5 Davide Grudle, PHPUnit testy se dají uplně normálně debugovat jako každý jiný skript :-) Pravda je, že to není tak uplně přímočaré (obzvlášť, pokud je spouštím z konzole na remote serveru), ale funguje to v jakémkoliv IDE, které podporuje krokování pomocí xDebugu :-) Pokud by byl zájem, mohu předvést :-)

  10. Honza T #10

    #7 Jakube Mh.,

    Nic proti pánové, tohle jsem nikdy s phpunitem neviděl.

    Petr Procházka kdysi napsal pro potřeby svoje i Clevisu nástroj https://github.com/…/HttpPHPUnit. Je to webový runner pro PHPUnit, takže funguje laděnka, krokování s libovolným IDE a proklik do editoru. V mnoha ohledech je to lepší, než co nabízí Nette\Tester v současnosti, ale úvodní zprovoznění je zprovoznění toho nástroje je porod.

    před 3 lety | odpovědět | reagoval [12] Jakub Mh. [12] Jakub Mh.
  11. David Grudl http://davidgrudl.com #11

    avatar

    #9 arrone, no jasně, že je zájem. Jak na to?

    před 3 lety | odpovědět | reagoval [15] arron
  12. Jakub Mh. #12

    avatar

    #9 arrone, #10 Honza T skutečnost, že k tomu potřebuji návod, mi jasně řiká, že to je prostě složitější než to jen spustit.

    #9 arrone, také mám zájem o návod na úplně normální debugování testů

    #10 Honzo Te, ne ne, neviděl jsem, že by lidé psali testy s nadšením a brali to jako samozřejmost aniž bych jim musel na tabuli psát „5 důvodů“ proč testovat. V případě, že je v týmu jeden schopný programátor, tohle vše vždy ostatním nastaví a nemusí se to řešit, ale vždy to bude tvořit určitou bariéru.

    Nette tester je nástroj ty, kteří chtějí mít čas se jít po práci projít do parku :-). Nemyslím si, že má za cíl přetáhnout lidi, kteří si rochní v phpunitu, funkčně se s ním srovnávat nemůže, ale je to úžasná vstupní brána pro ty, kteří zatím moc netestují.

  13. David Š. #13

    avatar

    Bylo by fajn taky rozvést _co_ testovat. Testovat presentery? Testovat obsluhu formulářů? Modely nebo nějakou mezivrstvu? A jak?

    Když jsem chtěl s testy začít, narazil jsem na to, že kód obsahuje minimum složitých a záludných funkcí (na kterých se psaní testů vždycky tak krásně prezentuje). Naopak jde často o funkce pracující s databází (kde bych musel řešit její reset do nějakého výchozího stavu a asi by se těžko testovalo paralelně) anebo o nějakou logiku uvnitř presenteru (tam zase musím bojovat s bootstrapem a obecně s nastavením prostředí).

    A teď ať mi někdo říká, že testy (Nette aplikace) jsou hračka :-)

    před 3 lety | odpovědět | reagoval [14] David Š. [17] arron
  14. David Š. #14

    avatar

    #13 Davide Š., jen se doplním – v prvním odstavci jsem měl na mysli záludné funkce bez dalších vnějších závislostí, jako právě db atp.

    před 3 lety | odpovědět
  15. arron #15

    #12 Jakube Mh., Ve skutečnosti to není o tolik těžší, jde jenom o to, že musíš donutit xDebug, aby se Ti připojil k IDE. Což je opravdu složitější, než „prostě spustit testy“, ale když si na to napíšeš skript, tak pak už je to přesně tak jednoduchý :-)

    #11 Davide Grudle, #12 Jakub Mh. Primárně jsem chtěl, abych byl schopný debugovat cokoliv, co pustím z konzole na remote serveru. To že to funguje i na testy v PHPUnitu je defacto vedlejší efekt ;-)
    Je potřeba použít pro spuštění tenhle https://github.com/…r/TestIt/bin skript :-)
    Například (PhpStorm):
    ./debugphpscript -id PhpStorm -s myserver.local -ip 192.168.1.1 -c „my_script.php -f someConfiguration“
    Ale nechci tady duplikovat dokumentaci http://www.testitphp.com/#… :-)

    před 3 lety | odpovědět
  16. arron #16

    #12 Jakube Mh., Psát testy vlastně fakt je docela hračka, když je kód dobře napsaný (čili minimálně využívá DI). Ale stejně jako jakýkoliv skill, nějakou dobu to trvá, než si tu techniku osvojíš a než pochopíš jak ty testy spsát správně. Mě to trvalo zhruba rok :-) No a pak už jenom najít ty správné nástroje a ty testy se vlastně píšou skoro samy ;-)

    před 3 lety | odpovědět | reagoval [17] arron
  17. arron #17

    #16 arrone, Ups, předchozí komentář reaguje na #13 David Š.

    před 3 lety | odpovědět
  18. Jakub Mh. #18

    avatar

    #12 Jakube Mh., u nás testujeme všechno, co se dá spustit a kde se mohou vyskytnout chyby. O testování presenterů tady před rokem byl článek.

    Každý test může buď využít celý systémový container se všemi službami a zavolat si co chce a otestovat to.

    Jednotlivé testy, ale mohou mít vlastní systémový container, což je častější. Prostě k testu přidám krátký neon soubor pouze se službami, které k testu potřebuji.

    S databází je to složitější. Programátor má možnost si nechat pro test vytvořit vlastní naplněnou databázi, ale trvá to relativně dlouho. Častěji prostě test uzavřeme do transakce, kterou na konci testu rollbackneme, pro většinu testů a formulářů to bohatě dostačuje.

    před 3 lety | odpovědět | reagoval [19] arron
  19. arron #19

    #18 Jakube Mh., Osobně tedy databázi testuji tak, že si udělám mock připojení a pak řeším, jestli se zavolaly správné příkazy/dotazy se správnými daty ve správném pořadí. Jinak se totiž nejedná o unit test ;-)

    před 3 lety | odpovědět | reagoval [20] v6ak [21] Jakub Mh.
  20. v6ak https://v6ak.com #20

    avatar

    #19 arrone, Ale testování nejsou jenom unit testy, jsou to i různé další druhy testů. Zrovna u dotazů do DB mi není úplně jasné, jakou hodnotu má takovýto test. On vlastně testuje, jestli umím dobře poskládat string dotazu do DB, případně mu předat správné parametry. Vlbec mi to ale neříká, jestli ten dotaz/příkaz dělá to, co chci, jestli využívá aktuální strukturu databáze a dokonce ani jestli v něm není nějaká syntaktická chyba.

    Ve výsledku mi takovýto test DB dotazů proti mocku často řekne mnohem méně než statická typová kontrola. Ta sice logickou správnost neověří, ale můžu si být jist, že dotaz bude používat aktuální strukturu databáze a nebude v něm třeba hloupý překlep.

    A pokud mám nějakou větší logiku, ze které třeba vyplyne více dotazů, tak bych stejně spíš mockoval vrstvu nad SQL.

    před 3 lety | odpovědět | reagoval [22] arron
  21. Jakub Mh. #21

    avatar

    #19 arrone, Jasně a v modelech si píšeš přímo sql dotazy jinak totiž netestuješ jenom danou třídu, ale i databázovou vrstvu a takový upgrade databázové vrstvy, ve které se třeba začne jinak zacházet s bílými znaky, ti rozbije tvoje unit testy, není to pořád paradoxní? :) Nebo chceš říct, že mezi modely a databázovou vrstvou máš svoje rozhraní?

    Co si budeme povídat, svět php je prostě zvrácený. Komunita a nástroje vyrostly kvůli jejich potřebě a ne akademické čistotě. A je to špatně?

    Do php světa jsem přešel z pozice C# vývojáře. Dělal jsem na interních systémech s dvouletým plánováním. Běžně mezi námi lítaly termíny jako 100 % coverage, AT, UT, FAT, SIT, UAT. Jsem rád, že se to do php ještě tolik nedostalo, dává mi to pocit volnosti.

    Ne, nepíšeme unit testy, my píšeme jenom testy. Programátoři mají dobrý pocit z práce, opora v podobě testů jim dává volnost v programování a klienti jsou spokojení, za relativně nízké náklady dostávají produkt s malým procentem chyb. Samozřejmě si mohou zaplatit lepší výstupní kontrolu a kvalitnější produkt, ale ten produkt nebude u zákazníků úspěšnější nebo oblíbenější.

    V php se dělá zejména webový vývoj v poměrně rychlých obrátkách za nízké ceny s tolerovanou chybovostí. O takový produkt je na trhu zájem a snad všichni tady takový produkt pro svoje klienty děláme. Systémové inženýrství je úžasný obor, ale zatím mi ve světě php pro něj chybí v rozpočtu patřičná kolonka.

    Nechci se přít ohledně unit testů, ale nette Tester mi jako nástroj splňuje požadavky, které od něho očekávám. Posouvá produkt na mnohem vyšší úroveň bez zvýšených nákladů na vývoj. Schopnější programátoři za pár let zkušeností samozřejmě začnou opravdu třeba unit testovat a psát podle toho aplikace, ale během té doby vytvoří mnoho třeba velice zajímavých produktů a nemusí strávit měsíce v knížkách, pro někoho to je lepší volba.

    Mně se cesta, kterou jde php líbí a vyhovuje mi.

    před 3 lety | odpovědět | reagoval [24] arron
  22. arron #22

    #20 v6aku, Ale bavíme se tu to unit testech nebo ne? To co popsal Jakub Mh. tak je IMHO integrační test. A já neříkám vlastně nic jiného ;-)

    Ten unit test Ti ale ani nic jiného říct nemůže, pokud má být unit testem. Ale není to tak, že když pošlu do databáze správné příkazy/dotazy, ve správném pořadí, se správnými daty, tak dostanu správný výsledek? Čímž neříkám, že je to jediný možný/nutný test, ale jako unit test je to naprosto v pořádku ne?

    před 3 lety | odpovědět | reagoval [23] Jakub Mh. [25] arron
  23. Jakub Mh. #23

    avatar

    #22 arrone, o nit testech nepadlo v celém článku a ani slovo :)

    A kdo ti zaručí, že dotazy jsou v pořádku, že databáze po jejich zavolání má správný stav? Další sada testů nebo ruční kontrola? Není to jenom poloviční řešení?

    před 3 lety | odpovědět
  24. arron #24

    #21 Jakube Mh., Pokud to bereš tak, že píšete testy a nikoliv unit testy, tak pak je to naprosto v pořádku, můk komentář se týkal unit testů ;-)

    Používám Doctrine 2 a přiznám se, že mezi ní a mojí aplikací mám ještě jednu vrstvu. Ale v podstatě jenom proto, abych byl schopný rychle fixovat případné BC v Doctrine a nebyl na ní tak moc závislý.

    Ostatní je asi trochu offtopic, takže jenom tolik…možná to, že v PHP se málo používají pojmy jako UAT je jeden z důvodů, proč se na PHP nahlíží tak, jak se na něj nahlíží :-)

    před 3 lety | odpovědět
  25. arron #25

    #22 arrone, Ok, beru :)

    Samotné unit testy jsou vždycky jenom poloviční řešení :)

    před 3 lety | odpovědět
  26. Kamil http://maraz.co #26

    avatar

    Krokovanie a XDebug v Sublime je to najmenej… bežne používam…

    před 3 lety | odpovědět
  27. takyhonza #27

    Rád bych se taky podělil o svou zkušenost. Když jsem před lety začal programovat, tak jsem testování moc neřešil, ostatně asi jako většina začátečníků. Čím déle jsem ale programoval, tím víc jsem cítil, že neustálé dumpování proměnných není dále schůdná cesta a že fakt musím začít psát testy.

    Věděl jsem, že na testování v PHP se používá PHPUnit, vygooglil jsem si seriál, jak začít s PHPUnitem, nakonec se mi ho podařilo nainstalovat, otevřu další kapitolu, pročtu se až k „hello-world“ ukázce a vidím tu šílenou TestCase třídu, čtu z čeho jak musím dědit atd. a říkám si „TAK TOHLE KURVA ANI OMYLEM, to fakt musím pro každý test psát něco takového?! Vždyť to snad ani nejde napsat z paměti!“ Seriál jsem zavřel a další 2 roky testování neřešil…

    A pak jsem narazil na Nette fóru na nějaké zmínky a ve zdrojáku Nette ho našel – Tester! Koukám na testy v Nette a říkám si „Ty voe, to je ono! Na tohle už 2 roky čekám, proč to sakra někoho nenapadlo dřív!“ Vytáhl jsem si zdrojáky Testeru a začal si s ním hrát, psát první testy. V testování jsem pořád ještě zelenáč, neřeším unit-testy, integrační testy, prostě píšu testy, tak, jak cítím, že bych je měl psát. Díky Testeru to není otrava, mám lepší pocit z toho, že mi záda kryje otestovaný kód a už jsem se i dostal do stavu, že když nenapíšu ke kódu testy, mám divný pocit a tomu kódu vůbec nedůvěřuji, i kdyby to měla být jen funkce na sečtení dvou čísel… Takže, za Tester díky!

    před 3 lety | odpovědět
  28. Daniel Milde http://blog.milde.cz #28

    avatar

    Krokovat PHPUnit testy jde a je to velmi snadné. Stačí nastavit v php.ini xdebug.remote_autostart = 1, spustit debuggování v IDE (ano, i v Sublime, který je imho nejlepší PHP IDE vůbec) a pak spustit jakýkoliv PHP skript, nebo otevřít libovolnou stránku.
    Xdebug se podívá, jestli něco neposlouchá na portu 9000 a pokud ano, tak se začne debuggovat.

    před 3 lety | odpovědět | reagoval [30] David Grudl [34] arron
  29. Marek #29

    avatar

    Davide, ty to rok od roku píšeš čtivěji;) mám z toho radost…

    před 3 lety | odpovědět
  30. David Grudl http://davidgrudl.com #30

    avatar

    #28 Danieli Milde, to spíš popisuješ, jak spustit krokování v editoru, stále mi tam chybí ten PHPUnit. Test je třída. Jak ji zavolat konkrétní metodu?

    ad Sublime: je to jeden z mých nejoblíbenějších editorů a pomocí doplňků se z něj dá udělat takřka plnohodnotné IDE. Nechtěl jsem se navážet do Sublime, mířil jsem na programátory, kteří ladí metodou dump'n'refresh, tedy ať už používají jakýkoliv editor, není v jejich užití víc než poznámkový blok.

    před 3 lety | odpovědět | reagoval [31] Daniel Milde [35] arron
  31. Daniel Milde http://blog.milde.cz #31

    avatar

    #30 Davide Grudle, Asi nerozumím jak to myslíš. Spustím si v Sublime krokování, dám si breakpoint někam do metody toho testu a pustím v konzoli phpunit (třeba jen pro tu jednu třídu).

    před 3 lety | odpovědět | reagoval [32] David Grudl
  32. David Grudl http://davidgrudl.com #32

    avatar

    #31 Danieli Milde, aha, takže xdebug si asi spustí server a pak tím komunikuje s pluginem v Sublime.

    před 3 lety | odpovědět | reagoval [33] Daniel Milde
  33. Daniel Milde http://blog.milde.cz #33

    avatar

    #32 Davide Grudle, Je to myslím přesně naopak. Server (127.0.0.1:9000) spouští IDE a Xdebug se k němu zkusí připojit.

    před 3 lety | odpovědět
  34. arron #34

    #28 Danieli Milde, Problém je v tom, že když se spouští testy z konzole a běží na jiném stroji, než kde běží IDE, tak xDebug netuší, kam se má snažit připojit…PhpStorm by tohle měl nějak umět (spouštět unittesty na remote server;někam di adresářové struktury si nahrává vlastní skript a pak ty testy spouští přes prohlížeč či co), ale nikdy se mi to nepodařilo nakonfigurovat, abych s tím byl spokojený a bylo to jednodušší než testy spouštět z konzole.

    před 3 lety | odpovědět | reagoval [36] Daniel Milde
  35. arron #35

    #30 Davide Grudle, dá se použít přepínač –filter, ale v tomhle případě bude prostě spuštění php souboru s jedním testem vždycky pohodlnější, o tom žádná :)

    před 3 lety | odpovědět
  36. Daniel Milde http://blog.milde.cz #36

    avatar

    #34 arrone, Kam se má xdebug připojit se nastavuje pomocí xdebug.remote_host.

    před 3 lety | odpovědět | reagoval [38] arron
  37. Daniel Milde http://blog.milde.cz #37

    avatar

    Na webu Xdebugu je to krásně ukázané dokonce včetně animace (je to asi až v půlce stránky)
    http://xdebug.org/docs/remote

    před 3 lety | odpovědět
  38. arron #38

    #36 Danieli Milde, Ano, to je pravda, ale jak nastavit xdebug.remote_host, pokud jednou sedím u desktopu a jednou jsem připojený přes VPN z notebooku? Přenastavovat je to samozřejmě nesmysl, ne?

    před 3 lety | odpovědět | reagoval [39] Filip Procházka
  39. Filip Procházka http://filip-prochazka.com/ #39

    avatar

    #38 arrone, http://www.php.net/….options.php CTRL+F v browseru a napiš „-d“

    před 3 lety | odpovědět | reagoval [43] arron
  40. Tomáš Myšík #40

    avatar

    #3 Filipe Procházko, >Zajímalo by mě, jestli tohle implementovali kluci z Netbeans i pro Tester.

    Oni by rádi, ale nefungovalo jim to :)

    https://github.com/…er/issues/39#…

    před 3 lety | odpovědět
  41. Tomáš Myšík #41

    avatar

    #5 Davide Grudle,

    A které IDE umí debugovat PHPUnit?

    Tohle v NetBeans funguje automaticky, stačí jen otevřít test file a dát Debug file.

    před 3 lety | odpovědět | reagoval [42] Tomáš Myšík
  42. Tomáš Myšík #42

    avatar

    #41 Tomáši Myšíku, Jen teda upřesním – Xdebug musí být nastaven; pokud není, NetBeans vyhodí okénko s požadovanou konfigurací a odkazem do wiki.

    před 3 lety | odpovědět
  43. arron #43

    #39 Filipe Procházko, Kdyby ses podíval do toho skriptu, co jsme posílal, tak to je přesně to, co dělám. Plus se tam startuje xDebug session (aby nemuselo být nastaveno autostart a dal se nastavit správný idekey) a je tam možnost specifikovat jméno serveru, aby PhpStorm znal mapování souborů ;)

    před 3 lety | odpovědět

Zanechat komentář

Text komentáře
Kontakt

(kvůli gravataru)



*kurzíva* **tučné** "odkaz":http://example.com /--php phpkod(); \--