单元测试数据库交互器答案

【问题标题】：Unit testing database interactors单元测试数据库交互器
【发布时间】：2013-04-08 07:50:35
【问题描述】：

我有一个数据库交互组件，其中包括一个 Writer 和一个 Reader 类。 writer类有insertEntity(Entity)、updateEntity(Entity)等write方法，Reader类有getEntityById(EntityId)等方法。

为了实现这个组件，我想像往常一样使用 TDD，但不确定如何管理它。如果我从实现 Writer 开始，如果我还没有 Reader 方法，我将如何进行有意义的断言。即使我有 Reader 方法，我也最好不要在 Writer 的测试中使用它们，尽管这可能是一厢情愿的想法。

测试这样的代码似乎天生就很痛苦，因为需要设置和拆除表格。但是，由于我以前没有尝试过为此类代码执行 TDD，因此我可能会错过一些技巧来使这相对轻松。对此的任何指针表示赞赏。

【问题讨论】：

标签： database unit-testing testing tdd

【解决方案1】：

只要你有一个抽象，你就不需要数据库。

例如，如果我创建了一个方法getEntityById，我可以有一个使用内存存储（数组、散列等）的类。虽然我的生产代码将使用具体实例。在伪代码中：

类 MemoryStore { getEntityById(id) { // 返回硬编码响应或预设结果 } } 类 DatabaseStore { getEntityById { // 转到真正的数据库并进行读取。 } }

然后您可以编写测试，而无需访问真正的数据库。请记住，如果您确实使用了第三方服务、API、数据库、文件系统等……您不是在进行单元测试。

这里的另一个好处是，您可以让另一个开发人员处理数据库访问代码，而您可以处理应用程序的其余部分。这一切都依赖于“对接口进行编码”。

如果你想测试数据库访问代码怎么办？那么你会想要一个综合测试。这里将使用一个真实的数据库，您可以实例化读取/写入数据库的代码。自然这会很慢并且需要种子数据。关键是你测试这些独立的，你的应用程序的其余部分将使用内存中的假货。所以在上面的例子中，只要 DatabaseStore 自己工作，我们就可以确信其余的代码做了正确的事情。

【讨论】：

【解决方案2】：

我要做的是首先实现我的 CREATE 方法，然后通过直接查询数据库而不是通过我的 DAO 的 READ 方法不来测试这些方法。当这些通过后，您可以使用您的 CREATE 方法编写您的 READ 测试，用测试数据填充您的数据库，然后实现您的 READ 方法。

就每次测试后设置和拆除数据库而言，将用于执行此操作的 SQL 放置在您的设置和拆除方法中。

【讨论】：