Vlákno názorů k článku Cibulová architektura aneb jak nepřipravovat špagety od wajtr - Budeme-li brát v úvahu i "Vícevrstvé architektury", jsou...

@uetoyo

Pokud vyvíjíte složitou aplikaci s velmi složitými ? obsáhlými daty, ke všemu ješté od píky, mockovat MB odpovědí v rúzných kombinacích je fakt opruz a ztráta času v týdnech. Moct si spustit testy (třeba celou složku) při psaní nějaké složitejši logiky bez penalizace kolikrát chcete v čase 1s nad reálnou DB je k nezaplaceni - ne vzdy jenom čtete a používáte jednu entitu bez vazeb, že ....
Nehledě na to že když si neco do té Vaší oddělené vtrstvy namockujete a na druhém konci aplikace data zmenite, tak tu chybu objevíte už pri vývoji, ne az po commitech a cekánim na CI/CD testy a vracenim se od dalsi rozdelane prace. A dalsim kolečkem mockováni a CI/CD.

Jinak spouštění určité části testů při každé změně je jedna z běžných praxí, Test Driven Development.

24. 1. 2020, 23:02 editováno autorem komentáře

@uetoyo

"Jasně, ale když máte oddělené vrstvy např. doménovou, tak nepouštím vedle jednotkových testů i integrační po každé změně na svém lokálu"

Však to taky nikdo netvrdil. Ale ne vždy pracujete jenom s jednotkami, že? Např. při hledání problému nebo jejich zkoušením ... Pokud děláte něco složitějšího než "Rabit::sayHello" často pracujete opakovaně s funkcionálními testy. Např. když budujete větší API - jednotky si sice napíšete, ale k čemu je Vám endpoint když si nezkusíte že Vám skutečně něco vrací - což je význam funkcionálních, resp. integračních*, testů. Kruh uzavřen.

*Často se rozdíl stírá s komplexitou a variabilitou aplikace, AFAIK neexistuje jednoznačné rozlišení pro každý případ. Teorie a definicí je samozřejmě hromada, není nutno sem nějakou rychle vygooglenou kopírovat.

"Ještě jinak ...když změna náleží doménové entitě (entitám) tj. operuje jen nad ní, nezajímá mě persistence tj. integrační testy. __TDD není o tom pouštět všechny testy, které navíc vůbec nesouvisí se změnou, kterou jsem udělal__."

1) To nikdo netvrdil
2) Až budete opravdu pravidelně a poctivě testovat zjistíte, že "testy, které navíc vůbec nesouvisí se změnou" je celkem pravidelný zdroj překvapení co všechno je možné rozbít na různých koncích aplikace.

25. 1. 2020, 12:15 editováno autorem komentáře

@uetoyo

Z čeho tak vyvozuji? Vyvozuji tak z toho co tu tvrdíte. Např. ten Váš "vertikální řez" - když se nad tím zamyslíte, tak pokud nemáte jednovrstvou aplikaci, tak Váš kód v oné vrstvě bude mít vždy nějaký vertikální dopad. A je to přesně obsahem oné poznámky:
Až budete opravdu pravidelně a poctivě testovat zjistíte, že "testy, které navíc vůbec nesouvisí se změnou" je celkem pravidelný zdroj překvapení co všechno je možné rozbít na různých koncích aplikace."

Spletl jsem se ale v jedné věci. Na toto není ani potřeba mít žádné zkušenosti s testováním. To, co je obsahem zmíněného výroku, je přesně důvodem velmi častých problémů nasazování netestovaného kódu do produkce a častým zdrojem překvapení zejména mladých programátorů - že úpravou nějaké malé blbosti v jedné vrstvě rozbili nějakou funkcionalitu v úplně jiné vrstvě o 50 souborů vedle, přestože se pokusili po opravě kód ještě prověřit fulltextem IDE.

Nikdo Vás taky nenutí pouštět všechny testy úplně pokaždé, ale většinou (mrkněte do manuálu) se dají pustiti testy jenom pro nějakou jednu dvě složky, něco jako např.
tests/[func|u­nit]]/{*}Handlin­gService (pokud to teda nemáte všechno úplně na jedné hromadě) a nebo se dá často filtrovat podle názvu, např. něco jako
./run --filter "Users|Aeroplane"
či třeba jenom
./run tests/functio­nal/services/so­meService::tes­tHandleSomething což ale může zahrnovat i dalších x vrstev, y souborů a hromadu dat - přes loginy a externí služby .... je dobré moct si vyzkoušet hned na místě že to co bylo zaneseno do testů funguje i po opravě. Napsal jsem dobré, ale je to úžasné, protože mezi tím nemusíte pootvírat dalších milion blbin k další věci než Vám dojede CI/CD a vy zjistíte že jste něco nedomyslel.

