如何对非功能代码进行单元测试？

Question

在我看来，有些代码比其他代码更容易进行单元测试。我喜欢为高功能代码编写单元测试(这里，我指的是主要对其参数进行操作并返回计算结果的函数)。

但是，当代码更多地关注它的副作用时，测试它就会变得更加困难。例如，我在工作中使用的一个socket类有一个方法，声明如下：

void Socket::Create( void );

它不接受参数，也不返回任何结果。出错时抛出，但底层调用(socket())的直接结果被类本身隐藏。

有没有人可以推荐一些技术，或者是一本书，或者一个网站，来学习更高级的单元测试技术，这些技术主要是关于代码的副作用？

Answer 1

我将抛出这一点，但我不认为它会对您的特定示例有所帮助。有一个称为依赖注入或控制反转的通用概念，它允许您从业务逻辑中去除基础架构依赖项。因此，假设您有一个名为SubmitLoanApplication的例程，它执行验证、执行业务逻辑，并最终将数据提交给数据库。对此运行单元测试很困难-但使用IoC，您可以针对接口编写业务逻辑代码，并传入该接口的一个实例，业务逻辑最终在该实例上运行。在您的生产代码中-该实例连接到数据库。在您的单元测试代码中-该实例是静态的，并且您的调用返回可预测的结果。

Answer 2

我的观点是，你不应该关心它做了什么，只关心它是有效的。因此，您不需要测试该方法，只需确保您尝试执行的底层操作成功即可。如果是，那么一切都很好，如果不是，那么你需要修复一些东西。这是可以测试的。

我的观点可能与"TDD“不一致，所以就当它是值得的吧。

Answer 3

我不确定您是想测试Socket::Create( void )方法，还是测试调用此方法的代码。在第一种情况下，您希望为现有功能编写测试。所以你可能想读一读...

http://www.objectmentor.com/resources/articles/WorkingEffectivelyWithLegacyCode.pdf

或者最好是这本书..。

http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052

在第二种情况下，您需要一个Test Double (我们曾经被允许将其称为mock…)用于基础调用。你看..。

http://xunitpatterns.com/

这两本书都解决了你提到的那种问题。简而言之，解决方案是以这样一种方式划分问题，即大多数功能都很容易测试，只有尽可能少的功能不能测试。