ugrás a tartalomhoz

PhpUnit - közös teszt változók

inf · 2013. Szep. 19. (Cs), 15.45
Van egy olyan - szerintem elhibázot - húzása a phpunit-nak, hogy ha csinálsz egy testcase-t, és abban több teszt metódust, akkor minden teszt metódushoz újra példányosítja a case-t, és futtatja a setup-ot. Be lehet állítani valahogyan, hogy ezt ne tegye, és csak egy testcase példányt hozzon létre, és azon futtassa az összes megadott metódust? Baromira zavaró ez a viselkedése, főleg integrációs teszteknél, ahol igyekszik spórolni az ember az adatok legatterolásával és újra feltöltésével, hogy gyorsak legyenek.
‹ Form időzítés 2 szintű legördülő menü ›
 ■
1

Statikus változó? És olyankor

MadBence · 2013. Szep. 19. (Cs), 17.06
Statikus változó? És olyankor feltételesen setupolsz.
2

Ja, most ezt csinálom, de

inf · 2013. Szep. 19. (Cs), 17.15
Ja, most ezt csinálom, de ocsmány a kód... :-) Azt hittem van valami megoldás arra, hogy kikapcsoljuk ezt a "feature"-t. Eleve nem is értem, hogy milyen logika vezette ehhez a megoldáshoz a fejlesztőket...
3

Csökkenteni akarták az

tgr · 2013. Szep. 19. (Cs), 17.23
Csökkenteni akarták az esélyét, hogy összeakadjanak a tesztek? Mindenesetre létrehozhatod az objektumaidat a setupBeforeClass-ban, aztán átadhatod global/static változóként (csak vigyázz arra, hogy a global/static izoláció ne legyen bekapcsolva), vagy tárolhatod őket a TestSuite-ban (gondolom, sose próbáltam még).
4

+1

janoszen · 2013. Szep. 19. (Cs), 17.30
+1, a tesztek ne akarjanak osszefuggeni.
5

Ez így teljesen értelmetlen,

inf · 2013. Szep. 19. (Cs), 18.03
Ez így teljesen értelmetlen, akkor minek van a @depends? Egyszerűen túlgondolták az egészet szerintem. Egyáltalán nem úgy viselkedik a testcase, mint ahogy azt várná az ember...

Ilyen túlbonyolítás helyett tökéletesen elég lett volna a következő:

class MyTestCase extends TestCase {
	protected $setupForEveryTest = false;
	public function setup(){
		$this->pdo = new PDO(...);
	}

	public function main(){
		$this->run(function ($tc){
			$tc->test1()
		});
		$this->run(function ($tc){
			$tc->test2()
		});
		...
	}
	
	public function test1(){
		$this->pdo->...
	}
	
	public function test2(){
		$this->pdo->...
	}
	
}
Az alap main megadási sorrendben hajtja végre a teszteket, a @depends kiváltható a main felülbírálásával, a minden test-re külön setup is beállítható, meg ha nagyon akarják, akkor a minden test-re letakarítás is. Mindegy, valahogy sosem voltam elégedett ennek a S. Bergmann gyereknek a munkájával, biztos csak szőrszálat hasogatok...
6

Kösz, a setupBeforeClass

inf · 2013. Szep. 19. (Cs), 18.17
Kösz, a setupBeforeClass valszeg működni fog, mindjárt megnézem...
7

"főleg integrációs

firith · 2013. Szep. 19. (Cs), 18.20
"főleg integrációs teszteknél"

phpunit unit tesztelésre lett kitalálva, nem integrációs tesztelésre.
8

Ez nem magyarázza, hogy miért

inf · 2013. Szep. 19. (Cs), 18.23
Ez nem magyarázza, hogy miért kell hibásan megtervezni valamit.
9

Miért lenne már az a hibás

