Obecně k testování – kontorlovat vstup nejníže + databáze

Technicky je možné testovat i db – v setUp ji vyrobíš a naplníš, v tearDown roztrháš.
Tím otestuješ i SQL dotazy, ale je to pomalejší a je víc práce s aktualizací testovacích dat.

Rychlost můžeš vylepšit tím, že budeš používat třeba in-memory SQLite, ale pak v ní nefungují MySQL (nebo co používáš)-specific věci.

Aktualizaci dat si můžeš usnadnit tím, že je nebudeš uchovávat jako SQL dumpy, ale PHP pole (nebo Neon/Yaml/CSV) a do db budeš importovat z nich. Nebo mít master db, ze které děláš kopii. Ale když je dat víc a ještě prolinkované přes cizí klíče, tak je to prostě oser.

Takže odpověď není jednoznačně ano / ne, ale seznam pro a proti, a business se rozhodne, jestli mu to za ty náklady stojí.

Já to dělám tak, že co nejvíc logiky mám bez dotazů do db (jako máš ty v té service), a ty pak můžu unit testem proklepat ze všech stran na nejrůznějších datech, které mám v @dataProvider. Někdy mám získávání dat aspoň v metodách, které namockuju.

Krom toho mám hrstku integračních testů, které to projedou celé skrz naskrz, včetně databáze.
A pak mám smoke testy – seznam url, které nesmí házet chybu. Ty jsou taky s db, ale nekontrolují všechny stavy.

Dělám na malých projektech, kde jsou zákazníci v pohodě, když tam občas vznikne chyba.
Nějak se mi ani nestává, že bych měl chybu v dotazu do db. Složitější logiku nepíšu v SQL, ale v PHP. Jestli je i to řazení kritické, tak ho dej taky do PHP.

Editoval petr.pavel (7. 4. 2022 10:30)

@JiříNápravník A proč si ta service netahá ta data z té databáze pomocí té fasády?
Z jakého důvodu fasáda co tahá data z databáze je pak posílá do služby a ne naopak, tedy proč si služba netahá ta data z té fasády?

Respektive pokud bych měl například nějaký datagrid, tak ty říkáš, že například Presenter vezme fasádu, zavolá nad ní findData a to, co vrátí ta fasáda, tak Presenter vezme, vytvoří službu datagridu a té předá ta seřazená data? Pak ano, musíš v té službě testovat, jestli data přišla v pořádku a jestli je požaduješ seřazená, tak ano, musíš testovat i to seřazení.

Proč to ale není jinak a to tak, že datagrid bude jako závislost brát například tento interface:

interface DataProvider
{
	public function findOrderedData(int $page, int $itemsPerPage, string $sortColumn, bool $sortDirection): array;
}

A z něj si ta data sám pomocí této metody tahat? Ze signatury metody vyplývá, že ten, kdo ten interface implementuje, tak musí tuto metodu implementovat taky a ta již MUSÍ ta data vracet seřazená. Tedy to, jeslti ten provider seřazená data vrátil, nebo ne už není starost té servicy, jelikož ta počítá s tím, že kdo to implementoval, tak dodržel pointu té metody a toho interface, což se mimo jiné testuje pomocí UNIT testů.

Respektive pomocí mnou navrhovaného řešení by fasáda implementovala initerface DataProvider a ta ‚service‘ která ta seřazená data potřebuje by brala jen instanci DataProvideru, tedy té tvé fasády.
Díky tomu získáš hned 3 výhody.

1. Nemusíš v service řešit, jestli instance implementující rozhraní DataProvider vrátila seřazená data, jelikož to je popisem toho interface, což je již otestováno UNIT testama.
2. Tím, že netaháš data z databáze a neposíláš tam výsledná data, ale jen objekt, který se stará o získání těchto dat v tvou požadované formě docílíš toho, že daná service si ta data vytáhne až když je potřebuje, takže aplikace je pak víc lazy.
3. Provider můžeš do servicy předávat přes DI, protože provider může být taky služba. Tím ušetříš tuny kódu a jak se říká, LESS CODE, MORE SECURITY. A taky se míň napíšeš :D Což je výhoda, jelikož práci dokončíš za kratší čas a dostaneš víc peněz. :D

EDIT 1
Ještě jsem zapomněla napsat odpověď na jednu tvou otázku. Ani v mnou poskytnutém řešení není třeba sestavovat databázi a tu si testovat, ale je možné, jelikož datagrid požaduje DataProvider, si DataProvider mocknout a tedy UNIT testy dané servicy mohou proběhnout v pohodlí domova bez přístupu k databázovému serveru.

EDIT 2
Ještě jedna věc… :D Alternativně nemusí být nastavení v direktivě té metody v DataProvideru, ale může ten DataProvider sloužit jako nějaký builder dat, kde bude už jen metoda build/get apod., díky čemuž nebude muset ta tvá služba vůbec nic věděto tom, jaké je pořadí, další parametry vyhledávání apod.

Editoval Polki (16. 4. 2022 5:04)

@JiříNápravník

Píšeš, že to je už i UNIT testováno, ale nějak nerozumím jak, v tomto případě, můžeš mě nasměrovat?

Určitě můžu.
Ale asi spíše na mailu, nebo jiném komunikačním rozhraní. Rozepisování by bylo na dloouho a nechci tu zase spamovat fórum.