TDD测试结构问题

Question

5

假设我正在进行TDD并编写以下测试：

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

然后我开始让测试通过，继续下一个测试。假设我连续完成了几个测试并且存款、取款和分期付款都正常工作。

接下来，如果我想写一个测试来测试某人创建账户并执行一些组合操作，那么这不是技术上的集成测试而不是单元测试吗？如果是这样，它是否适用于TDD，或者TDD只应该包括单元测试？

主要是因为，如果这个测试失败了，很可能其他测试也会失败，如果它们没有失败，我可能只是没有使用正确数量的场景对它们进行测试。所以，在TDD中，我应该将集成测试放在与单元测试相同的域中，还是应该在另一个类/文件中编写并单独运行？

- slandau

另一种解决方法是采用TDD => 单元测试 => 一次只测试一个对象的一个行为。ATDD => 场景测试 => 一次只测试一个用户场景。 - Gishu

2个回答

2

"集成测试"和"单元测试"之间的界限有些模糊；在进行TDD时，值得测试到"集成"级别，以确认功能，但是在TDD期间建立"全面的"集成测试(注意引号)肯定是过度的。基本上，这里涉及到一个"判断调用"的重要方面；您的经验应该是停止在TDD模式下添加测试的适当水平的良好指南。"

- Paul Sonier

所以基本上就像是，我在这里测试了一个足够广泛的场景，让我们以后变得更加广泛，并专注于在进行TDD的同时添加更多功能？ - slandau

@slandau：是的，大致就是这样；重点不是在TDD过程中陷入过于严格测试的细节中；要记住，首先它是一个开发过程。请记住，没有代码，即使是TDD代码，也是没有缺陷的；这是代码质量和生产力之间的平衡。 - Paul Sonier

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Jonah · Accepted Answer

我认为高层次测试可以作为TDD工作流程的一部分。例如，从“外部到内部”进行测试可以是定义新功能的非常有效的方法。首先通过UI级别的验收测试来测试新功能，编写集成测试以提供该功能所需的组件，并编写单元测试以驱动每个组件的实现。

我认为你应该保持你的测试类型之间的区别清晰，不要将它们混在一起，但将它们全部包含在你的TDD过程中也是有意义的。