Redux的单元测试 - 减速器和行动创造者

我最近学习终极版，写单元测试与使用行动创造者和减速器玩笑Redux的单元测试 - 减速器和行动创造者

我写测试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) 
});

我来到这无疑是因为官方文档使用硬编码的动作在减速测试：

expect(
    reducer([], { 
    type: types.ADD_TODO, 
    text: 'Run the tests' 
    }) 
).toEqual([{ 
     text: 'Run the tests', 
     completed: false, 
     id: 0 
}])

我猜使用硬编码的行动是最好的做法是不是？

来源

2016-07-29 David Lavieri

有趣的问题，我会说这取决于你如何运行你的测试套件。就我个人而言，我对动作进行硬编码，因为如果您仔细考虑它们，他们会声明性地解释减速器期望的内容。赞成导入这些动作的论点是，如果你改变了它们的源代码，测试将不需要更新。但是，这也意味着您在运行这些测试之前期待您的操作始终正确。

如果是这样的话（如果你总是在这个之前运行你的动作测试套件），那么将它们导入你的reducer测试套件是合理的。反对这种逻辑的唯一理由是，让新开发人员仅仅看着Reducer测试套件就可以了解Reducer的工作原理并不容易，因为他们还需要查看动作源文件以查看哪些类型的动作是出动。

另一方面，对行为进行硬编码更具说明性，但如果行为更改，则需要更新每个缩减器测试。我仍然推荐这种方法的原因是，它允许您发送更多受控数据，但我同意它会增加维护成本。

来源

2016-07-29 15:42:20 ZekeDroid

对此有相同的看法，主要是为了避免“维护成本”。但是，正如你声明的那样，它们使它成为声明式的，对新开发者来说很有帮助。由于测试不是单独运行，只需要对操作进行严格编码即可。谢谢 –

Redux的单元测试 - 减速器和行动创造者

回答

相关问题