unit-testing - 服务和 DAO 层的 JUNIT 测试

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改善这个问题吗？更新问题，以便可以通过 editing this post 用事实和引文回答问题.

7年前关闭。




Improve this question




我在项目中拥有分层架构，如 Controller -> Service -> DAO。我想为服务层编写 JUnit 测试用例。现在服务层将在内部调用 DAO 方法，为什么我要为 DAO 层编写不同的测试用例，因为它是内部测试的。

有人说我需要使用 mockito 来模拟 DAO 方法。真的需要吗？测试服务层方法时不能直接使用原始代码吗？

Answer 1

为您的服务提供一组测试，并为 DAO 提供一组单独的测试。

DAO 测试应该针对数据库，最好是内存数据库。这不仅是因为在测试中创建和拆除它很容易，而且因为你会知道它是你的，没有其他人会改变它。 DAO 测试将测试您的数据库映射和 SQL 是否正确。您可以使用 DBUnit 用测试数据初始化数据库，并在每次测试结束时验证数据库的内容，这样每个测试都可以针对已知数据集运行。使用单独的 DAO 测试，如果存在数据库级别的问题，这些将更容易区分，因为您将在 DAO 测试中而不是在服务测试中看到它们。

可以使用 DAO 的模拟来测试服务。因为测试不使用数据库，所以它们的执行速度会更快(针对数据库的测试运行速度要慢得多，即使使用内存数据库)，并且您可以在不减慢测试速度的情况下执行许多不同的场景。服务层通常是您的大部分复杂性所在，因此需要更多的测试来覆盖它，如果这些测试可以快速运行，那就更好了。

通常，您拥有带有执行 crud 操作的方法的 DAO，并且这些方法在服务中以不同的方式被一遍又一遍地调用。当您将数据库访问限制为仅 DAO 测试时，您可以最大限度地减少测试所需的数据库访问总量，并且测试运行得更快。

你所说的，有一组测试(服务和 DAO)对数据库的测试，非常诱人，因为 a) 它一直测试真实的东西，b) 看起来它会是更少的工作(而且很多时候项目没有足够的抽象，您无法有效地单独测试事物，并且没有时间分解事物)。许多项目出于合理的原因做出相同的决定，并且它们都直接进入了相同的测试陷阱陷阱，这些测试运行时间过长并且未发现太多案例(因为开发人员在他们现有的测试时不鼓励添加更多测试用例已经花了太长时间)。缓慢的测试会导致糟糕的代码覆盖率和无效的测试。