Home/ Questions/Q 811719
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-15T01:05:19+00:00

Here’s the scenario. I have VO (Value Objects) or DTO objects that are just

  • 0

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

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0