测试数据访问持久方法
只是想知道是否有人对如何测试数据访问方法有任何想法。 我发现测试检索数据访问方法要容易得多，因为我只需模拟 ExecuteReader 并返回填充的 dataTable.CreateDataReader() 即可。 通过这样做，我可以测试返回结果集时我的对象是否正确填充。
但我如何将其转换为我的持久方法（即添加、更新、删除等）。 我想测试的是它是否正确填充命令参数等。
有什么想法吗？ 干杯
Just wondering if anyone has any ideas on how to test ones data access methods. I have found testing retrieval data access methods is much easier because i can just mock out the ExecuteReader and return a populated dataTable.CreateDataReader(). By doing this I can test to see if my object is populating correctly if a result set is returned.
But how do i translate this to my persist methods (i.e. add, update, delete, etc). What i want to test is whether it populates the command parameters correctly, etc.
Any ideas?
Cheers
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
嘲笑是要走的路。 使用 Moq 之类的东西，您可以为您的数据访问提供模拟连接（例如 IDbConnection）类并测试连接创建的命令是否正确设置了其参数。
我不久前写了一篇博客文章（请参阅此处）描述了一种模拟连续调用 IDbCommand.CreateParameter 的方法。 设置模拟参数后，您可以验证它们的 Value 和 ParameterName 属性是否已设置。
Mocking is the way to go. With something like Moq you can supply a mocked connection (eg an IDbConnection) to your data access class and test whether the command created by the connection had its parameters correctly set.
I wrote a blog post a while back (see here) which describes a way to mock successive calls to IDbCommand.CreateParameter. Once you've set up your mocked parameters you can verify that their Value and ParameterName properties were set.
我们使用内存数据库（hsql）进行单元测试。 设置启动一个事务，而拆卸则将其回滚。 然后您始终知道单元测试中数据库的状态。
We use an in-memory db (hsql) for our unit tests. The setup starts a transaction and the teardown rolls it back. Then you always know the state of the db in your unit tests.
对于我们的 o/r 映射器框架 LLBLGen Pro，我们使用专门的数据库进行测试，并为每组功能使用不同的测试项目。 因此，我们有一个用于插入/更新的特殊数据库，一个用于测试继承相关操作的特殊数据库，一个用于大集的特殊数据库，一个用于获取的特殊数据库。 最重要的是，我们将不同项目中的单元测试分开：面向获取、面向 linq 提供者、面向插入/更新/删除、面向内存内容等。
这样，测试是可维护的并且不会互相影响。 有了特殊的数据库，我们就知道会发生什么以及该做什么。
当然，这还取决于您对持久性逻辑测试的含义：如果您想像我们一样测试框架级例程，那么模拟实际上并不是那么有用：您想测试场景中的真实情况，其中涵盖大多数（如果不是全部）情况。 如果您真的在谈论测试使用框架级代码（例如存储库代码）的代码，那么模拟可以提供帮助，只要所使用的框架当然没有错误。 :)
For our o/r mapper framework LLBLGen Pro we use specialized databases for the tests, and different test projects per group of features. So we have a special database for inserts/updates for example, a special database for testing inheritance related actions, a special database for huge sets, a special database for fetching. On top of that, we have separated the unit tests in different projects: fetching oriented, linq provider oriented, insert/update/delete oriented, in-memory stuff oriented, etc.
This way, the tests are maintainable and don't influence eachother. With the special databases, we know what to expect and what to do.
It also depends on what you mean with persistence logic tests of course: if you want to tests the framework-level routines like we do, then mocking is something which is really not that useful: you want to test the real deal in scenario's which cover most, if not all, cases. If you're really talking about testing your code which utilizes framework-level code (e.g. your repository code), then mocking can help, as long as the framework utilized is of course error free. :)