单元测试数据库交互器

我有一个数据库交互组件，其中包括一个Writer和一个Reader类。 writer类具有诸如insertEntity（Entity）和updateEntity（Entity）之类的写入方法，而Reader具有诸如getEntityById（EntityId）之类的方法。单元测试数据库交互器

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

测试这样的代码似乎本质上是一个痛苦，因为表需要被设置和撕下来。然而，因为我之前没有尝试过为TDD编写这样的代码，所以我可能会错过一些技巧来使其相对简单。任何指针都赞赏。

来源

2013-04-08 Jeroen De Dauw

只要有适当的抽象，就不需要数据库。

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

 
class MemoryStore 
{ 
    getEntityById(id) 
    { 
     // Return hardcoded response or canned results 
    } 
} 

class DatabaseStore 
{ 
    getEntityById 
    { 
     // Go off to the real database and do reads. 
    } 
}

然后，您可以编写测试，而不会碰到真正的数据库。请记住，如果您使用第三方服务，API，数据库，文件系统等......您不是单元测试。

这里的另一个好处是，您可以让另一位开发人员处理数据库访问代码，同时处理其他应用程序。这一切都依赖于“编码到接口”。

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

来源

2013-04-08 09:15:08 Finglas

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

至于在每次测试后建立并拆除数据库，请将SQL放入您的设置和拆卸方法中。

来源

2013-04-08 09:17:45 mattyB

单元测试数据库交互器

回答

相关问题