TDD 测试结构问题答案

【问题标题】：TDD Test Structure QuestionTDD 测试结构问题
【发布时间】：2011-09-14 05:27:08
【问题描述】：

假设我在做 TDD，我写了一个这样的测试：

public void testDeposit()
{
    Bank b = new Bank();
    b.deposit(100);
    AssertEquals(100, b.balance);
}

然后我去使测试通过，继续下一个。假设我连续几次这样做，并让存款、取款和摊销都正常工作。

然后说我想编写一个测试来测试某人创建帐户并执行所有操作的组合。这在技术上不是集成测试，而不是单元测试吗？如果是，这是否适合 TDD，或者 TDD 是否应该只包含单元测试。

我主要是因为，如果这个测试失败，很可能其他测试之一应该失败，如果他们没有，我可能只是没有用正确数量的场景测试它们。那么当涉及到 TDD 时，我应该在与单元测试相同的域中进行集成测试，还是应该将它们写在其他地方的另一个类/文件中并单独运行？

【问题讨论】：

【解决方案1】：

集成测试和单元测试之间的界限可能有点模糊；在进行 TDD 时，为了获得功能确认，测试“升级”到集成级别是值得的，但在 TDD 期间进行“全面”集成测试肯定是矫枉过正（请注意那里的全面引用）。

基本上，“判断电话”的一个重要方面正在进行；您的经验应该可以很好地指导在 TDD 模式下停止添加测试的适当级别。

【讨论】：

所以基本上有点像，我在这里测试了一个足够广泛的场景，让我们稍后再扩大，只专注于在做 TDD 之类的事情时添加更多功能？
@slandau：是的，大概就是这样；关键是不要陷入 TDD 过程中过于严格的测试细节中；请记住，这首先是一个开发过程。请记住，没有任何代码，甚至是 TDD 代码，都是没有错误的；这是代码质量和生产力之间的平衡。

【解决方案2】：

我认为高级测试当然可以作为 TDD 工作流程的一部分。例如，测试“由外而内”可能是定义新功能的一种非常有效的方式。从新功能的一些 UI 级别验收测试开始，为需要存在以提供该功能的组件编写集成测试，并编写单元测试来驱动每个组件的实现。

我认为您应该清楚区分您的测试类型，而不是将它们混合在一起，但将它们都包含在您的 TDD 过程中是有意义的。

【讨论】：

这很有意义，但是，您是采用将它们保存在同一个测试文件中并仅按区域（在.net中）分隔它们的方法，还是创建一个单独的文件夹（甚至项目），用于单元/集成/UI测试？
我更喜欢 Rails 约定的测试或规范目录，其中包含每种测试类型的子目录，这些子目录又包含每个测试的类或方面的文件。例如。 'specs/models/foo' 或 'tests/integration/bar'。