在 BDD 测试用例中使用模拟是否明智？
我们将使用 BDD 实现一个小型 Java 应用程序，该应用程序使用 apache.org 的 POI 读取 MS excel 工作表，并根据该 excel 将一些文本打印到 STDOUT。我们一致认为，最简单的解决方案是为每个 BDD 测试用例创建一个 test.xls。
还有另一个想法，那就是我们应该模拟 POI 库的调用和测试的期望。这个想法背后的原因是我们不想测试 POI，并浪费测试时间在每个测试用例中使用它。此外，文件访问在不同的操作系统上可能会很棘手。
在这种情况下使用模拟是否明智？
We are going to implement a small java application with BDD, which reads an MS excel sheet using POI of apache.org and prints some text based on that excel to the STDOUT. We agreed that the simplest solution would be to create a test.xls for each BDD test case.
There was another idea, which is that we should mock the POI library calls and expectations for testing. The reasoning behind this idea is that we don't want to test the POI, and waste test time on using it in every test case. Additionally file access can be tricky on different operating systems.
Is it wise to use mocking in such cases?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
定义你嘲笑的地方和你不嘲笑的地方的限制绝对是灰色的，但是我认为有两个关于嘲笑的一般性陈述提供了指导：
因此，尽管有时您想要模拟一个子系统，因为它很慢，但正确的模拟是将慢速系统识别为需要架构分离的东西，因此您将开发正确表示您与该慢速系统交互的接口，并模拟其行为那里。然后，您将进行另一类测试，用于测试那些实际与慢速资源交互的接口的实现，以确保代码正常工作。
就这如何应用于 POI 而言，可能有也可能没有充分的理由来模拟 POI 的抽象。这取决于项目的范围。对我来说，如果我觉得该项目从长远来看可能需要不同的电子表格解决方案，我就会这样做。
我当然不会模拟实际的 POI 类，因为上面的第一个链接非常清楚地表明这种方法会带来多少痛苦。
Defining the limit of where you mock and where you don't is definitely gray, however I think there are two general statements about mocking that offer guidance:
So although there are certainly times when you want mock a subsystem because it is slow, proper mocking is identifying that slow system as something that needs architectural separation, so you would develop interfaces that properly represent your interaction with that slow system, and mock the behavior there. Then you would have another category of tests that test implementations of those interfaces that actually interact with the slow resources to make sure that that code works.
In terms of how this applies to POI, there may or may not be good justification to mock out an abstraction to POI. It depends on the scope of the project. To me, I would do it if I felt the project may need a different spreadsheet solution over the long haul.
I would certainly not mock out the actual POI classes, as the first link above makes abundantly clear how much pain can be involved in that approach.
我从来都不热衷于嘲笑，但在某些情况下它确实有意义。
我认为 Apache POI 足够稳定，您可以正确地将其删除。重要的是要问的是，您是否正在测试与 POI 的交互？如果是的话，那么你就无法嘲笑它。
既然你说你不测试与 POI 的交互，那就继续吧。
I've never been a big fan of mocking but it does make sense in some instances.
I think Apache POI is stable enough and you can properly stub it out. The important thing to ask is if you are testing interaction with POI? If you are, then you can't mock it out.
Since you say you not testing interaction with POI then go ahead.