每层集成测试是一个好习惯吗？

Question

我有一个使用spring-mvc的应用程序,基本上我们有一个表示层(控制器),服务层(业务单元,帮助器),集成层和数据访问层(jdbc/jpa存储库),我们希望确保使用未来的测试除了代码之外不会破坏以前工作的任何东西,为此我们使用单元测试(mockito)和集成测试(spring-test,spring-test-mvc).

每个类/组件进行单元测试,基本上我们试图对输入输入和这些组件中的可能流程进行良好的覆盖,这个动作工作正常,这里没有疑问,因为单元测试是关于确保单元按预期工作.

集成测试是不同的故事和非常有争议的一个,因为现在我们有时使用相同的场景来设计我们的单元测试但是使用真实平台等可以获得整个系统,但我对这里的最佳实践有疑问.

1. 由于我们有一个控制器,服务,数据层一种方法是每层IT,例如我们有UserService类,我们将有UserServiceTest,它将是Unit测试和UserServiceIT,但是可维护性不理想,我觉得有时我们会重复相同的测试场景,但现在使用真实系统.这种做法真的有意义吗或在哪种情况下这是有道理的？如果我们已经在课堂上有100%的测试覆盖率进行单元测试,为什么我们需要IT来实现这一目标,那么我们认为这只是为了确保真正的组件能够启动？有意义的是拥有所有相同的场景或哪些是一个很好的标准来决定？

2. 其他方法只是通过集成测试来处理最重要的测试用例,而只是来自控制器层,这意味着调用REST服务并验证JSON输出.这够了吗？我们不需要在其他层中验证更多东西吗？我知道调用真正的REST api将在所有层(控制器,服务,dao)下使用,但这已经足够了吗？你会在这里说些什么？

3. 如果我们有一个帮助类我不认为有单位和IT是有意义的,因为大多数方法只有一个目的我觉得单元测试就够了,你觉得相同吗？

4. 数据层中的某些类可以使用Criteria API,QueryDSL用于那些我使用IT的人,因为在某些情况下单元测试非常困难,这是一个有效的理由吗？

我正在努力获得最佳方法,技巧和实践,使确保系统完整性的任务成为真正有价值的过程,同时牢记这些东西的可维护性.

Answer 1

您需要触摸应用程序所需的整个测试策略.测试不仅涉及覆盖范围和层次.例如:

我们希望确保使用测试,未来的代码添加不会破坏以前工作的任何东西,为此,我们使用单元测试(mockito)和集成测试(spring-test,spring-test-mvc).

这就是你实际支持回归测试的方式,这是一种类型.如果我们看一下(详细的)测试金字塔

很容易看出集成测试占了很大比例(建议5-15%).集成是跨层的,但也是跨组件的API.您的业​​务组件自然会存在于同一层中,但您仍需要确保它们彼此之间的工作正常.拥有mSOA将推动您支持如此广泛的接口集成测试.

我同意你的看法

集成测试是不同的故事,非常值得商榷

一些专家甚至建议您只需要保留单元测试和GUI E2E.恕我直言,没有严格的最佳做法 - 只有好的做法.如果您对权衡取舍感到满意,请使用适合您情况的产品.

我觉得有时我们重复相同的测试场景,但现在使用真实的系统.这种做法真的有意义吗或在哪种情况下这是有道理的？如果我们已经在课堂上进行了100%的测试覆盖,并且单元测试为什么我们需要IT来实现这一目标,那么我们认为这只是为了确保真正的组件能够启动吗？有没有理由拥有所有相同的场景或哪个是一个很好的标准来决定？

看起来您需要在这些场景中划一条线.长话短说 - 单元测试和模拟对象自然地结合在一起.组件测试需要一些真实的系统行为,它可用于检查各个单元或子系统组件之间传递的数据的处理 - 如组件/服务DB或非单元级任务的消息传递.

来自控制器层,这意味着调用REST服务并验证JSON输出.这够了吗？我们不需要在其他层中验证更多东西吗？我知道调用真正的REST api将在所有层(控制器,服务,dao)下使用,但这已经足够了吗？

不完全正确 - 测试表示层也会运行底层...所以为什么还要考虑所有其他测试？如果你对这种方法没问题--Selenium团队建议采用这种数据库验证方法.

如果你在这里谈论Beans和ViewHelpers

我们有一个帮助类我不认为有单位和IT有意义,因为大多数方法只有一个目的我觉得单元测试就够了,你觉得一样吗？

你需要单位和IT,因为所有原因都适用于其他组件.有单人的责任并不否认需要测试.

在某些情况下进行单元测试是非常困难的,这是一个有效的理由吗？

所有封装的私有(和静态)类,方法,属性等都是一样的.但是有一种方法可以测试它们 - 比如反射.这当然是针对特殊情况的单元测试遗留代码或您无法更改的API.如果你需要它来代替你自己的代码,那么这种缺乏可测试性可能会导致设计气味.