我该怎么做正确的TDD？我何时为比业务逻辑层更深的层（即DAL）编写测试？

Question

我仍然不确定在从外向内进行开发时如何最好地使用Mocks（即首先模拟客户需求的写测试）

假设我的客户要求是“客户可以取消订单”。

我可以为此编写测试 - Test_Customer_Can_Cancel_Her_Order。

使用TDD然后编写业务类并模拟数据访问层（或比我的业务逻辑层“更深”的任何层）。太棒了，我的测试通过，我只测试业务层而不是下面的任何层。

现在我想知道的是......我什么时候深入研究并开始编写和测试数据访问层？顶级测试后直接？只有在我编写集成测试时？也许没关系？只要它在某个时刻完成了吗？

只是想知道......

Answer 1

这是一个棘手的问题。有些人认为测试“私有”代码是可以的，有些人认为不是。这当然更容易，因为您不必执行复杂的设置来重现应用程序状态，该状态允许您测试要添加的小功能（您可以直接测试该功能）。我曾经是那些人之一，但现在我说最好只测试公共API（创建测试和设置，只做和看到用户可以做什么和看到什么）。这样做的原因是，如果您只测试公共API，那么您将获得无限的重新分解潜力。如果您测试私有代码，如果您选择重新考虑因素（使您不太可能“无情地重构”，从而导致代码错误），则必须更改测试。

但是，我不得不说，只测试公共API 做会导致更复杂的测试框架。

因此，为了更具体地回答您的问题，您的下一步是尝试考虑当前订单取消代码存在问题并编写新的高级设置以重现该问题的情况。您提到了数据访问测试。创建数据库损坏的高级设置，并测试您的应用程序是否正常运行。

哦，如果对于GUI应用程序来说，它有点棘手，因为你真的不想达到测试鼠标点击和读取像素的程度。那太傻了。如果你使用（你应该）MVC系统，请停在控制器级别。

Answer 2

使用集成测试进行查询和其他数据访问测试。

Answer 3

我总是编写测试来测试DAO层，它不测试业务逻辑，但我觉得测试CRUD功能很重要。这让我遇到了很多麻烦，因为如果我的数据库由于某种原因而损坏我的测试很有可能失败。我所做的是防止这些DAO类型测试失败，首先在非生产数据库中进行测试。然后对于每个CRUD / DAO测试我

1. 找到可能在之前的测试中遗留下来的对象，如果存在，我会删除它们。
2. 我创建了我想要测试的对象
3. 我更新了我想要测试的对象
4. 我清理或删除我创建的对象。

这个序列帮助我确保我的数据库处于这样的状态：如果运行两次并且第一次测试在中间停止一半时我的测试不会失败。

另一种方法是将CRUD测试包装在事务中，并在测试结束时回滚事务，以便数据库处于开始状态。