Testing a dataset returned from a database

Question

If I am testing a database rowset, what would be the criteria to test against?

Should I test that a row exists with a name of A, etc etc (What's in the database)? Is this a bad idea? This sort of test is fragile as the data can change but the query can be correct.

With that in mind, would it be better to check the column names I have returned in the dataset? Like so (http://stackoverflow.com/questions/696782/retrieve-column-names-from-java-sql-resultset).

Thanks

Answer 1

Testing what's in the database is pointless unless it is data static reference data tables (and you can often make these read only, so again pointless).

Testing columns names? Why would these change? Hopefully developers are not making changes against the production server?

What you probably want, is as part of your CI build process to fully deploy your databases (applying all incremental change scripts [you have those right?]) to a test server.

Answer 2

You don't need to test anything about the database except that the database and the code work.

So then, using a database that you have created in your test environment, connect the code that uses the database to it, and test that it does whatever it is supposed to.

Remember that in a test, it is very rare that you need to check how something is done, but rather you should be testing that dome thing does in fact get done.

For example, if you are using hibernate to persist your entities, you might have a test called canRoundTripAFooBar that saves a foobar, loads it back again, and compares each field to make sure the one you loaded and the one that you saved are the same (except for those bit that should not be the same, like Ids or something)

Answer 3

Don't test what's in the database. Just provide some examples of how your system delivers value.

If the value is genuinely in the database - for instance, another service uses that data - then describe the things your system provides in terms of that value. For instance:

• My system can save a user with his family of four children and a spouse in another country.
• My system can handle Japanese addresses.
• My system can provide historical price data.

If you really have to, you can then associate big chunks of data - rather than individual rows - with the domain concepts to which they match. Removing some of the duplication - putting it in custom test queries, for instance - will help to keep this less brittle.

If you can think of examples of the things your system provides then you can probably cover all the data it provides too.

Another way to make the tests still less brittle is to use your persistence layer or the persistence layer of the system you're serving (Hibernate, for instance) to translate the data back into domain objects which make more sense for these examples.

This will also help you check that the data you're providing is actually valuable, rather than simply there . If it's your own system you're providing value to, you can do this and retain complete freedom where the format used to store the data is concerned. You can also do things like:

• My system does not allow me to store children without a parent.
• My system does not allow addresses with more than 150 characters in a line.

and check for database exceptions - also allowing you to verify constraints.