【问题标题】:Why isn't my Sinon spy function working when called in a promise then clause?为什么我的 Sinon 间谍函数在 promise then 子句中调用时不起作用?
【发布时间】:2016-08-03 18:35:37
【问题描述】:

我正在为基于 Promise 的函数编写测试。具体来说,它是一个 React 组件,我正在测试以确保正确调用 onChange 处理程序。

我的组件如下所示:

class TextInput extends React.Component {
    constructor(props) {
        super(props);

        this.state = {
            value: props.value || '',
        };

        this.onChange = this.onChange.bind(this);
    }

    updateState(values) {
        return new Promise(
            (resolve) => {
                this.setState(values, () => { resolve(this.state); });
            }
        );
    }

    onChange(event) {
        this.updateState({ value: event.target.value })
            // then fire the onChange handler (if necessary)
            //
            .then((state) => {
                if (this.props.onChange) {
                    // console.log(this.props.onChange) shows that this IS a
                    // Sinon spy function
                    this.props.onChange(state.value);
                }
            })

            .catch((err) => { console.log('-----------', err); });
    }

    render() {
        // render the component (omitted to keep this short)
    }
}

我的测试是这样的:

import React from 'react';
import { mount } from 'enzyme';
import chai from 'chai';
import sinon from 'sinon';
import TextInput from '../../../../client/modules/components/TextInput';

const expect = chai.expect;

describe('TextInput component editing', () => {

    it('calls the onChange handler', () => {

        const onchange = sinon.spy();

        const value = '';
        const editedValue = 'something';

        const component = mount(<TextInput value={value} onChange={onchange} />);

        // change the value
        //
        component.find('input').simulate('change', {
            target: { value: editedValue }
        });

        expect(component.find('input').prop('value')).to.equal(editedValue);

        expect(onchange.calledOnce).to.equal(true);
        expect(onchange.calledWith(editedValue)).to.equal(true);
    });
});

最后两次 expect 调用测试失败。

如果我用一个普通的旧函数替换 sinon spy,就会调用该函数。例如,

// instead of this...
// const onchange = sinon.spy();

// do this...
const onchange = (value) => { console.log(`VALUE = ${value}`); };

如果我直接使用 setState 方法的回调,它可以工作。例如,

// instead of...
// this.updateState(values).then(...)

// do this...
this.setState(values, () => {
    // call the onChange handler...
});

我可以这样做,但我想避免它,因为我要为这个组件添加更多功能,我不想被困在pyramid of doom 中。

起初我认为这可能与updateState 方法范围内的this 问题或该方法中的一个回调函数有关,但在整个过程中添加console.log 语句表明@987654332 @ 在所有适当的地方指代TextInput 的实例。

onChange 处理程序被触发之前添加一个console.log 语句来转储它表明this.props.onChange 实际上是一个Sinon 间谍。

我查看了其他包,例如 sinon-as-promised,但我认为该包并不能真正解决我想要做的事情 - 我只是想确保在承诺 then 内调用我的回调条款。 sinon-as-promised 是一个用于存根整个承诺的包。

我可能忽略了一些简单的东西,但不管它是什么,我都没有看到它。

【问题讨论】:

  • 绝对有必要在状态改变时调用this.props.onChange(而不是在状态going 改变时)?问题是您的状态更改方法是异步的,但您的测试不是(而且我认为没有非常干净的解决方案)。
  • 谢谢@robertklep,你让我对这个问题有了更多的思考。为此,异步不是必需的,但我想使用setState 上的回调来a)确保在继续之前实际进行了更改(我承认这可能会或可能不会真正产生影响)和b)实施出于语义原因的承诺(在多步骤过程中链接步骤并避免厄运金字塔)。

标签: node.js promise sinon


【解决方案1】:

您的同步测试似乎在您对状态的异步调用执行之前完成。我不会评论您是否应该同时设置状态和调用更改方法以及何时。但我认为您当前的简单答案是通过传入 done 参数来使用异步测试。 (很明显,那时你甚至不需要间谍,但我把它留了只是为了表明不是间谍本身不起作用:

describe('TextInput component editing', () => {
  it('calls the onChange handler', done => {
    const fakeOnChange = stuff => {
      expect(spyOnChange.calledOnce).to.equal(true);
      expect(editedValue).to.equal(stuff);
      expect(component.find('input').prop('value')).to.equal(editedValue);
      done();
    }

    const spyOnChange = sinon.spy(fakeOnChange);

    const value = '';
    const editedValue = 'something';

    const component = mount(<TextInput value={value} onChange={spyOnChange} />);

    component.find('input').simulate('change', {
        target: { value: editedValue }
    });

  });
});

【讨论】:

  • 我打算提出类似的建议。我唯一的问题(但不能轻易修复)是当fakeOnChange 永远不会被调用时(由于组件中的错误),测试将超时(这当然表明某些事情是错误,但如果事件处理程序被调用或没有被调用,能够显式测试仍然会更好)。这就是为什么我问(在我的评论中)异步是否是绝对必要的。
  • 我目前正在使用setState 上的回调函数,它工作正常。在这种情况下,我想让代码正常工作,而不是过分担心最优雅的解决方案。但是感谢您的回答 - 如果我有机会重构这段代码并让它变得漂亮,我会做这样的事情。
猜你喜欢
  • 2018-08-16
  • 2018-12-26
  • 1970-01-01
  • 2023-03-28
  • 2019-06-27
  • 2017-07-06
  • 2019-03-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多