A nebo si můžete napsat funkcionální test pro novou metodu a jeho opakovaným spouštěním dokonce zjišťovat jak aplikace funguje, co Vám různé služby vrací a postavit tak úplně novou funkcionalitu (Test Driven Development) nebo prokázat že to zatím nejde a můžete to každému kolegovi jako proof of koncept s užitím debugeru a datových fixtur nechat ukázat třeba 1000x za sebou - a když Vám to pak třeba opraví tak to můžete zrovna nechat jako test - aniž byste se k tomu např. musel pořád proklikávat dokola nějakým rozhraním a lovit nějaké něco někde po lozích a konzolích nějakých aplikací a browserů .... To v CI/CD budete dělat těžko ;-)

25. 1. 2020, 17:55 editováno autorem komentáře

@uetoyo

Hmmm, takže nezamyslel.

* Servisní funkcí předpokládám myslíte funkci v nějaké službě (třídě)

1) V textu který citujete je věta tak pokud nemáte jednovrstvou aplikaci. Bavíme se o apliaci a jejich vrstvách a o tom Vašem "vertikálním řezu", vzpomínáte? Je to opět i v té citaci kterou jste uvedl.

2) To že najdete nějakou konkrétní funkci která nedělá nic s databází nic neznamená, použitá může být na spustně jiných míst a už vůbec to neznamená že jsou takové funkce všechny. I tato Vaše funkce bude nějaký další kód ovlivňovat, pokud to není 'main' funkce s výpisem do konzole z HelloWorld Tutoriálnu. Minimálně bude Vaše aplikace mít nějakou zobrazovací vrstvu.

3) Je hezké že si pouštíte testy i lokálně. Tak proč píšete věci jako

eště jednou: některé testy pouštíme na CI/CD. Nemá smysl je pouštět na lokále. Ano, pokud dělam změnu která řeže projekt vertikálně, tak se to samozřejmě může dotknout různých částí aplikace.

a teď ještě přinášíte příklad který by snad neměl ani vertikální rozměr mít?

Co se mi tu vlastně snažíte tvrdit? Že běžné jsou aplikace které nemají vrstvy a testování po změnách na localhostu je nesmysl?

@uetoyo

Ale já tyto věčné debaty ohledně strategie testováni znám. Samozřejmě na to mám svůj názor, argumenty a znám i spoustu argumentů ostatních stran. Tak argumentuji, nemusím se schovávat za obecné odkazy a tvrzení demonstrované na urcitých řekněme specifických pripadech. Dokonce existují i názory že stačí jenom plné unit testy, někomu stačí jenom code coverage a dokonce jsem nedávno mluvil s člověkemz jiné firmy který se přiznal že nedavno na pohovoru rekl ze testy jsou ztrata času - vsak vi co měnil. To vám neprisuzuji, to jenom abyste videl že tezí je mnoho, já měl za to ze se bavime o reálné praxi a zkusenostech.

Jako myslete si o mě co chcete, ale z denodenní praxe testování vím, že se celkem často chyba nebo zmena projeví i vvdalsich vrstvach aplikace - ono je to taky logicky tím že ty tvrsvy a jejich akce jsou na sebe navázané.

No a speciálně pro Vás: Začnete mluvit o "řezu vrstvami", občas to vztáhnete jenom na vrsrvu persistence (jako v itaci vyse) a příklad dáte s funkcí v nějaké evidentne jednovrstvé implementaci. Asi byste si ty okazy měl projít nejprve sám a pak to vyzkouset i prakticky. Já Vám prakticky priklad dam.

Nedavno jsem opravoval funkci v jedné službě (třída), unit testy jsem upravil, pustil jsem functionalni testy podle jmena (asi 3) a zjistil jsem, ze v jine metode kde je tato funkce pouzita v jednom prípade nastane situace ktera me nenapadla. Kdybych to chtěl zkoušet normálně v dev instanci tak budu muset naklikat asi 4-6 scénářů. Takže behem minuty jsem to zjistil, pak opravil a nechal při MR jet v pipeline testy 25 minut. Tak Vám děkuji za praktickou radu nepustit func. test na localhostu a cekat ? času na pipeline a mezitím někde začínat neco druhého a pak snad i třetího a kdovi kolikátého. Dekuji, rozhodně se Vaší rady drzet nebudu

@uetoyo

A) "Může být, to nepopírám, ale při vhodném vrstvení se to nemusí stávat často."

Tak s tím se dá souhlasit. Každopádně se to dá pomocí testů velice jednoduše zkontrolovat - ano, dokud neproběhnou všechny testy, je to lehce indikační, dá se něco minout, to nezastírám.

