对存储库进行单元测试。 NHibernate
我有基于 NHibernate 的（构造函数 ISessionFactory 注入）通用存储库实现，它存储在 DAL 内。它实现了存储在“域层”中的合约。
我应该使用 SQl CE 测试真实的存储库行为，还是应该重构我的应用程序以支持不可知论（就像 Tim Maccharty 的书中 http://www.wrox.com/WileyCDA/WroxTitle/productCd-0470147563,descCd-authorInfo.html) 工作单元 然后给出我的假实现IUnitOfWorkRepository？
在本地数据库上运行测试以暴露真实存储库实现是一种有效的方法吗？
谢谢！
I've got NHibernate-based (constructor ISessionFactory injection) generic repository implementation which is stored inside DAL. It implements contract which is stored in `Domain Layer'.
Should I test real repository behavior using SQl CE or should I refactor my application to support agnostic-like (like in Tim Maccharty's book http://www.wrox.com/WileyCDA/WroxTitle/productCd-0470147563,descCd-authorInfo.html) Unit of Work and then give my fake implementation of IUnitOfWorkRepository?
Is it a valid approach to run tests on a local database exposing real repository implementation?
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
问题是你正在测试什么以及为什么。这将回答这个问题。
如果：
我想测试第三方工具
也就是说，你正在测试NHibernate是否正在工作（不是一种测试）
我愿意）。然后做任何需要的事情，所以不需要重构。放开自己。
我想测试我的代码如何与第三方工具交互
然后你正在谈论我喜欢称之为交互测试的内容。重构是必需的，因为您对如何使用 Niberate 更感兴趣，而不是它是否有效。
我想测试我的代码
完全抽象的NHibernate。做任何必要的事情......包装？现在回到单元测试。
我想从用户的角度测试我的应用程序
我认为这超出了您谈论的范围。但是您可以使用这个范围来讨论组件。所以……嗯……值得但并不容易。不是单元测试，因此您想要实例化组件/应用程序并像其“用户”一样运行整个过程。我将这些称为“UAT”，通常作为“编码 UAT”来实现。
The issue is what your are testing and why. That will answer the question.
If:
I want to test a third party tool
That is, are you testing if NHibernate is working (not a kind of test
I do). Then do whatever it requires, so refactoring not required. Loose yourself.
I want to test how my code interacts with a thrid party tool
Then you are talking about what I like to call a interaction test. Refactoring is required as your more interested in how your using NHiberate than if it works.
I want to test my code
The abstract NHibernate entirely. Do whatever is necessary ... wrapper? Your now back into unit testing.
I want to test my application from a user point of view
I think this is above the scope your talking. But you can use this scope talking about components. So ... hmmm ... worthwhile but not easy. Not a unit test, so you want to instantiate the component/app and run the whole thing as its 'user' does. I call these 'UATs' and usually implement as 'Coded UATs'.
单元测试是单独测试一个单元。所以，不，如果您要访问数据库，它甚至不是单元测试。
使用模拟接口抽象并测试您的存储库。
A unit test is testing a unit in isolation. So, no, it's not even a unit test if you're going to the database.
Abstract away and test your repositories with mocked up interfaces.
我认为要测试存储库，您需要使用实际场景。否则你没有任何其他地方来测试数据库访问。模拟存储库不是一个好的做法。因为您没有任何需要在存储库中测试的逻辑。我认为您需要编写调用实际存储库的集成测试才能从中受益。
I think to test the repositories you need to use the actual scenario. Otherwise you don't have any other place to test the database access. Mocking the repositories is not a good practice. Because you don't have any logic which is need to test in the repositories. I think you need to write integration tests which is calling actual repositories to have any benefit from it.