很好的一篇文章,深入说了很多关于测试的东西。
A article from Technoetic
- Posted in Software Dev., Agile by Steve Bate
I recently read a blog entry with criticisms of mock-based testing. The author raised several “issues” with using mocks to support unit testing. I’m commenting here since the author has closed comments on the original blog entry.
Issue 1: Poor integration tests, as everything is being tested in isolation
I’ve had good experience with mock-based testing. However, it’s obvious that mocks will only test classes in isolation. I use both unit tests and integration tests (sometimes called system or acceptance tests) together. The need for integration tests is not an issue for mock-based techniques and is not a good reason to use less mocks. It’s just a different aspect of testing. A more common issue in my experience is that people in the agile community who are new to testing often don’t understand these different aspects of testing and seem to believe that mock-based unit testing and integration testing are mutually exclusive options. The lack of common terminology in the community only worsens the problem. For some people, a “unit” is a class or small group of tightly coupled classes. For others, it’s a large portion of the software product. Most agile developers seem to call every test they write a unit test. It’s become so confusing for some teams that I’ve seen terminology like “integration unit tests” being used to describe testing strategies.
But, back to the topic. Poor integration testing is simply the result of lack of integration tests. Mocks do not cause a lack of integration tests. A team makes that choice, probably based on a weak understanding of the tradeoffs between isolation (unit) and integration (system) testing.
Issue 2: Mocks add complexity to the software design.
“I’ve seen numerous occasions where the introduction of mocks has added a large amount of complexity to an otherwise simple design. This complexity leads to higher implementation costs, a higher cognitive load on the developers working on the system, and higher maintenance costs (as there’s more code to maintain). “
The author appears to focused on the increased use of interfaces when using mock-based testing and expresses the opinion that interfaces should only be used where we’d want to be able to replace one implementation with another. First, there are other reasons to use interfaces. In general, interfaces are useful for managing dependencies between software components or subsystems. This can be beneficial even if the implementations do not change (see The Dependency Inversion Principle).
A modular software design will generally make it easier to use mock-based testing without altering the design specifically for the mocks. However, there are times when the software must be modified to support testing. Fortunately, the changes needed to support testing often, if done well, support the modularity goal.
In my experience, extra interfaces don’t add a significant maintenance overhead. Most effort is spent implementing the interface. The time writing the interface itself (or extracting it using an IDE’s refactoring tools) is negligible.
My Conclusions
In almost every case, I see the “simplicity” gained by not using mocks overshadowed by complex test setups to initialize large groups of dependent objects. The dark side of integration testing is that it’s often very slow for large numbers of tests. Some teams are using continuous integration tools like Cruise Control to run their “unit tests” (usually they are actually integration tests). This delays the feedback about broken builds but is often necessary because the tests run so slow. I realize there other reasons for using CC, but this is a common one from what I’ve seen and heard.
I’ve worked on teams where we had thousands of tests that ran in less than 15-20 seconds total on a developer workstation. This was a direct result of heavy use of mock-based testing. We also had a slower suite of integration tests that required 4-5 minutes to run. We didn’t need a continuous integration server because we were able to integrate and run our unit tests before every commit to the source control system. The team integrated 10-20 times/day and broken builds were practically nonexistent over the several years I worked with them. In the very rare cases when the build did break, it was typically fixed in a matter of minutes.
The other benefit of the isolation testing enabled by mocks is the ability to pinpoint problems much more quickly. It’s a form of the divide and conquer problem solving strategy, only the divide part is already done. The conquering is relatively easy compared to tracking down the cause of test failures when many classes are being exercised in a test.
My experience was that our mock based unit tests caught about 98% of the code problems before the code was ever committed to source control. The integration tests caught about another 1% beyond that (almost always because of a flaw in the mock-based testing) and manual testing caught the other 1%.
分享到:
相关推荐
gmall2020-mock-db-2021-11-14.jar
这就是"前端开源库-mock-local-storage"存在的原因。这个库提供了一个模拟的本地存储实现,特别适用于无头单元测试,帮助开发者在测试环境中精确控制数据存储和读取。 Mock-local-storage 是一个专门为前端开发者...
用户行为日志生成脚本
**前端开源库-redux-mock-store** 在前端开发中,Redux是一个非常流行的JavaScript状态管理库,它使得应用的状态管理变得有条理且可预测。然而,当涉及到测试时,特别是对于那些涉及异步操作的动作创建者(action ...
`pytest-mock-2.0.0` 是一个专门针对 `pytest` 测试框架的 `mock` 库的轻量级包装器,旨在简化在 `py.test` 版本2中使用 `mock` 进行单元测试的过程。`mock` 库是 Python 中用于模拟对象的工具,它允许我们在测试中...
`mock-browser`是一个非常有用的开源库,专门针对前端开发者设计,它可以在Node.js环境中模拟一个完整的浏览器环境,包括窗口、文档、位置、导航、本地存储和会话存储等关键功能。这使得开发者能够在服务器端对...
mock-socket, web sockets和 socket.io的Javascript模拟库 的Javascript模拟库, 和 socket.io 安装yarn add mock-socket --dev用法在 node 环境中使用,你可以直接导入或者直接要求文件。 这里选项对于phanto
总的来说,mock-xhr库为前端开发者提供了一种高效且灵活的手段,可以在离线环境中对使用AJAX的代码进行充分的测试,确保代码质量,提高开发效率。通过熟练掌握并应用这个库,开发者可以更好地应对各种复杂的前端应用...
体积小适合小程序的mockjs包,使用方便在页面中require方式引入。mockjs简单易学稳定,国内开发文档全 https://github.com/nuysoft/Mock/wiki
`pytest-mock-1.13.0_testing_python_thin_`这个标题表明我们讨论的是一个与Python测试相关的库,具体来说是`pytest-mock`的一个版本,版本号为1.13.0。`pytest-mock`是针对`py.test`测试框架的一个轻量级包装器,它...
node-mock-server, 基于文件的node REST API 模拟服务器 node-mock-server基于文件的node REST API 模拟服务器 正在启动这里应用程序需要 node 6 或者更高版本。 对于 node ,请使用 node-mock-serv
`pytest-mock-1.12.1_testing_python_thin_`这个标题表明我们讨论的是一个与`pytest-mock`相关的版本,具体是1.12.1版,它的主要目的是为`py.test`(即pytest)提供一个轻量级的`mock`库包装器,以简化Python测试中...
压缩包中包括easy-mock-dev.zip、node-v12.10.0-linux-x64.tar.xz和centos7安装说明。 Centos部署node.js、MongoDB安装、Redis安装、部署easy-mock、导入SwaggerAPI文档
spring-mock-2.0.8.jar
离线安装包,亲测可用
一个简单好用的api-mock工具,模拟后台返回报文,方便前端开发!可注册接口。
Mock-ENB 是一个专为前端开发者设计的开源库,用于模拟后端环境(ENB,即Environment Builder),帮助开发者在没有真实后端服务的情况下进行前端功能的构建和测试。这个库的主要目标是提供一种灵活、高效的方式来...
lws-mock-response 是一个轻量级的前端中间件,它的主要任务是向 Light Weight Server (LWS) 添加模拟响应的能力。LWS 是一个微型的HTTP服务器,通常用于开发和测试环境,因为它启动快速,占用资源少。通过lws-mock-...
**前端开源库 Koa-Mock-Response** 在前端开发中,常常需要与后端API进行交互,但在某些情况下,如单元测试、快速原型设计或离线开发时,直接依赖真实的后端服务可能会带来不便。这就是`Koa-Mock-Response`这个开源...
mock-fs 是个可配置的 mock 文件系统,允许内存和 mock 文件系统短暂支持 Node 的内置 fs module 。这个允许用户对一组 mock 文件进行测试,而不是对一群测试装置。 标签:mockfs