Názory k článku Jednotkové testování v PHP: příjemné drobnosti
-
To tedy dost záleží na tom, jak máte nastavené acceptance criteria / procesy pro release (v závislosti na tom, jak si organizujete vývoj).
Součástí může být pravidlo všechny podobné konstrukce před mergem / releasem eliminovat. Podobně jako třeba TODO v kódu. Snižuje to množství různých čekání na něco při paralelním vývoji. Kontrolu ideálně automatizovat při buildu merge requestů, aby se na to nezapomnělo.
Samozřejmě, pokud nejste schopni zajistit spolehlivou kontrolu podobných konstrukcí, je lepší to na úrovni projektu zakázat. Ale byl bych opatrný s tvrzením "nikdy" :).
-
Neni jednodussi ta pravidla aplikovat na vysledny report? To preskakovani testu muze byt podminene, urcite testy vyzaduji urcite testovaci prostredi. Testy, ktere normalne funguji na CI serveru nemusi fungovat na lokale, ale neni duvod , aby kvuli tomu beh testu failoval, proste jen v reportu jsou preskocene testy.
-
@dirka12345
Zkusím reagovat postupně.Celá série článku popisuje základní možnosti PHPUnit. Myslím si, že k těmto základním možnostem patří i popisovaná metoda
markTestSkipped().Nikde nemluvím o produkci. Jednotkové testování probíhá obyčejně ve vývoji. BTW předpokládám, že jste z praxe, takže se zeptám, zda je ve firmě, ve které pracujete, zvykem, že "kód ve vývoji" = "okamžitě kód v produkci"?
Fakt nechapu proc akademik dava podobny moudra :/
Nevím, proč používáte tak ofenzivní styl psaní. Známe se? Udělal jsem Vám někdy něco?
Pavel Herout -
nil nil (neregistrovaný)
@Pavel Herout
Klidně vám jeden příklad z praxe půjčím. Máme v kódu několik Unit test metod, jihž feature byla dočasně pozastavena kvůli bugu. Testy jsou opraveny, protože byly použité k nalezení poblému a vyhodnocení závažnosti a co s tím ...
Takže testy jsou označeny jako přeskočit, ale rozhodně je nikdo nechce mazat a pak tahat kdoví odkud a ještě vlamovat do kódu, který už třeba divergoval kdoví kam - jsou "jen" skipped, takže při jakém koliv refactoringu se s nimi automaticky počítá.Jistě se to dá řešit i jinak, nicméně 3x "S" ve výstupu phpuinit nikoho nezabije.
18. 11. 2021, 13:48 editováno autorem komentáře
-
nil nil (neregistrovaný)
@dw
Ano, je. A to proto, že to už vyžaduje extra nastavení tam, kde kód testujete, takže třeba několik typů pipelines a různá vývojová prostředí různých členů teamu. Když test označíte Skipped, je to univerzální pro spuštění testů s jakýmikoliv prametry.
Různé group featury jsou IMHO pouze pro jednorázová spouštění testů při vývoji, abyste ušetřil čas ...
-
Takze v zavislosti na prostredi, zakomentuje CI v zdrojakoch testov volania skip? :D
Pokrocilejsi uzivatel dokaze CI prisposobit tak, aby na zaklade premennych prostredia vytvoril parametre pre spustenie tak ako je definovane.
Profik si tu extra funkcionalitu oddeli do balicku, ktory obsahuje vlastnu sadu testov a instaluje sa len tam kam ma.
Mate vo firme s ostatnymi vlastny gang alebo ste tam za exota?
-
nil nil (neregistrovaný)
@dw
Přizpůsobit CI dokáže i jednodušší uživatel. To není problém. Problém je, že si do CI zanesete různé nastavení kvůli požadavcím v kódu, takže vlastně problém kódu řešíte v CI.
Za druhé bude muset každý pořád sledovat co kdo dělá s nastavením CI testů, může to někdo měnit mezi tím než projde MR, takže na začátku vám může běžet MR na pipelinách jiných než na konci, aniž byste to vůbec věděl - to je ideální pro přehled nad projektem.... a to vše, protože chcete řešít v CI věci, které jsou záležitostí kódu, protože nechcete z nějakého důvodu použít metodu, která je k tomu přímo určená a dělá přesně to co má, ne skrtytě, jako změny v CI.
Až budete dělat s deseti lidma po netu a každý bude pořád něco měnit v CI, velice rychle z takového přístupu vystřízlivíte.
CI má být hranice, která se mění jenom při změnách požadavků na projekt, ne kvůli tomu, co kdo spáchá v kódu - a to právě proto, aby byl vývoj stabilní ... CI používáte právě proto, abyste automatizoval všechny operace nad kódem a projektem, ne jako doplněk kódu. CI má věci zautomatizovaně spustit, ne si pohrávat s kódem.
Přesně tímto přístupem se pak stane to, že někdo něco změní v DEV CI ale už to nezmění v jiné CI a problém může být na světě. Pokud to nastavíte v kódu a použijete metodu skipped, nic takového se vám nestane - ale to co píšu je o celkovém přístupu co dělá kdo a kde.
20. 11. 2021, 00:12 editováno autorem komentáře
-
>> Nikde nemluvím o produkci. Jednotkové testování probíhá obyčejně ve vývoji.
Nevim jak mam odpovedet na slovo "obycejne", vzdyt to je blbost z podstaty, unit testy se pousti proste pri kazde zmene/CI behu, tecka. Rozumne nastavena pipelina navic az po projiti unit testu pusti dalsi faze build procesu/hlubsich testu.
Ale fajn, pokud bylo mysleno, ze to vyvojar vubec neposle do repozitare, tak sem prestrelil.
Jinak zastavam jednoznacne nazor, ze jakykoliv zakomentovani testu nebo oznacovani, ze nemaji probehnout, je zcela spatne a ma se opravit duvod (proto jsou napr branche). Klidne nemusis souhlasit a hodne stesti, az se to cely sesype.
>> Nevím, proč používáte tak ofenzivní styl psaní. Známe se? Udělal jsem Vám někdy něco?
Asi je to muj styl, no.
18. 11. 2021, 21:03 editováno autorem komentáře
-
Jinak zastavam jednoznacne nazor, ze jakykoliv zakomentovani testu nebo oznacovani, ze nemaji probehnout, je zcela spatne a ma se opravit duvod
Treba takovy Hibernate ma 6500 unit testu z toho je jich okolo 1000 platformove zavislych. Tzn nespousti se pokud test nebezi oproti konkretni databazi. Podobne ma smysl preskakovat testy pokud test probiha na jine HW platforme(v jinem prostredi) nez pro kterou byl zamyslen.
-
Po očkování? Nebo proč jsi tak nabroušený? Je to funkce frameworku, byla zmíněna a i nějaký ten use-case by se našel. Nejsme PHPkář ale pytest má to samé. A ano, občas jsem to použil: https://docs.pytest.org/en/latest/how-to/skipping.html
-
V pytestu na to jsou označení ... markery... takže se to dá zapínat a vypínat podle potřeby. Každý framework má asi jiné mechanismy nebo se to dá naskriptovat a pouštět testy jen z určitého adresáře. Prostě co jazyk/framwork poskytuje. Jako byl bych také s tím _skip_ opatrný ale napsat to takto agresivně a nekompromisně jako předřečník, no nevím :).
19. 11. 2021, 18:43 editováno autorem komentáře
-
nil nil (neregistrovaný)
Produkce
Jo, to je taková mantra pro ... nevidomé ... na produkci patří to, co je stabilní, testované a předvídatelné, to co bylo naplánováno a na čem se team shodl. Váš kód může fungovat správně i bez Unit testů, třeba dočasně skipped, prootože Unit testy nejsou to jedinné co děláte, pokud se chcete bavit o nějakém smysluplném testování.
A propos, dělat hovadiny se nevyplácí ani při vývoji, protože se občas může stát, že se nějaká blbost do té produkce dostane. Ve vývojové fázi se má vyvíjet, ne dělat blbosti.
ČLÁNKY DO MAILU