删除并组合回归测试以加快测试速度是一种不好的做法吗？
我正在开发一个与第三方网络服务集成的应用程序。我目前有单独的集成/回归测试，调用 Web 服务来执行以下操作：
- 修改政策 - 添加车辆
- 修改政策 - 删除车辆
- 修改政策 - 添加多辆车辆
- 修改政策 - 添加被保险人
- ...
大多数这些测试都是作为错误创建的被发现&固定的。第三方网络服务速度很慢，我正在努力加快测试过程。由于每个测试都会调用 Web 服务，因此将它们合并到一个仅调用 Web 服务一次的测试中会使事情变得更快。
因为每个测试都是针对特定错误编写的，所以组合这些测试是否是一种不好的做法？我担心的是，重构中的错误可能会导致稍后重新引入错误。
I'm working on an app that integrates with a 3rd party web service. I currently have separate integration / regression tests that call the web service to do the following:
- Modify Policy - Add Vehicle
- Modify Policy - Remove Vehicle
- Modify Policy - Add Multiple Vehicles
- Modify Policy - Add Insured
- ...
Most of these tests were created as bugs were found & fixed. The 3rd party web service is slooow and I'm trying to speed the testing process up. Because each test calls the web service, combining them into one test that only calls the web service once would make things much faster.
Would combining these tests be bad practice because each test was written for a specific bug? My concern is that a mistake in refactoring could potentially allow a bug to be re-introduced later on.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
是的，将它们结合起来是一种不好的做法。相反，请考虑如何在不组合测试的情况下降低风险。一种方法（可能是您最好的选择）是模拟 Web 服务，以便测试速度更快，而不会损害检测回归的能力。另一种方法是将慢速回归测试分成自己的套件，该套件的运行频率低于通常的测试集（但仍然足够频繁！）。最后，您可以将它们组合起来 - 但我建议明确地将所有原始错误重新引入您的代码中，以验证组合测试是否仍然可以检测到它们。
具体的、有针对性的、直接的、单元测试非常有价值；很高兴确切地知道出了什么问题。组合测试会损害该值。
Yes, combining them would be a bad practice. Think instead about how to mitigate the risk without combining the tests. One approach - probably your best bet - would be to mock out the web service, so that the tests are much faster without jeopardizing their ability to detect a regression. Another would be to split your slow regression tests into their own suite that is run less frequently (but still frequently enough!) than your usual set of tests. Finally, you could combine them - but I would recommend explicitly reintroducing all the original bugs into your code to verify that the combined test still detects them.
Specific, pointed, direct, unit tests are very valuable; it's nice to know exactly what has broken. Combining tests compromises that value.
我不建议将它们组合起来，除非您保留单独运行它们的能力（也许在您的隔夜构建中将它们分开，并在连续构建中组合）。
如果您的测试框架支持的话，请尝试并行化它们（在单独的“策略”上）。
I wouldn't recommend combining them, unless you keep the ability to run them separately (maybe keep them separate in your overnight build, and combined in your continuous build).
Try parallelizing them (on separate 'policies'), if your test framework supports it.
我建议将它们包含在您的夜间构建中，以便当您睡着而不看时钟时它们每天运行一次。并且仅在开发人员时间测试中删除它们。
当然，这是假设他们不会太慢以至于一晚还不够。
仅仅将您的测试合并到一个大测试中可能会使它们毫无用处或更糟。这并不比直接删除它们好多少。
I would suggest including them in your nightly build, so that they do run once a day when you are asleep and not watching the clock. And only removing them your developer time tests.
Of course that assumes they are not soooo sloooow that one night is not enough.
Just combining your tests into one big test is likely to make them useless or worse. Thats's not much better than just deleting them.