B) [1] "Já totiž jen tvrdil , že některé testy nemá smysl pouštět u sebe, že se odchytnou na CI/CD serveru."

Dovolte abych Vám odcitoval
[2] "Jo, jenže proč bych je měl spouštět po každé změně? Od toho tu je právě oddělení na doménový model, infrastrukturu, kam patří repositories a aplikační vrstvu (use-cases). Když už, tak tyhle testy oproti DB nakonec pouštím na CI/CD serveru. Pokud se hrabu v doménovém modelu, vůbec mě tohle nezajímá víz pojem "Persistence ignorance" " [ 24. 1. 2020 16:24 uetoyo]

S [1] bych souhlasil a pravidelně to dělám. S [2] bych nesouhlasil.

C) "To spouštíte např. testy pro všechny verze interpreteru na lokále? Od toho právě máme CI/CD"

Ne, a už jsem to psal
"Nikdo Vás taky nenutí pouštět všechny testy úplně pokaždé, ale většinou (mrkněte do manuálu) se dají pustiti testy jenom pro nějakou jednu dvě složky, něco jako např.
tests/[func|u­nit]]/{*}Handlin­gService (pokud to teda nemáte všechno úplně na jedné hromadě) a nebo se dá často filtrovat podle názvu, např. něco jako
./run --filter "Users|Aeroplane"
či třeba jenom
./run tests/functio­nal/services/so­meService::tes­tHandleSomething což ale může zahrnovat i dalších x vrstev, y souborů a hromadu dat "

D) "To, že to všechno projde u Vás ještě vůbec nic neznamená"

Ano i ne. Není to nutná ani postačující podmínka, ale pro ulehčení si práce a zefektivnění procesu je to velmi užitečné. Ono totiž ani to že Vám projdou testy na CI/CD neznamená že jste otestoval všechno a neexistuje tam nějaká chyba která tam byla zanesena před tím nebo nějakou opravou. Pak jsou na řade quality testy ale tak co si do nich nenapíšete to tam nemáte a chybu lze udělat i v psaní testů - taky se mi stalo mnohokrát.

@Tomas-T

Může být, záleží jak je prostředí postavené. Už jsem viděl kde co a ne vždy je to bohužel ideální i když se lidi fakt snaží.

@Vít Šesták

Jej, to mi nedošlo ... měl jsem na mysli cache databáze aby se nemusela před každým testem obnovovat do výchozího stavu, ne cache dotazů apod.

My máme např. v local dev prostředí asi 9 Docker kontejnerů (komplet local dev env) - některé simulují služby dostupné v amazonu jako RDS (Databáze) nebo nějaký Cloud (to jsem nenastavoval já ani jednou a nikdy se s tím nemuselo nic dalšího řešit ...) a některé (hlavně aplikace) běží přímo v Amazon Elastibeanstalk jako kontejner aplikace nahrávané přes CI/CD. Pro testy na localhostu používáme SQLite, je to jeden soubor, běžně je dostupný v daném kontejneru tato DB je cacheovaná mezi testy. Jak jsem psal, je tam jenom jedno místo u kterého se musel udělat jedena podmínka kvůli nějaké funkcionalitě která se v SQLite chová jinak - je to sice zásah do aplikace "pouze" kvůli testům, zdálo by se to nepřípustné, na druhou stranu je to místo kde už je vyzkoušené že při změně typu databáze bude/byl nějaký problém :-) tedy funkce specifická pro aktuální technologii ...

Tady už se dostávám na tenký led, ale ještě jsem neviděl že by větší databáze běžely v kontejnerech, takže stejně se nějakému ladění defaultů nevyhnete a při každé změně na produkci musíte konfigurovat i vývojové prostředí. Nejlepší to určitě není, ale zatím jsem se fakt už ve více firmách setkal pouze s tím že databáze prostě běžela někde na vlastní pěst, často "Managed" nějakým dohledovým centrem jako služba. Je pravda, že když se to začne rozcházet moc, nejde každá obezlička použít ... DOckerové farmy jsem ještě nepoužíval, naposledy když jsem o tom četl tak tam byla větička o jakémsi experimentálním cosi a běhu v produkci na vlastní riziko .... nevím. nejsem machr přes databáze ...

@Jakub Daněk

Už jsem to psal výše, špatně jsem se vyjádřil. Cacheovaná je celá databáze - její výchozí stav, ne dotazy a kdoví co to umí ještě.

"V době kdy není problém si v dockeru pustit libovolnou databázi na lokálu mi to přijde jako zbytečný odklon od produkčního prostředí."

