Persistence layer unit testing best practices

I've been doing some searching on best practices for unit testing the persistence layer with DBUnit and I'm interested in people's feedback on my policies or pointers to policies others have created.

For example I've been thinking of making our company's policy as follows:

1. Unit tests can rely on certain rows with certain Id's being in the database in pristine format (loaded with DBUnit).
2. Unit tests can select DBUnit loaded row id X in table foo, reinsert it with a new id, and then change it or delete the newly added record, but should leave DBUnit loaded records pristine.
3. It's not OK for a unit test to modify DBUnit loaded rows because other unit tests expect those rows to be there.
4. A unit test cannot depend on a certain number of rows being in the database because it will likely contain the DBUnit loaded rows as well as some unknown number of rows that may be left over form other unit tests.
5. In general it's good policy for a unit test to clean up new data it added during the test but not absolutely required because when a unit test fails it may leave bad data behind.

Do these policies seem reasonable or are there other places I should be looking for these types of best practices?

This entry was posted in Java. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *