return () => { listeners = listeners.filter(l => l !== listener)}
},
dispatch,
}
}
这是一个简化版的代码，去掉了抛错等等细节，但功用是残缺的。把你本人写的reducer扔出来，然后可以发事情来使其更新，你还可以订阅它来拿形状。有点像 Event Sourcing ，以音讯而非调用来处置逻辑，更新和订阅的逻辑不在一同(事情是写模型，各种view就是多个读模型)。
reducer简直包括了我们一切前端业务的中心，测好它就测了大半。它们全都是 (State, Action) => nextState 方式的纯函数，无异步操作，用swtich case来模拟形式婚配来处置事情。比如用喜闻乐见的粗陋版的栈停车场举例：
export const parkingLot = (state = [], action) => {
switch (action.type) {
case 'parkingLot/PARK':
return [action.car, ...state]
case 'parkingLot/PICK':
const [_, ...rest] = state
return rest
default: return state
}
}
Reducer是这么用的：
const store = createStore(parkingLot)
store.subscribe(() => renderMyView(store.getState()))
store.dispatch({ type: 'parkingLot/PARK' })
好，如今你又了解了Redux。那我们可以看看怎样测试下面的parkingLot reducer了：
test('parking lot', t => {
const initial = parkingLot(undefined, {})
t.deepEqual(initial, [], 'should be empty when init')
const parked = parkingLot(initial, { type: 'parkingLot/PARK', car: 'Tesla Model S' })
t.deepEqual(parked, ['Tesla Model S'], 'should park Model S in lot')
const picked = parkingLot(parked, { type: 'parkingLot/PICK' })
t.deepEqual(picked, [], 'should remove the car')
})
它就是你第一天学测试就会写的那种测试。这些测试不受任何上下文影响，是幂等的。试着把那几个const声明的state挪就任何中央，你都可以发现测试还是正确的，这和我们往常小心翼翼别离各个测试case，并用beforeEach和afterEach重置一模一样。
测试Reducer是十分机械的，你不需求问本人“我究竟应该测哪些东西”，只需求机械地测试初始state和每个switch case就好了。(小秘密：redux-devtools写完完成，在阅读器里翻开，反过去还可以自动生成各种框架的测试代码，粘贴回来就行了。引荐不写测试的项目尝试下，反正白送的测试……而且跟你写的没两样)
随着业务变得复杂，当state树变大时，我们可以将reducer结构继续往下抽，并继续传递事情，函数没有this，重构起来比普通OO要复杂得多，就不赘述了。这时分测试还是完全一样的，这种树形结构保证了我们能最大限制地掩盖一个bounded context—也就是root reducer。
另外更好的方式是用t.is(断言援用相反)而非t.deepEqual。但是JavaScript对象本身是可变的，引入 immutable.js 可以让你只用t.is测试，不过immutable的API有点别扭，不展开了。
组件测试 (View测试)
(责任编辑：admin)