【问题标题】:Unit testing of communication-classes通信类的单元测试
【发布时间】:2016-03-08 07:45:27
【问题描述】:

我有一个类用于处理与外部系统的连接。 该类有一些公共方法,比方说:

  • 关闭()
  • 配置()
  • 发送()
  • 连接()

还有一些私有方法。 该类旨在隐藏内部工作中的大部分重新建立、失败检查和连接处理。

现在,我得到了一个代码覆盖错误,因为除了配置方法之外,这个类没有单元测试。

  • 除了大量的模拟之外,还有其他方法可以为此类类编写单元测试吗?
  • 如果是这样,这不是一个很好的证明,应该在集成测试或系统测试级别而不是单元测试上测试该类吗?通信类属于单元测试还是系统测试?

【问题讨论】:

  • 我同意你的第二点。恕我直言,此类类不适合单元测试,并且是单元测试覆盖率异常的候选者。当然,您可以模拟所有内容,但是单元测试将毫无价值,因为它只是测试您的模拟功能。
  • 我认为你必须模拟,因为如果它连接你的代码被部分使用,你将不得不断开并重新连接你的计算机才能进入你的代码,这并不容易。如果没有网络“故障”,您的代码的一小部分将被测试。

标签: java unit-testing


【解决方案1】:

只要你不能在单元测试中本地实例化外部系统,这个任务就是经典的集成或系统测试。所以通信类,通常不属于单元测试。
此类课程的覆盖率较低,表明存在 否则需要对其进行测试。

进一步的覆盖率报告,例如在 SonarCube 中可以(希望)被过滤。 可以与负责人(例如软件架构师)一起定义异常过滤器。
将所有此类通信类移动到它自己的包中可能会有所帮助。 甚至到它自己的项目或jar文件。对于那个项目,覆盖范围将不会被执行。

有时构建一个虚拟的外部系统来使用是有意义的。 如果外部系统还在开发中,并且当它每天更改其接口时,您可能会在使用外部系统时浪费很多时间。 在这种情况下,可以使用虚拟系统,它也可以从单元测试中实例化。

【讨论】:

    【解决方案2】:

    这取决于类中的代码量。如果它只是配置另一个服务(如套接字或数据库驱动程序),则单元测试没有意义,因为可能已经有人测试了实际的服务。

    如果代码非常复杂(错误处理、数据转换),你应该为这部分代码编写单元测试并模拟服务。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2010-09-09
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2013-08-26
      相关资源
      最近更新 更多