No, on to problém je. Pro vývoj si ji sice hezky spustíte, ale (abych byl konkrétní) v našem případě teď aktuálně trvá uvedení databáze do výchozího stavu asi 5 min. a ještě je v DEV prostředí navázaná na další - ale ty jsou obnovit rychleji. Těžko si lze představit takto spustit třeba 8 testových metod a před každou uvést databázi do výchozího stavu. Dost nepříjemné je když to musíte udělat 3x za sebou při manuálním testování. S použitím SQLite pod Doctrine je to v řádu vteřin.

"Výše píšete, že nikdy nemáme testovací prostředí úplně shodné s produkčním. To je sice pravda, ale není to pro mě argument pro to se od něj cíleně vzdalovat."

Neoznačoval bych použití jiné databáze pro účely spouštění lokálních testů za účelové vzdalování. Pro vývoj na localhostu máme samozřejmě plně dockerizované prostředí - několik DB instancí a script na jejich uvedení do výchozího stavu i s default daty. Tím se taky hned objeví problém v běhu testů pod jinouo DB. Nicméně pokud má být datový engine zaměnitelný, těžko pak argumentovat tím že je to problematické. Mohu Vám říct že v našem případě rozhodně není a aplikaci bych hodnotil jako nejméně středně složitou, možná i více.

"Abych to shrnul: chápu důvody proč se to používá, ale v dnešní době mi to přijde překonané."

Řekl bych že naopak. Díky modernímu přístupu a abstrakci se z toho dá velmi dobře těžit. Říkáte co je špatně, ale jak je to tedy správně? Máte nějaký konkrétní příklad na nějaké větší/složitější aplikaci?

@Jakub Daňek

Nejde o to jak rychle startuje dazabáze, uvedení databáze do výchozího stavu (data) je časově nepřijemné - speciálně pro použití v testech. O tom je tu řeč.

"Nevím, co to všechno obnáší, ale nešel by vytvořit docker image s už nainicializvanou databází?"

Já měl za to že to máte pořešené a poučíte mne jak se to dělá správně.

@Jakub Daněk

Dobře, připustím že Docker dokonale substituje skutečné produkční prostředí - protože pokud databáze neběží někde jako úplně stejný Docker kontejner i na produkci, vždy je celkem šance že bude v něčem jiná. Připomenu že docker není 1:1 virtuál, ale má vytvořit možnost spustit stejný kontejner jak ve výjovém, tak produkčním prostředí.

Uvedl jste "Nevím, co to všechno obnáší, ale nešel by vytvořit docker image s už nainicializvanou databází?". Možná jsem to špatně pochopil, ale to mi nepřipadá jako "používám to a vím že je to lepší".

Takovou verzi s dockerem jsem používal pro "ručně" spouštěné testy s unit test docker conteinerm od maintainera a nějakým mým vlastním - budu ten projekt muset pohledat, ale pamatuji že tam byl nějaký dowside. A to ještě nevím jak se k tomu postaví buildové prostředí na serverech - zatímco tady mi stačí zkopírovat jeden soubor s daty a dokonce na takové testování existuje běžně používaná knihovna. Ale nasadil jste mi brouka do hlavy, to je pravda, musím se mrknout jestli se mi nepodaří s tím nějak pokročit, možná prokázat co je lepší.

30. 1. 2020, 17:48 editováno autorem komentáře

@Jakub Daněk

Děkuji za link, určitě se na to podívám, zdá se dokonce na letmý pohled že tam toho není moc :-)

No ona ta debata vlastně vznikla na zaměnitelnosti vrstev, takže to o čem se bavíme jsou teoreticky dvě strany jedné mince - bavili jsme se o zaměnitelnosti vrstev, ale jedna strana mince vlastně je že není dobré je zaměňovat (a testovat v idálně přesně odpovídajících kontejnerech) a druhá, ta o které mluvím já, je dbát na praktickou zaměnitelnost, testovat s použitím jiných databází (vlastně jenom kvůli rychlosti testů), ale pak nemít plně shodné prostředí s produkčním.

Ano, uvědomuji si že mluvím o vrstvách, zatímco reálně řeším/řešíme jenom datovou vrstvu - to ale vlastně protože nevěřím, z hlediska mých praktických zkušeností, na to, že když použitím nějaké technologie budujete nějakou třeba prezzentační vrstvu několik let, tak ji můžete nějak jen tak zaměnit výměnou nějakého enginu. To je utopie a krom databázového uložiště a systémů postavených na APIs jsem neviděl že by se někdy něco takového měnilo nebo se dalo vyměnit bez zahození a znovunapsání.
Aplikační vrstvy mi dávají vetší smysl z důvodu testování a možnosti řekněme substituce v rámci vrstvy, nebo spíš dekompozice v třídách, ale jinak asi prakticky ne ....

31. 1. 2020, 12:48 editováno autorem komentáře