How can I unit-test my database content?

We have a case where we are testing a swing application. We have a QA person who up until now was doing manual testing of the app. Now we have realised that manual testing takes a long time to repeat and hence investing time into automated testing of our UI using Fest.

The other side of the coin is testing the database data. Meaning after doing some steps in the GUI, we need to check with the database if the data we expect is present there or not.

Since it's a QA guy who is writing these unit tests for us, we would like to make it as easy as possible for him by providing some sort of framework in order to do this.

Is there some sort of a framework which will test the database against the data that we have? Something like an expected and actual as with JUnit's assert.

Basically we are looking for a framework that has these features:

1. The 'expected' data should be easy to provide like in a YA开发者_如何转开发ML, JSON, Excel Sheet, CSV way. XML and writing code to create beans in java is time consuming.
2. We would like to create the expected data such that only the columns present in the expected data should be checked against the database.
3. We don't mind extending the framework to make it easy for a person who doesn't know Java much to work with....

---

Dbunit looks like a solution for you.

DbUnit can also help you to verify that your database data match an expected set of values.

---

This seems like a use case for DBUnit

---

You may also like to consider FitNesse as an easy to use tool. Although you may have to invest more time behind the scenes creating the test fixtures it will be an easy to use tool for the tester. See http://fitnesse.org/

---

We had a similar situation recently and ultimately went for our own framework. We are basing it on the excellent scala specs library (which can also work with JUnit's runner). The main difference to your case will probably be, that our QA guy has a little programming background and that we write additional more involved test cases within the same framework.

However, to cover you main features, the central idea is to define a domain-specific language for testing your data. This makes it very easy to use for a QA (after the initial overhead for learning how to use the language, what's available for it, etc.).

To more concretely answer your feature points:

1. Scala works extremely well with XML. No parser code required, boilerplate code is reduced to a minimum. Write the XML-Database-Comparator yourself and provide access to it via the DSL, then the QA can simply write a XML fragment to check for in the database.

2. Same as above. You provide the comparator yourself, so it's straightforward to ensure this.

3. Scala works lovely with Java, as it compiles to Java bytecode. You can reuse all your existing Java code for creating the DSL, or even let your test-code access it.

Major advantages for us were that we could reuse the Hibernate datamodel to perform more involved tests on the datamodel, we could still access all our Java code as usual, and the DSL is very easy to read even for non-programmers. (The latter comes in handy, when you try to explain some manager-type what that stuff is actually doing.)