Reflection in unit tests for checking code coverage

Question

Here's the scenario. I have VO (Value Objects) or DTO objects that are just containers for data. When I take those and split them apart for saving into a DB that (for lots of reasons) doesn't map to the VO's elegantly, I want to test to see if each field is successfully being created in the database and successfully read back in to rebuild the VO.

Is there a way I can test that my tests cover every field in the VO? I had an idea about using reflection to iterate through the fields of the VO's as part of the solution, but maybe you guys have solved the problem before?

I want this test to fail when I add fields in the VO, and don't remember to add checks for it in my tests.

dev environment: Using JUnit, Hibernate/Spring, and Eclipse

Answer 1

I would recommend cobertura for this task. You will get a complete code coverage report after you run your tests and if you use the cobertura-check ant task you can add checks for the coverage and stop the ant call with the property haltonfailure.

Answer 2

You could make it part of the validation of the VO. If the fields aren't set when you use a getter it can throw an exception.

Answer 3

Keep it simple: write one test per VO/DTO:

1. fill the VO/DTO with test data
2. save it
3. (optional: check everything has been correctly save at the database level, using pure JDBC)
4. load it
5. check that the loaded VO/DTO and the original one matches

Productive code will evolve and tests will need to be maintained as well. Making tests the simplest as possible, even if they are repetitive, is IMHO the best approach. Over-engineering the tests or testing framework itself to make tests generic (e.g. by reading fields with reflection and filling VO/DTO automatically) leads to several problems:

1. time spent to write the test is higher
2. bug might be introduced in the test themselves
3. maintenance of the test is harder because they are more sophisticated
4. tests are harder to evolve, e.g. the generic code will maybe not work for new kinds of VO/DTO that differ slightly from the other and will be introduced later (it's just an example)
5. tests can not be used easily as example of how the productive code works

Test and productive code are very different in nature. In productive code, you try to avoid duplication and maximize reuse. Productive code can be complicated, because it is tested. On the other hand, you should try to have tests as simple as possible, and duplication is ok. If a duplicated portion is broken, the test will fail anyway.

When productive code change, this may require several tests to be trivially changed. With the problem that tests are seen as boring piece of code. But I think that's the way they should be.

If I however got your question wrong, just let me know.