服务和DAO层的JUNIT测试

Question

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

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

Answer 1

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

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

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

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

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