Recording test data in Hibernate

Question

I have an automated test framework for testing hardware widgets. Right now only pass/fail results of test cases are stored into a relational database using hibernate. I'd like to change this so that various characteristics of the test are stored in the database. (e.g. how many gerbils are running inside the widget, the inputs to various assertions in the tests, etc.).

Each test case is represented as a Java class, so the first thing I thought of was using hibernate to just create a table for each test case. However, we have lots and lots of test cases so I don't think that having a table for each test case is necessarily the best idea.

The amount and type of data for specific test cases will not change on different executions of the test case, but the data needed for each test case will be dramatically different. To use a silly example: for the gerbil-gnawing test we always want to record the age and color of the gerbils gnawing at the wires, but for the smash test we only need to record how many rocks were thrown at the widget.

Ideally we would be able to query this information from the database using SQL so the data can't be stored as binary blobs or other un-queryable entities.

Any ideas on how to structure the database to meet these requirements? Am I totally off-base on not wanting a large number of tables?

Answer 1

I would not worry about a lot of tables. If that is the correct schema, then that's what it is. DB's are designed to handle it.

Answer 2

I'd say you have two major options:

Make your TestCase classes supclasses of a common superclass and then use one of the inheritance mapping strategies (http://hibernate.org/hib_docs/reference/en/html/inheritance.html) don't worry to much about the number of tables/columns but of cause you should ensure that you do not hit a limit of your database engine.

Or you do a EAV model (http://en.wikipedia.org/wiki/Entity-Attribute-Value_model) It is extremely flexible, but be aware that it causes extremely complex queries for simple questions.

Make sure that you run tests with realistic volumes before commiting to one or the other.