单元测试:简单和硬第一策略

Question

我从没写过单元测试。

我正在读Osherove的单元测试艺术，他解释了一种在为遗留代码编写测试时选择从哪里开始的方法。基本上，您最终需要编写两种类型的测试: easy (对于依赖项较少的组件)和hard (针对具有许多依赖项的组件)。

然后，他说，从困难的部分开始，您必须更有经验，但它允许您重构并使系统的大部分可测试，从而使以后的工作更容易。

但这不是真的吗？我的意思是，如果你从简单的测试开始，你不应该让困难的测试变得更容易吗？

Answer 1

首先进行简单的测试，如果只是因为当您开始编写硬测试时，您将能够进行一些回归，以确保您的重构不会破坏任何东西。

根据您的问题:不应该是这样的，除非系统是难以置信的高度耦合。简单的测试不应该强迫重构使更难的测试变得更容易。结果可能是这样，但您的代码应该尽可能正交，从而使您的测试与正交测试一样。

您可以为您的集成测试提供更强大的支持。

Answer 2

首先，我会从简单的单元测试开始，以获得编写它们的经验。确保您的测试是彻底的，并且您正在测试您所测试的类/方法的所有输入组合中可以想到的所有用例。从编写更难的测试开始，可能根本不鼓励您进行单元测试。

Answer 3

如果你从简单的测试开始，你不应该让困难的测试变得更容易吗？

伯纳德说：“在实现了更简单的测试之后，硬测试就会变得简单一些，因为您可以获得经验。”

然而，硬测试的困难在于，非tdd开发的模块通常是紧密耦合的，并且几乎不可能隔离地测试功能。

我的建议是：

• 做一些简单的测试来获得经验。
• 为硬案例创建集成测试。
• 只要您是tdd新手，就不要为困难的案例创建单元测试。
• 对新特性进行测试驱动开发，以获得如何使用松散耦合功能实现的经验。