Question

我需要像这样的测试服务方法吗？

@Transactional
@Override
public Charge saveAndFlush(Charge charge) {
    return chargesRepository.saveAndFlush(charge);
}

原则上，没有要测试的东西。因此，出现了一个问题-无论如何都要编写测试，因为将来可能有人会在此处添加逻辑。或者让他写一个会添加逻辑的人（如果有的话）。

Answer 1

通常来说，您将单元测试的重点放在通过执行一些计算或处理来返回值的代码上。
您可以对不返回任何值的方法进行单元测试，以确保它在执行所有可能的路径时不会运行异常而通过。
在上述情况下，我相信您不应该为此编写测试。该方法实际上没有逻辑，您需要对spring框架进行单元测试。弹簧框架已经具有大量的单元测试，因此没有必要。
请注意，单元测试应该运行得很快并且必须独立运行，也就是说，单元测试不能依赖于数据库或网络连接。因此，这是不进行单元测试的另一个原因，因为您将依赖数据库来验证代码是否有效。

Answer 2

没有要测试的东西

嗯，有。因为不进行测试就无法区分正确的实现和以下错误的“实现”：

{
   return null;
}

{
   return chargesRepository.saveAndFlush(null);
}

{
   return chargesRepository.saveAndFlush(new Charge());
}

{
   return chargesRepository.someOtherMethod(charge);
}

但是您认为有多少要测试是正确的。假设chargesRepository的类已经过正确的测试，则只需要进行一两个单元测试就可以证明该方法正确地委托给chargesRepository。

Answer 3

我找到了类似问题的答案：

肯特·贝克的经验法则：

测试所有可能破坏的内容。当然，这在某种程度上是主观的。对我来说，像您上面这样的琐碎的吸气器/装卸器和单缸吸油器通常不值得。但是话又说回来，我大部分时间都在为遗留代码编写单元测试，只是梦见一个不错的未开发TDD项目...在这些项目上，规则是不同的。对于遗留代码，主要目标是以尽可能少的努力覆盖尽可能多的领域，因此，单元测试往往是更高层次且更复杂的，更像是集成测试（如果人们对术语学得很熟）。而且，当您要使整体代码覆盖率从0％上升到200％或设法将其提高到25％以上时，单元测试的getter和setter方法是您最少的担心。

在未开发的TDD项目中的OTOH，即使对于这种方法，编写测试也可能更为实际。特别是在您已经开始编写测试之前，您有机会开始怀疑“这一行值得进行专门的测试吗？”。而且至少这些测试编写起来微不足道，而且运行起来很快，因此这两种方法都没什么大不了的。

Answer 4

您为什么要编写测试？拥有更轻松的生活。不要狂热，要务实。

费用是多少？

花在编写上的时间，每个开发人员永远在每次执行上所花费的时间，更多的代码，在维护上花费的时间，代码重复（我希望您对数据库进行集成测试）

价值是什么？

检查方法A是否直接委托给B？在这种情况下，也许您根本不需要A
检查事务是否挂起或数据库操作是否正确？您需要为此进行集成测试
检查方法中是否还没有做其他事情？您将需要为此进行突变测试

因此很难在此测试中看到真正的价值。另外：您希望此代码经常更改吗？如果失败（10分钟修复/夜间致电/ 1M $损失/飞机失事）会真的很糟糕吗？如果答案为“否”，那么成本远大于价值

但是...

如果这在您的应用程序和其他开发人员中被广泛使用，并且经常由于误解而删除@Transactional？添加测试！通过反射检查注释是否存在
是否非常关键的方法？做突变测试，检查委托是否完成，检查参数是否未更改
是否期望此方法会经常更改并引起很多麻烦？添加测试以检查基本属性是否保留（事务和委派）

因此，请尽可能轻松地生活。视您的情况而定，无论是否进行测试，都会更容易

Answer 5

此方法存在的主要原因是交易注释和对费用存储库的副作用。这也是最有可能/唯一无法正常工作的事情。这是您通过集成测试发现的。单元测试完全没有意义，因为您可以模拟存储并忽略注释。因此，基本上，您是在进行模拟的随机调用的单元测试。令人惊讶的是，它通常可以按您希望的那样工作。

因此，请确保仅使用一些良好的集成/方案测试来涵盖所有相关的存储库方法（即，不要为每个方法编写一个，而是将它们组合到实际方案中）。焦点单元测试具有算法复杂性的事物，这些事物具有多于一行的代码或任何种类的分支。这样，当您使用实际的业务逻辑对服务类进行单元测试时，您可能会模拟DAO类，这可能会带来真正的错误，因为您已经知道DAO具有集成测试所需的副作用。

Answer 6

我个人暂时不为此服务方法编写测试。无论如何，您都需要为MVC零件编写测试。检查端点：

返回JSON / XML /任何内容
接受并解析HTTP参数
不访问惰性字段
将逻辑传播到正确的服务并启动ORM会话和事务

端点将调用此服务并进行隐式测试。

稍后，当您向该服务添加更多逻辑时，您也可以添加服务层测试（编写许多MVC测试更加困难和缓慢）。我不会将它们写为 unit 测试（请参见下面的文章）。

P.S，在那里我可以了解到什么以及如何进行测试？ ...我仍然没有找到如何测试的实际示例以及比hello world更难测试的示例

希望这些会有所帮助：

是否需要为没有逻辑的服务方法编写单元测试？

6 个答案: