反映在单元测试中以检查代码覆盖率 [英] Reflection in unit tests for checking code coverage

问题描述

这是场景.我有VO(值对象)或DTO对象，它们只是数据的容器.当我将它们拆分并分开保存到(由于多种原因)不能优雅地映射到VO的数据库中时，我想测试一下是否在数据库中成功创建了每个字段并成功读回重建VO.

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.

有没有一种方法可以测试我的测试覆盖VO中的每个字段?我有一个想法，就是使用反射来迭代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?

我希望在VO中添加字段时此测试失败，并且不记得在测试中添加对其的检查.

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环境: 使用JUnit，Hibernate/Spring和Eclipse

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

推荐答案

保持简单:每个VO/DTO编写一个测试:

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

1. 用测试数据填充VO/DTO
2. 保存
3. (可选:使用纯JDBC检查所有内容是否已正确保存在数据库级别)
4. 加载
5. 检查加载的VO/DTO和原始VO/DTO是否匹配

生产代码将不断发展，并且测试也需要维护.恕我直言，最好的方法是使测试尽可能简单，即使它们是重复的. 过度设计测试或测试框架本身以使测试通用(例如，通过读取具有反射的字段并自动填充VO/DTO)会导致以下问题:

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. 编写测试所花的时间较长
2. 错误可能会在测试中引入
3. 测试维护更加困难，因为它们更加复杂
测试很难发展，例如通用代码可能不适用于与其他类型的VO/DTO稍有不同的新型VO/DTO，稍后将介绍(仅作为示例)
4. 测试不能轻松用作生产代码工作方式的示例

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.

这篇关于反映在单元测试中以检查代码覆盖率的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！