(Unit) testing en in-memory DB met hsqldb

[Standeman]

Ik ben bezig om een aantal tests op te zetten, zodat we onze DAO's automatisch kunnen testen. Nu had ik bedacht om met JUnit 4.5 in de setUp method een memory only database aan te maken met hsqldb zodat ik niet afhankelijk ben van bestaande databases die misschien wel niet runnen e.d.

Ik zit nu alleen met 1 probleempje. Het DB schema staat gewoon als sql script in onze repository. Ik zit me alleen af te vragen hoe ik het script kan runnen in mijn memory only db? Ik kan natuurlijk de file parsen (elke ; is een nieuw statement) en elk statement afschieten, maar dat lijkt me nogal omslachtig.

Iemand een idee hoe ik van mijn create schema script naar een DB schema in hsqldb kan komen?

edit:

Oh en ik gebruik gewoon plain old JDBC en geen hibernate o.i.d. (dan was het makkelijk geweest).

[ Voor 7% gewijzigd door Standeman op 01-04-2009 14:40 ]

[MBV]

Waarom niet SQLite gebruiken? Dat werkt met bestanden, is self-contained, en kan vziw ook gewoon SQL-bestanden importeren.

En verder: tja, splitten op ; lijkt me nou ook niet zo'n groot drama.

[Niemand_Anders]

Je kunt ook een SQLite database opnemen als resource van je unittest. Je hoeft dan niet bij elke test run opnieuw je database aan te maken. Op deze manier kun je zeer goed je DAO testen. Echter voor elke DAO implementatie heb je natuurlijk ook test cases nodig en daarvoor heb je natuurlijk wel een draaiende database nodig.

[Standeman]

SQLite is op zich ook een mogelijkheid, maar is een beetje traag in vergelijking met HSQLDB. Verder bied HSQLDB ook wel file based DB's (zelfs als text). Aangezien de DAO's bij elke build gerund worden, wil ik het geheel zo lightweight mogelijk houden.

zie:

Misschien moet ik gewoon wel bij elke run van de testcases met ant het schema opnieuw uitvoeren, dat kan ook natuurlijk.

[ Voor 23% gewijzigd door Standeman op 02-04-2009 08:31 ]

[Verwijderd]

Wat wil je eigenlijk testen: Je DAO's of je Database?
Wat je nu doet is een halve integratie test (dao <--> jdbc <--> database) en daar is natuurlijk niets mis mee. Echter test je dan wel een integratie die afwijkt van de werkelijke productie omgeving en de vraag is dan wat de waarde van zo'n test is.

Volgens mij dien je om de correcte werking van een DAO aan te tonen de volgende twee zaken te testen:
1. De correctheid van de SQL
Hiervoor heb je helemaal geen DAO nodig. Het gaat hier puur om de SQL zelf, doet de query wat je er van verwacht?

2. De logica van de DAO
Hier test je of de DAO de juiste/verwachte SQL naar database stuurt en op een juiste/verwachte manier met het resultaat om gaat. Dit onderdeel is prima te mocken en behoeft helemaal geen draaiende database server.

Ik zou elke vorm van integratie tests zoveel mogelijk buiten je unit tests houden. Te lang draaiende unit tests (natte vinger: meer dan 30 sec in totaal) zorgen er immers voor dat ze niet meer lokaal uitgevoerd worden.

[Standeman]

hmmm, goed punt.

Ik wil eigenlijk beide, maar idd wel de integratie buiten mijn unit tests houden.

1) De SQL wordt in de DAO gegenereerd. Ik wil graag de SQL op juistheid controleren en of het werkt op met het db schema. Ik begrijp niet helemaal wat dan bedoeld dat ik de DAO daar niet voor nodig heb.

2) Daar heb je gelijk in. Ik ga gelijk easymock uit de kast halen

[Verwijderd]

Je zou bijvoorbeeld het volgende kunnen testen met as voorbeeld de volgende class:

Java:

public interface UserDao {
  Set<User> findAllById(Collection<Long> userIds);
}

Een implementatie genereert de sql die er bijvoorbeeld zo uit ziet:

SQL:

select * from user where user.id in (1, 4, 5)

Nu hoef je alleen maar te controleren dat (een bepaalde methode uit) je implementatie de juiste SQL genereert (dus de verwachte sql oplevert) op basis van 'userIds' en deze over een mock connectie verstuurt. Tevens kan je een fake result set mocken (je noemde easymock al) om het resultaat te testen.

[Standeman]

Ah, helemaal duidelijk. Eigenlijk een beetje suf dat ik er zelf niet aan dacht, maar soms is het lastig om een andere richting op te denken. Het scheelt iig een hoop geneuzel op deze manier met schema's in mijn unit tests e.d. Ik geloof dat ik hier wel vrolijk van wordt.

Heb je zelf nog een favoriet mocking framework? De enige waar ik tot nu toe mee heb gewerkt is easymock.

[jAnO!]

Even voor een mocking framework, ben heel enthousiast over Mockito!

http://mockito.org

voor een vergelijk:

http://code.google.com/p/mockito/wiki/MockitoVSEasyMock

[Standeman]

jAnO! schreef op donderdag 02 april 2009 @ 12:29:
Even voor een mocking framework, ben heel enthousiast over Mockito!

http://mockito.org

voor een vergelijk:

http://code.google.com/p/mockito/wiki/MockitoVSEasyMock

Mockito ziet er inderdaad er net even wat eenvoudiger uit. Ik denk dat ik er in iedergeval even mee moet gaan spelen.