测试用例：使用 Spring beans 模拟数据库
我们的应用程序有一个服务层和一个 DAO 层，编写为 Spring bean。
在测试服务层时 - 我不想依赖真实的数据库，所以我通过为 DAO 层创建一个“模拟”Impl 来模拟它
因此，当我测试服务层时 - 我将服务层 bean 链接到模拟道豆 在生产中 - 将服务层链接到“真正的”DAO bean
这是一个好主意吗？ 关于如何模拟数据库层有什么替代建议吗？
澄清：这个问题是关于测试服务层而不是DAO层。 在测试服务层时，我假设 DAO 层已经经过测试或者不需要测试。 最主要的是 - 我们如何测试服务层 - 不依赖于 DAO 实现 - 因此我嘲笑 DAO 层
Our application has a service layer and a DAO layer, written as Spring beans.
While testing the Service Layer- I do not want to depend upon a real database so I am mocking that by creating a 'Mock' Impl for the DAO layer
So when I am testing the Service layer- I chain the Service layer beans to the Mock DAO beans
And in Production- will chain the Service layer to the 'real' DAO beans
Is that a good idea ?
Any alternate suggestion on how to mock the database layer ?
Clarification:This question is about testing the Service Layer and not the DAO layer.
While testing the service layer- I assume that either the DAO layer has already been tested or doesn't need testing.
The main thing is- how do we test service layer- without being dependent upon the DAO implementation- hence I am mocking the DAO layer
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
这是我们多年来一直使用的技术。 请注意，在模拟 DAO 接口时，您有一些选择：
动态模拟框架允许您消除各种情况（无数据、1 行、多行、异常抛出），而无需创建复杂的类来消除您希望的行为去测试
This is a technique we've been using for many years now. Note that when it comes to mocking the DAO interfaces you have some choices:
Dynamic mocking frameworks allow you to stub out a variety of circumstances (no data, 1 row, many rows, exception throwing) without having to create complex classes to stub out the behavior you wish to test
这是使用模拟来测试数据库的好方法。 我认为没有必要提出任何替代建议； 我认为您已经掌握了正确的技术！
That's a great way to use mocking to test the database. I don't think any alternative suggestion is necessary; I think you've got the right technique already!
您绝对走在正确的道路上。
我选择的模拟框架是 Mockito
You are definitely on the right track.
My mocking framework of choice is Mockito
据我了解，这个问题明确致力于有关测试 DAO 层的最佳实践，因为在测试服务时模拟数据库似乎不像模拟 DAO 层那么简单。
就我个人而言，我会再次提出这个问题，即按照经典单元测试的含义对 DAO 层进行真正的单元测试是否合理。 如果您正确设计 DAO 层，它除了将域对象映射到查询之外不会做更多的事情。
也就是说，我总是建议使用 H2、HSQL 或 Java 6 嵌入式 Derby 等嵌入式数据库来执行此类操作，因为模拟数据源实际上比简单地提高嵌入式数据库要费力得多。 Spring 3 将提供一个很好的构建器模式来动态创建此类数据库。 它的 RC1 还将引入
jdbc命名空间以进一步简化设置。 有关详细信息，请参阅此。但即使当前的 Spring 2.5 分支使用嵌入式数据库，也只需获取数据库 JAR 并相应地设置
DataSource即可。As I understand the question it is explicitly dedicated to best practices regarding testing DAO layers, as mocking a database seems nnot so straightforward as mocking the DAO layer when testing services.
Personally I'd raise the question back if it's reasonable to really unit test a DAO layer in the classical unit testing meaning. If you design your DAO layer properly it does not do much more than mapping domain objects to queries.
That said I alway propose to use an embedded database like H2, HSQL or the Java 6 embedded Derby to do things like this as mocking a datasource is really much more effort than simply raising an embedded database. Spring 3 will provide a nice builder pattern to create such databases on the fly. RC1 of it will also introduce a
jdbcnamespace to ease setup further. See this one for details.But even with current Spring 2.5 branch using an embedded database is just a matter of taking the databases JAR and setting up a
DataSourceaccordingly.