ユニットテストレデューサー、各スライスレデューサーまたは組み合わせレデューサーをテストしますか？

Question

は、私がこの

export default combineReducers({ 
    A: combineReducers({ A1, A2 }), 
    B: reducerB, 
    C: reducerC 
}) 

などの減速ファイルリデューサー/ group1.jsは、各スライスの減速（A1、A2、reducerBとreducerC）をテストし、合わせたものをテストする間に違いはありますがあると？

import group1 from 'reducers/group1' 

describe('reducers',() => { 
    describe('group1',() => { 
    it('should provide the initial state',() => { 
     expect(group1(undefined, {})).to.equal({ group1: { A: { ... }, B: ... } }) 
    }) 

    it(...) 

    // ... 
    }) 
}) 

または

import { A1, A2, reducerB, reducerC } from 'reducers/group1' 

describe('reducers',() => { 
    describe('group1',() => { 
    describe('A1',() => { 
     it('should provide the initial state',() => { 
     expect(A1(undefined, {})).to.equal(0) // if A1 is just a number 
     }) 
    }) 
    describe('A2',() => { ... }) 
    describe('reducerB',() => { ... }) 
    describe('reducerC',() => { ... }) 
    }) 
}) 

Answer 1

それは単純なユニットテストすることができますので、あなたの第二の例は、通常は良いです。開発者が減速機Cのテストをたくさん書いたければ、減速機AとBについて何も知らずにシナリオを想像することができます。 2番目のコードサンプルでは、​​AまたはBが何であるかを気にせずに、その開発者がCテストスイートを書くことができます。また、リデューサの動作が大幅に変更された場合に、テストを書き直すときに役立ちます。これらのテストはすべて、テストファイル全体に散在するのではなく、1か所にあります。

ただし、リデューサー全体のテストを作成する場合があります。たとえば、グローバルなリセットアクションがある場合、各レデューサーに対して個別のテストを作成するのではなく、そのアクションにレデューサー全体が適切に応答することをテストする必要があります。たいていの場合、おそらく個々の減速機のテストを書くのがよりクリーンになるでしょう。