测试数据库存在TDD

我知道在单元测试中打击数据库通常是不好的做法，除非特殊情况。

我正在采用TDD方法来使用EF的MVC项目。我的第一个测试是：

void DatabaseShouldExist() { ... }

我想知道...这是一个特殊的情况？

我想检查EF生成的数据库，我的下一个测试将检查它是否包含正确的种子数据。

你会如何去测试这个？

它应该被测试吗？

嘲笑框架。 NSubstitute。 – Karolis

我不同意。如果你正在测试一个DAO，除了命中数据库之外别无他法。一旦完成，那么依赖于DAO的类可以依赖于mock。我不会写测试来查看数据库是否存在。我会先假设它。 – duffymo

*整合测试*完全不是坏习惯。唯一的问题是，它与“单元”测试不同，但它非常有用。此外，我完全同意@duffymo。如果数据库没有创建，你会注意到它，不用担心。 –

你想测试行为，所以不是如果数据库存在或不存在它自己。如评论中所建议的，从商业逻辑开始。 TDD开始小并且是迭代的，不潜入DB逻辑测试1.

简单的例子（对于一个应用程序中存储的电影）

Test 1 - shouldAddAMoveToList() 
Test 2 - shouldBeAbleToRetrieveAMovieFromList() 
Test 3 - shouldPersistAMovieBeweenSessions() // Could Be DB here

当使用TDD，挑第一简单的东西。数据库部分应该稍后进场。

就我个人而言，我会避免使用单元测试对数据库进行测试，并将其保存为集成测试。 DAO模式对此很有用，因为你可以坚持记忆，或者在单元测试中简单地模拟DB端。

单元测试应该尽量坚持FIRST principle，引入数据库可以减缓测试，并防止他们是独立的（除非清除DB每次） - 在最起码尝试使用内存数据库单元测试

2016-05-17 20:41:44 MikeJ

对不起DAO模式是什么？ –

数据访问对象 - 请参阅此链接。 http://www.tutorialspoint.com/design_pattern/data_access_object_pattern.htm – MikeJ

感谢Mike。我正在使用实体框架进行数据访问。它使用POCO，所以在这个意义上，嘲笑仓库似乎是明智的。 –

回答