1

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

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

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

4

2 回答 2

1

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

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

类 MemoryStore
{
    getEntityById(id)
    {
       // 返回硬编码响应或预设结果
    }
}

类 DatabaseStore
{
    getEntityById
    {
        // 转到真正的数据库并进行读取。
    }
}

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

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

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

于 2013-04-08T09:15:08.550 回答
1

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

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

于 2013-04-08T09:17:45.467 回答