🚀 go-pugleaf

On Thu, 4 Nov 2010 15:05:04 +0100, GrzybSon wrote:
> <snip>
> Chodzi mi o to by te metody testowe wykonywały sie w odpowiedniej kolejności 
> np. Zaloguj najpierw potem dalsze i na końcu wyloguj.
> Czy da sie nadać kolejność metodom testowym?

Generalnie Unitem w Twoich Unit Testach powinien
być kompletny flow of control:

TestLogowania:
 ws.Login();

TestRobieniaCzegos:
 ws.Login();
 ws.RobCos();

TestRobieniaCzegosInnego:
 ws.Login();
 ws.RobCosInnego();

w taki sposób żeby każdy test był samodzielnym,
wyizolowanym i spójnym bytem nie polegającym na
niczym zewnętrznym.

[ http://stackoverflow.com/questions/61400/what-makes-a-good-unit-test ]

Nie powinieneś polegać na kolejności testów,
na efektach ubocznych innych testów, niektóre 
frejmłorki wykonują testy alfabetycznie, niektóre 
losowo, taka jest specyfika Unit Testing.
[NUnit akurat odpala testy alfabetycznie, aczkolwiek
 nie radziłbym na tym polegać ;-)]

Defacto, test [ze środka] nie powinien zawieść tylko
dlatego bo Dev/Tester odpalił tylko ten jeden test,
zamiast odpalać wszystkie.

p.s. z ciekawości, mock'ujesz WebService czy komunikujesz
     sie z realnym endpointem? ;-)

-- 
Pozdrawiam,
Łukasz 'Maly' Ostrowski.      http://l3v.eu/

> Generalnie Unitem w Twoich Unit Testach powinien
> być kompletny flow of control:
>
> TestLogowania:
> ws.Login();
>
> TestRobieniaCzegos:
> ws.Login();
> ws.RobCos();
>
> TestRobieniaCzegosInnego:
> ws.Login();
> ws.RobCosInnego();
>
> w taki sposób żeby każdy test był samodzielnym,
> wyizolowanym i spójnym bytem nie polegającym na
> niczym zewnętrznym.

Ox, dzięki za wyjaśnienie.

>
> [ http://stackoverflow.com/questions/61400/what-makes-a-good-unit-test ]
>
> Nie powinieneś polegać na kolejności testów,
> na efektach ubocznych innych testów, niektóre
> frejmłorki wykonują testy alfabetycznie, niektóre
> losowo, taka jest specyfika Unit Testing.
> [NUnit akurat odpala testy alfabetycznie, aczkolwiek
> nie radziłbym na tym polegać ;-)]
>
> Defacto, test [ze środka] nie powinien zawieść tylko
> dlatego bo Dev/Tester odpalił tylko ten jeden test,
> zamiast odpalać wszystkie.

Oki.

>
> p.s. z ciekawości, mock'ujesz WebService czy komunikujesz
>     sie z realnym endpointem? ;-)

Nie wiem co to znaczy mockować, ale działam na żywym realnym webserwisie 
odpalanym pod środowiskiem.
Można to lepiej zrobić? 

>> TestLogowania:
>> ws.Login();
>>
>> TestRobieniaCzegos:
>> ws.Login();
>> ws.RobCos();
>>
>> TestRobieniaCzegosInnego:
>> ws.Login();
>> ws.RobCosInnego();
>>
>> w taki sposób żeby każdy test był samodzielnym,
>> wyizolowanym i spójnym bytem nie polegającym na
>> niczym zewnętrznym.

jeśli się da, to dobrze pomyśleć o wydzieleniu login/logout do metod z 
atrybutami [SetUp]/[TearDown], żeby nie powielać ich wewnątrz każdego testu.

Wiktor Zychla
 

Dnia 04-11-2010 o 16:46:01 Wiktor Zychla <wzychla@nospam.com> napisał(a):

>>> TestLogowania:
>>> ws.Login();
>>>
>>> TestRobieniaCzegos:
>>> ws.Login();
>>> ws.RobCos();
>>>
>>> TestRobieniaCzegosInnego:
>>> ws.Login();
>>> ws.RobCosInnego();
>>>
>>> w taki sposób żeby każdy test był samodzielnym,
>>> wyizolowanym i spójnym bytem nie polegającym na
>>> niczym zewnętrznym.
>
> jeśli się da, to dobrze pomyśleć o wydzieleniu login/logout do metod z  
> atrybutami [SetUp]/[TearDown], żeby nie powielać ich wewnątrz każdego  
> testu.
>
> Wiktor Zychla
>

Setup/Teardown nie jest zalecane, bo utrudnia czytanie kodu testu.
W takim MBUnit chyba celowo wogóle nie umożliwili Setup/Teardown.

Co do mockowania WS. To jest test tego WS więc nie można tego zmockować :)
Ja na to patrzę tak. WebService jest tylko interfejsem do mojej logiki tak  
samo
jak może nim być okienko, lub konsola i klawiatura.
Logika do osobnej klasy/klas i testujemy klasy. A potem testy integracji  
testujące
czy da się to wywoływać przez WS raz na jakiś czas. Testy jednostkowe w  
całości bez żadnych trudności,
konfiguracji itd powinny być bez problemu wykonywane na każdym komputerze  
w krótkim czasie.

On Thu, 04 Nov 2010 19:46:58 +0100, 3P wrote:
> Setup/Teardown nie jest zalecane, bo utrudnia czytanie kodu testu.
> W takim MBUnit chyba celowo wogóle nie umożliwili Setup/Teardown.

Agreed.

> Co do mockowania WS. To jest test tego WS więc nie można tego zmockować :)
> Ja na to patrzę tak. WebService jest tylko interfejsem do mojej logiki tak  
> samo
> jak może nim być okienko, lub konsola i klawiatura.

Dyskusyjne, zależy czy testuje WS-behaviour czy composite clienta do 
tegoż serwisu =]. ;-)

> Logika do osobnej klasy/klas i testujemy klasy. A potem testy integracji  
> testujące
> czy da się to wywoływać przez WS raz na jakiś czas. Testy jednostkowe w  
> całości bez żadnych trudności,
> konfiguracji itd powinny być bez problemu wykonywane na każdym komputerze  
> w krótkim czasie.

Agreed again. ;-)

>> Nie wiem co to znaczy mockować, ale działam na żywym realnym webserwisie 
>> odpalanym pod środowiskiem.

Mock - udawać, nie używać żywej implementacji czegoś, tylko uhm, kontraktu.

http://en.wikipedia.org/wiki/Mock_object

-- 
Pozdrawiam,
Łukasz 'Maly' Ostrowski.      http://l3v.eu/