[alg] unit testing: gedrag van setup en teardown

[JeroenTheStig]

Vorige week zijn we begonnen met een Oracle project waarin we voor het testen van onze plsql-code gebruik gaan maken van een unittest framework, genaamd utplsql.
Nu was ik even aan het spelen met het gedrag van ut_setup en ut_teardown om vast te stellen of het gedrag hetzelfde is als in het JUnit framework voor Java, waar utplsql van is afgeleid.

Wanneer met JUnit een TestCase wordt uitgevoerd waarin een setUp() en tearDown() en twee testmethodes (bijvoorbeeld testOne() en testTwo()) zijn gespecificeerd, dan zal het JUnit framework de methoden als volgt aanroepen:

code:

setUp()
testOne()
tearDown()
setUp()
testTwo()
tearDown()

Heel logisch, want je wilt voor elke test die je specificeert exact dezelfde beginsituatie hebben die je in je setUp opstelt. Bijvoorbeeld een set records die je in een dummytabel plaatst en na je test weer netjes verwijdert. Op deze manier zijn je verschillende testmethoden binnen een testcase niet afhankelijk van elkaar.

Nu heb ik in utplsql exact hetzelfde voorbeeld aangemaakt, waarin ik in een testpackage een ut_setup, een ut_teardown en twee testprocedures (ut_testOne en ut_testTwo) heb gespecificeerd.

Tot mijn verbazing bleek het gedrag als volgt te zijn:

code:

ut_setup
ut_testOne
ut_testTwo
ut_teardown

Stel dat ik in mijn setup een bestand klaarzet in een directory waarop een procedure die ik wil testen op los gelaten worden. In ut_testOne laat ik de procedure los op de file met bepaalde parameters en na de bewerking wil ik een assert equal uitvoeren over de gemuteerde file en een reeds aangemaakte file zoals ik het had verwacht.

Vervolgens wordt testTwo uitgevoerd die de procedure loslaat op het bestand met andere parameters dan in testOne. Ook hier wordt een mutatie uitgevoerd in het bestand die ik vervolgens wil vergelijken met een bestand zoals ik had verwacht zoals die eruit zal zien na uitvoering van procedure2.

Echter, het bestand is al door testOne gemuteerd waardoor testTwo totaal in de soep loopt. De twee tests zijn dus afhankelijk van elkaar geworden, wat IMHO nooit mag gebeuren bij unittesting.

Over voorgaande heb ik twee vragen:
1: Is Unittesting een standaard afspraak hoe tests uitgevoerd worden, of dit nou in Java, C++, PL/SQL of Delphi wordt toegepast? Als dit inderdaad zo is, dan zou ik zeggen dat utplsql de standaarden heeft geschonden.

2: Klopt het dat de reden van setup en teardown niets anders is dan dat je voor elke gespecificeerde testmethode/procedure dezelfde beginsituatie hebt? Ik geloof namelijk dat de manier zoals utplsql omgaat met de setup en teardown totaal zijn doel voorbij schiet.

[prototype]

Ik heb helaas geen ervaring met utplsql, maar wel met unittesting, dus misschien dat ik wat zinnigs kan zeggen

1: Goede vraag. Met de nieuwe JUnit 4 is dit puntje iig een stuk duidelijker geworden, met de komst van annotations in java. In JUnit maakt men zo nu onderscheid tussen @BeforeClass en @AfterClass om als methode markers te dienen voor methodes die respectievelijk voor en na de testclass dienen te draaien. Zo heeft men ook @BeforeTest en @AfterTest om op analoge wijze dit voor en na tests te doen. Een verloop zou dan als volgt eruit zien:

code:

@BeforeClass
@BeforeTest
@Test
@AfterTest
@BeforeTest
@Test
@AfterTest
@AfterClass

2: Zie 1. Voor utplsql schiet kennis mij tekort om daar zinnige uitspraken over te kunenn doen. Succes.

[JeroenTheStig]

Dat ziet er inderdaad duidelijker uit. De annotations laten beter zien wat het gedrag is.
Wat wel een vreemd gedrag van JUnit is, is dat per testmethode een instantie van de testklasse wordt aangemaakt. Als je namelijk een constructor toevoegt aan je testklasse, dan zie je dat die net zo vaak wordt aangeroepen als dat er testmethodes zijn in die klasse. Wat hier dan de reden van is, is mij een compleet raadsel.

[momania]

Boktor schreef op vrijdag 08 september 2006 @ 11:16:
Dat ziet er inderdaad duidelijker uit. De annotations laten beter zien wat het gedrag is.
Wat wel een vreemd gedrag van JUnit is, is dat per testmethode een instantie van de testklasse wordt aangemaakt. Als je namelijk een constructor toevoegt aan je testklasse, dan zie je dat die net zo vaak wordt aangeroepen als dat er testmethodes zijn in die klasse. Wat hier dan de reden van is, is mij een compleet raadsel.

Kijk dan eens naar TestNG. Dat werk ook met annotations, maar is nog uitgebreider dan JUnit en maakt tenmisnte niet per testmethod de hele class op nieuw aan

[JeroenTheStig]

Oke, dus als ik het goed begrijp is Unittesting geen algemene standaard? Want het gedrag verschilt dus per framework?
Er bestaan dus geen afspraken over de setup- en teardown-methodes/procedures?

[momania]

Idd

Enige 'standaard' aan unit testen is dat je losse units test imo. Dat is de basis en de uitwerking zal per taal/unittest framwork verschillen