Na navigaci | Klávesové zkratky

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 🙂

před 11 lety v rubrice Nette | blog píše David Grudl | nahoru

Mohlo by vás zajímat

Komentáře

  1. Honza Marek #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 11 lety | reagoval [2] David Grudl
  2. David Grudl #2

    avatar

    #1 Honza Marek, 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 11 lety | reagoval [4] Filip Procházka
  3. Filip Procházka #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.

    před 11 lety | reagoval [5] David Grudl [40] Tomáš Myšík
  4. Filip Procházka #4

    avatar

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

    před 11 lety
  5. David Grudl #5

    avatar

    #3 Filip Procházka, 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 #6

    avatar

    #5 David Grudl, 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
    #stary-odkaz-#stary-odkaz-https://dl.dropboxusercontent.com/u/32120652/Sn%C3%ADmek%20obrazovky%20po%C5%99%C3%ADzen%C3%BD%202014–03–07%2019%3A44%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
    #stary-odkaz-#stary-odkaz-https://dl.dropboxusercontent.com/u/32120652/Sn%C3%ADmek%20obrazovky%20po%C5%99%C3%ADzen%C3%BD%202014–03–07%2019%3A49%3A11.png

    Nebo to jde i když pustíš všechny testy a pak chceš ty co failují debugnout
    #stary-odkaz-#stary-odkaz-https://dl.dropboxusercontent.com/u/32120652/Sn%C3%ADmek%20obrazovky%20po%C5%99%C3%ADzen%C3%BD%202014–03–07%2019%3A46%3A48.png

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

    před 11 lety
  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 11 lety | reagoval [8] Honza [10] Honza T
  8. Honza #8

    avatar

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

    před 11 lety
  9. arron #9

    #5 David Grudl, 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 Jakub 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 11 lety | reagoval [12] Jakub Mh. [12] Jakub Mh.
  11. David Grudl #11

    avatar

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

    před 11 lety | reagoval [15] arron
  12. Jakub Mh. #12

    avatar

    #9 arron, #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 arron, také mám zájem o návod na úplně normální debugování testů

    #10 Honza T, 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 11 lety | reagoval [14] David Š. [17] arron
  14. David Š. #14

    avatar

    #13 David Š., 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 11 lety
  15. arron #15

    #12 Jakub 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 David Grudl, #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 11 lety
  16. arron #16

    #12 Jakub 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 11 lety | reagoval [17] arron
  17. arron #17

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

    před 11 lety
  18. Jakub Mh. #18

    avatar

    #12 Jakub 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 11 lety | reagoval [19] arron
  19. arron #19

    #18 Jakub 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 11 lety | reagoval [20] v6ak [21] Jakub Mh.
  20. v6ak #20

    avatar

    #19 arron, 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 11 lety | reagoval [22] arron
  21. Jakub Mh. #21

    avatar

    #19 arron, 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 11 lety | reagoval [24] arron
  22. arron #22

    #20 v6ak, 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 11 lety | reagoval [23] Jakub Mh. [25] arron
  23. Jakub Mh. #23

    avatar

    #22 arron, 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 11 lety
  24. arron #24

    #21 Jakub 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 11 lety
  25. arron #25

    #22 arron, Ok, beru :)

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

    před 11 lety
  26. Kamil #26

    avatar

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

    před 11 lety
  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 11 lety
  28. Daniel Milde #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 11 lety | 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 11 lety
  30. David Grudl #30

    avatar

    #28 Daniel 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 11 lety | reagoval [31] Daniel Milde [35] arron
  31. Daniel Milde #31

    avatar

    #30 David Grudl, 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 11 lety | reagoval [32] David Grudl
  32. David Grudl #32

    avatar

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

    před 11 lety | reagoval [33] Daniel Milde
  33. Daniel Milde #33

    avatar

    #32 David Grudl, 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 11 lety
  34. arron #34

    #28 Daniel 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 11 lety | reagoval [36] Daniel Milde
  35. arron #35

    #30 David Grudl, 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 11 lety
  36. Daniel Milde #36

    avatar

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

    před 11 lety | reagoval [38] arron
  37. Daniel Milde #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/step_debug

    před 11 lety
  38. arron #38

    #36 Daniel 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 11 lety | reagoval [39] Filip Procházka
  39. Filip Procházka #39

    avatar

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

    před 11 lety | reagoval [43] arron
  40. Tomáš Myšík #40

    avatar

    #3 Filip Procházka, >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 11 lety
  41. Tomáš Myšík #41

    avatar

    #5 David Grudl,

    A které IDE umí debugovat PHPUnit?

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

    před 11 lety | reagoval [42] Tomáš Myšík
  42. Tomáš Myšík #42

    avatar

    #41 Tomáš Myšík, 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 11 lety
  43. arron #43

    #39 Filip Procházka, 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 11 lety

Tento článek byl uzavřen. Už není možné k němu přidávat komentáře.


phpFashion © 2004, 2024 David Grudl | o blogu

Ukázky zdrojových kódů smíte používat s uvedením autora a URL tohoto webu bez dalších omezení.