如何在Mocha单元测试中使用Sinon正确Stub request-promise？

嗨，我来帮你解决这个单元测试的困扰！当请求调用被嵌套在handleMessage和updateStatus这类函数内部时，确实会让测试变得棘手，但咱们有几种实用的方案，具体取决于你使用的编程语言和测试框架，下面我给你拆解常见的解决思路和例子：

方法1：依赖注入（最推荐的方式） #

如果可以修改原函数的代码，依赖注入是最干净的解决方案——把request模块/客户端作为参数传入函数，而不是在函数内部直接引入。这样测试时你就能轻松传入一个Stubbed的版本，完全隔离真实请求。

举个JavaScript的例子：

重构前的代码 #

// 原updateStatus函数，内部直接硬编码引入request
function updateStatus() {
  const request = require('request');
  request.post('/api/update-status', (err, res) => {
    // 业务逻辑处理
  });
}

重构后的代码（支持依赖注入） #

// 把request作为参数传入，保留默认值不影响生产代码的原有行为
function updateStatus(request = require('request')) {
  request.post('/api/update-status', (err, res) => {
    // 业务逻辑处理
  });
}

测试时的Stub写法（用Sinon为例） #

const sinon = require('sinon');
const myModule = require('./my-module');

test('updateStatus 应该正确调用请求接口', () => {
  // 创建一个Stub的request.post方法，模拟成功响应
  const mockRequest = {
    post: sinon.stub().callsFake((url, callback) => {
      callback(null, { statusCode: 200 });
    })
  };

  // 传入Stub的request执行函数
  myModule.updateStatus(mockRequest);

  // 断言请求是否被传入正确的URL调用
  sinon.assert.calledWith(mockRequest.post, '/api/update-status');
});

方法2：替换全局/模块级别的依赖 #

如果暂时不能重构原代码，可以通过测试框架提供的工具，直接替换函数内部依赖的模块。比如Node.js里的sinon.stub、Python里的unittest.mock.patch，都是这类场景的常用工具。

Python例子（用unittest.mock） #

from unittest.mock import patch, Mock
import my_module

def test_update_status():
    # 替换my_module内部导入的requests.post方法
    with patch('my_module.requests.post') as mock_post:
        # 模拟请求返回的响应对象
        mock_response = Mock()
        mock_response.status_code = 200
        mock_post.return_value = mock_response

        # 调用要测试的函数
        my_module.update_status()

        # 断言请求是否被正确触发
        mock_post.assert_called_once_with('/api/update-status')

Node.js例子（直接Stub模块） #

const sinon = require('sinon');
const request = require('request');
const myModule = require('./my-module');

test('updateStatus 应该调用正确的接口', () => {
    // Stub request.post方法，模拟异步回调
    const postStub = sinon.stub(request, 'post').callsFake((url, callback) => {
        callback(null, { statusCode: 200 });
    });

    // 执行待测试函数
    myModule.updateStatus();

    // 断言请求URL是否正确
    sinon.assert.calledWith(postStub, '/api/update-status');

    // 恢复原方法，避免影响其他测试用例
    postStub.restore();
});

方法3：封装请求为独立服务 #

如果你的项目比较复杂，建议把所有请求逻辑封装成一个独立的服务类（比如ApiClient），然后在handleMessage和updateStatus里调用这个服务。测试时只需Stub这个服务类的方法即可，不用直接操作底层的request模块，代码耦合度也会更低。

示例（Java/Spring风格） #

// 封装的ApiClient服务，统一处理请求逻辑
public class ApiClient {
    public void postStatus(String url, Callback callback) {
        // 实际request调用逻辑
    }
}

// 原函数通过构造函数注入ApiClient依赖
public class MessageHandler {
    private ApiClient apiClient;

    public MessageHandler(ApiClient apiClient) {
        this.apiClient = apiClient;
    }

    public void updateStatus() {
        apiClient.postStatus("/api/update-status", (err, res) -> {
            // 业务逻辑处理
        });
    }
}

测试时Stub ApiClient #

import org.junit.Test;
import org.mockito.Mock;
import org.mockito.junit.MockitoJUnitRunner;

@RunWith(MockitoJUnitRunner.class)
public class MessageHandlerTest {
    @Mock
    private ApiClient mockApiClient;

    @Test
    public void updateStatus_shouldCallApiClient() {
        MessageHandler handler = new MessageHandler(mockApiClient);
        handler.updateStatus();

        // 断言ApiClient的方法被传入正确参数调用
        Mockito.verify(mockApiClient).postStatus("/api/update-status", any(Callback.class));
    }
}

总结 #

• 如果能修改代码，优先用依赖注入，让测试更灵活且符合SOLID原则；
• 不能改代码时，用测试框架的模块替换工具直接Stub依赖；
• 复杂项目推荐封装请求服务，降低耦合度的同时也让测试逻辑更清晰。

内容的提问来源于stack exchange，提问作者Shamoon