我最近正在学习Redux并使用Jest在TDD流程中编写单元测试

我为动作创作者和还原者编写测试。但是我正在努力:我可以在化简测试中利用动作创建者吗?

import * as types from './../../constants/auth';
import * as actions from './../../actions/auth';
import reducer, {initialState} from './../auth';

我可以这样做吗
it('should set isFetching to true', () => {
    const expectedState = {
        ...initialState,
        isFetching: true
    }

    expect(
        reducer(initialState, actions.loginPending())
    ).toEqual(expectedState)
});

而不是这个?
it('should set isFetching to true', () => {
    const expectedState = {
        ...initialState,
        isFetching: true
    }

    expect(
        reducer(initialState, {type: types.LOGIN_PENDING})
    ).toEqual(expectedState)
});

我对此有疑问,因为官方文档在reducers测试中使用了硬编码的动作:
expect(
  reducer([], {
    type: types.ADD_TODO,
    text: 'Run the tests'
  })
).toEqual([{
      text: 'Run the tests',
      completed: false,
      id: 0
}])

我猜想使用硬编码操作是最佳实践,不是吗?

最佳答案

有趣的问题,我想说这取决于您如何运行测试套件。就我个人而言,我对操作进行了硬编码,因为如果您考虑一下,它们将声明性地解释减速器的期望。支持导入操作的理由是,如果您更改了操作的源,则无需更新测试。但是,这也意味着您期望在运行这些测试之前您的操作始终正确。

如果是这种情况(如果您始终在此之前运行动作测试套件),则将它们导入到reducer测试套件中是合理的。反对这种逻辑的唯一论点是,让新开发人员仅通过查看reducer测试套件来了解您的reducer的工作并不容易,因为他们还需要查看action源文件以查看是什么类型的action。派遣。

另一方面,对操作进行硬编码更具声明性,但是如果您的操作发生更改,则确实需要更新每个reducer测试。我仍然建议使用此方法的原因是,它允许您发送更多受控数据,但是我同意这会增加维护成本。

关于unit-testing - Redux单元测试- reducer 和 Action 创建者,我们在Stack Overflow上找到一个类似的问题:https://stackoverflow.com/questions/38662403/

10-09 05:54
查看更多