Jak správně testovat dibi fluent

2bfree

Ahoj,

zajímal by mne váš názor, kterak „správně“ jednotkově testovat Dibi fluent?

Například když je kód následující:

<?php
$this->getConnection()
	->select('[column_one]')
	->select('[column_two]')
	->from('[table]')
	->where('[column_three] = %s', 'value')
	->where('[column_four] >= (%SQL)', $this->getConnection()
			->select('MAX([colum_four])')
			->from('[table]')
			->where('[column_five] = %s', 'value')
			->__toString())
	->orderBy('[column_two] DESC'))->fetchAll()
?>

Tharos

K čemu je dobré jednotkově testovat DibiFluent? ;)

Ty asi spíš chceš jednotkově testovat logiku, která je postavená nad DibiFluent, je to tak?

2bfree

Možná špatně chápu význam Unit testů, ale mám za to, že je dobré otestovat, že metoda dělá co dělat má. A je-li její význam vrátit objekt třídy DibiFluent, který je určitým způsobem nastavený, tak bych IMHO měl asi chtít toto chování otestovat? No ne?

2bfree

Jediné co mě napadá je testovat, že výstup z DibiFluent->__toString() odpovídá řetězci.

Tharos

Testovat vygenerované SQL je legitimní.

Neznám kontext, ale ještě spíš než vygenerované SQL bych asi testoval to, že nad nějakými „fixtures“ daty mi ten dotaz vrátí kýžený výsledek.

Akademicky správně bys měl v takovém případě celé dibi namockovat, ale na to bych se ve většině případů vykašlal. (Dokud by mi benefity takové izolace nepřevážily náklady na ní.)

2bfree

Takže když to shrnu, jednotkově testovat SQL query a integračně testovat data nad fixtures stavem databáze?
Díky za rady a tipy.

Tharos

Disclaimer: následující text je můj subjektivní pohled na věc.

„Striktně“ jednotkové testy na části kódu přímo používající dibi se poměrně obtížně píšou právě proto, protože správně bys měl namockovat všechny potřebné části dibi. Sice na to existují nástroje, ale stejně to s sebou nese velký overhead. Řešením je nemockovat dibi a smířit se s tím, že takový test není dokonale jednotkový (má nádech jakéhosi akceptačního testu) a s tím, že test může selhat i v případě nějaké chyby v dibi. Což v praxi příliš nevadí, naopak. :)

Co se fluentu týče, kromě vygenerovaného SQL se ještě nabízí možnost kontrolovat vnitřní stav, jakého DibiFluent postupně nabývá. Problém je, že DibiFluent ten stav nativně ven nepoví a je zapotřebí si trochu vypomoci. Já to dělám takhle, přičemž tohle mám potom v Connection.

Ty bys mohl testům podstrčit takové Connection, které vyrábí fluenty, ze kterých lze vyčíst jejich vnitřní stav. Následně už bys jenom kontroloval, že po sérii volání nad fluentem je ten stav takový, jaký ty chceš.

Tohle má hlavně výkonnostní výhodu – DibiFluent se takto nemusí překládat do SQL. (A že ten překlad umí být drahý… Proto to třeba v té odkazované knihovně takhle dělám.)

Ještě pak používám trochu jiné názvosloví. :) Integrační test je pro mě takový test, který de facto testuje komunikaci mezi objekty (jaké metody, s jakými parametry a kolikrát se volají). Přiznám se, že takový test jsem už nějaký pátek nenapsal… ;)

Editoval Tharos (27. 3. 2014 12:58)

2bfree

Díky moc za rozbor. Věřím že to pomůže nejen mě.

Filip Procházka

Nevidím důvod testovat dibi fluent, ale testovat že vygenerované SQL po aplikování na databázi vrací co má už by smysl mít mohlo :)