tgr · 2013. Szep. 19. (Cs), 18.49
Miért lenne már az a hibás tervezés, hogy a TestCase osztály egy testcase-t ír le és nem egy test suite-t? Te, ha mondjuk készítesz egy User osztályt, és ki kell listáznod tíz usert, ugyanazt a User objektumot használnád mind a tízre, vagy különbözőt?
10

Mielőtt túl messzire megyünk

inf · 2013. Szep. 19. (Cs), 22.09
Mielőtt túl messzire megyünk az eredeti kérdéstől, a phpunit-nak van dbunit nevű kiterjesztése, ami direkt integrációs tesztekhez van, legalábbis valamennyire megtámogatja az sql tesztelést. Szóval a phpunit nem csak unit test-ekhez van.

Te, ha mondjuk készítesz egy User osztályt, és ki kell listáznod tíz usert, ugyanazt a User objektumot használnád mind a tízre, vagy különbözőt?


Nyilván ebben az esetben példányosítom 10x a User osztályt.

Ha a User osztályodnak van tíz metódusa, akkor te mindegyik metódus meghívásához csinálsz külön User példányt, vagy meghívod őket ugyanazon a példányon?
11

Tehát ha van tíz külön

tgr · 2013. Szep. 20. (P), 16.52
Tehát ha van tíz külön testcase-ed, mindegyik saját annotációkkal, saját izolációs környezettel, saját adatforrással, saját mock registry-vel, saját eredménnyel, akkor kézenfekvő, hogy mindegyikhez létre fogsz hozni egy TestCase objektumot, aminek van egy TestResult-ja, egy DataProvidere stb stb, nem pedig ugyanabba az objektumba próbálsz mindent belegányolni.
13

Persze. Viszont ilyen esetben

inf · 2013. Szep. 21. (Szo), 00.16
Persze. Viszont ilyen esetben nyilván mindegyik testcase-nek csinálok külön osztályt, és azokat példányosítom egyesével, nem pedig összeszórom egy osztályba és azt példányosítom 10x, amikor mindegyik testcase eltérő dolgot csinál, és "a tesztek nem függenek össze". Ez a mostani megoldás a phpunitban annyira nem oo, hogy az már fáj...
14

Minden metódust külön

tgr · 2013. Szep. 21. (Szo), 15.42
Minden metódust külön osztályba tenni OO design szempontból talán szebb lenne, ugyanakkor a felhasználónak roppant kényelmetlen, és gyakorlati haszna nincsen, úgyhogy az a kézenfekvő megoldás, amit az xUnit tervezői is választottak.
15

Én nem tartom jó megoldásnak,

inf · 2013. Szep. 21. (Szo), 16.39
Én nem tartom jó megoldásnak, de jelenleg nem akarok unit test rendszert fejleszteni, meg energiám sincs több erre a témára... Nekem azért nem tetszik, mert első ránézésre egyáltalán nem egyértelmű, hogy minden metódus külön példány alatt fut, és ha egy api első ránézésre nem egyértelmű az szerintem rossz.
16

nem hibás tervezés

Drawain · 2013. Szep. 22. (V), 15.17
Ez tudtommal nem hibás tervezés, ez a funkció az xUnit rendszerekben így működik, ők pontosan úgy implementálták, ahogy az ennek alapján várható volt.

A probléma megoldása pedig nem túl bonyolult, csak a TestCase osztályt be kell wrappelni egy saját TestCase osztályba, ami az általad elképzelt viselkedést valósítja meg.
17

A probléma megoldása pedig

inf · 2013. Szep. 22. (V), 18.37
A probléma megoldása pedig nem túl bonyolult, csak a TestCase osztályt be kell wrappelni egy saját TestCase osztályba, ami az általad elképzelt viselkedést valósítja meg.


És az automatikus TestCase osztály és test metódus felderítés ugyanúgy működni fog? Nem hiszem... (Mondjuk próbálni nem próbáltam, de nem jellemző, hogy ennyire rugalmas lenne 1-1 rendszer.)
12

subscribe

tihi · 2013. Szep. 20. (P), 19.04
subscribe