Redux: スマートコンポーネントのユニットテスト

作成日 2015年08月20日 · 19コメント · ソース: reduxjs/redux

ドキュメントの単体テストのセクションを読んでいて、ダムコンポーネントをテストする方法の例がありますが、「スマートコンポーネント」（connect（）メソッドを使用するコンポーネント）を単体テストできることについては説明していません。 connect（）が作成するラッパーコンポーネントのため、スマートコンポーネントの単体テストは少し複雑であることがわかりました。問題の一部は、connect（）を介してコンポーネントをラップするには、「ストア」プロップ（またはコンテキスト）が必要になることです。

私はこれをやろうとしてひびを入れました、そしてそれを達成するためのより良い方法があるかどうかについて少しフィードバックを得ることを望んでいました。そして、私がやったことが合理的に見えることになった場合、私はPRを押し上げて、これに関する情報を単体テストのドキュメントに追加すると考えました。

まず、ドキュメントの単体テストセクションにある既存のサンプルコンポーネントを、connect（）でラップして、状態およびディスパッチにバインドされたアクションの作成者からデータを渡しました。

Header.js（スマートコンポーネント）

import React, { PropTypes, Component } from 'react';
import TodoTextInput from './TodoTextInput';
import TodoActions from '../actions/TodoActions';
import connect from 'redux-react';

class Header extends Component {
  handleSave(text) {
    if (text.length !== 0) {
      this.props.addTodo(text);
    }
  }

  render() {
    return (
      <header className='header'>
          <h1>{this.props.numberOfTodos + " Todos"}</h1>
          <TodoTextInput newTodo={true}
                         onSave={this.handleSave.bind(this)}
                         placeholder='What needs to be done?' />
      </header>
    );
  }
}

export default connect(
  (state) =>  {numberOfTodos: state.todos.length},
  TodoActions
)(Header);

単体テストファイルでは、例と同様に見えます。

Header.test.js

import expect from 'expect';
import jsdomReact from '../jsdomReact';
import React from 'react/addons';
import Header from '../../components/Header';
import TodoTextInput from '../../components/TodoTextInput';
const { TestUtils } = React.addons;

/**
 * Mock out the top level Redux store with all the required 
 * methods and have it return the provided state by default.
 * <strong i="13">@param</strong> {Object} state State to populate in store
 * <strong i="14">@return</strong> {Object} Mock store
 */
function createMockStore(state) {
  return {
    subscribe: () => {},
    dispatch: () => {},
    getState: () => {
      return {...state};
    }
  };
}

/**
 * Render the Header component with a mock store populated
 * with the provided state
 * <strong i="15">@param</strong> {Object} storeState State to populate in mock store
 * <strong i="16">@return</strong> {Object} Rendered output from component
 */
function setup(storeState) {
  let renderer = TestUtils.createRenderer();
  renderer.render(<Header store={createMockStore(storeState)} />);
  var output = renderer.getRenderedOutput();
  return output.refs.wrappedInstance();
}

describe('components', () => {
  jsdomReact();

  describe('Header', () => {
    it('should call call addTodo if length of text is greater than 0', () => {
      const output = setup({
        todos: [1, 2, 3]
      });
      var addTodoSpy = expect.spyOn(output.props, 'addTodo');

      let input = output.props.children[1];
      input.props.onSave('');
      expect(addTodoSpy.calls.length).toBe(0);
      input.props.onSave('Use Redux');
      expect(addTodoSpy.calls.length).toBe(1);
    });
  });
});

このテストを少し簡略化して、関連する部分だけを示しましたが、私が確信していない主なポイントは、 createMockStoreメソッドです。小道具なしでヘッダーコンポーネントをレンダリングしようとすると、Redux（またはreact-redux）によってエラーがスローされ、コンポーネントはstoreの子であることが想定されているため、小道具またはコンテキストが必要であることが示されます。 <Provider>コンポーネント。単体テストには使用したくないので、モックアウトして、ストアに設定したい状態でテストに合格できるようにするメソッドを作成しました。

このアプローチの利点は、コンポーネント内の関数をテストできるだけでなく、connect（）に渡すメソッドの機能もテストできることです。 expect(output.props.numberOfTodos).toBe(3)ようなことを行う別のアサーションをここに簡単に記述して、 mapStateToProps関数が期待どおりに動作していることを確認できます。

その主な欠点は、Reduxストアをモックアウトする必要があることです。これはそれほど複雑ではありませんが、内部のReduxロジックの一部であり、変更される可能性があるように感じます。明らかに、私の単体テストでは、これらのメソッドを一般的な単体テストユーティリティファイルに移動したので、ストアメソッドが変更された場合でも、コードを1か所で変更するだけで済みます。

考え？他の誰かがスマートコンポーネントのユニットテストを試し、物事を行うためのより良い方法を見つけましたか？

discussion question

ソース

ernieturner

👍1

最も参考になるコメント

@ernieturner @ghengeveldが意味するのは、どこでもES6モジュールを使用する場合、装飾されたヘッダーコンポーネントをデフォルトとしてエクスポートでき、プレーンなReactコンポーネントを追加の名前付きエクスポートにすることができると思います。例えば -

//header.js
export class HeaderDumbComponent {
  render() {
    return <header><div>...</div></header>;
  }
}

export default connect(
  (state) =>  {numberOfTodos: state.todos.length},
  TodoActions
)(HeaderDumbComponent);

このデュアルエクスポートを使用すると、メインアプリはimport Header from './header.js'以前と同じようにスマートコンポーネントを消費できますが、テストではreduxをバイパスして、コアコンポーネントの動作をimport {HeaderDumbComponent} from '../components/header.js'直接テストできます。

eugene1g 2015年08月21日

👍18

全てのコメント19件

別の方法は、（装飾されていない）ヘッダークラスもエクスポートすることです。これにより、個別にインポートしてテストできます。

また、少なくともMochaを使用している場合は、すべてのファイルでjsdomReact呼び出しを行う必要はありません。これが私のsetup.jsです：

import jsdom from 'jsdom';
import ExecutionEnvironment from 'react/lib/ExecutionEnvironment';

if (!global.document || !global.window) {
  global.document = jsdom.jsdom('<!doctype html><html><body></body></html>');
  global.window = document.defaultView;
  global.navigator = window.navigator;

  ExecutionEnvironment.canUseDOM = true;

  window.addEventListener('load', () => {
    console.log('JSDom setup completed: document, window and navigator are now on global scope.');
  });
}

--requireコマンドラインオプションを介してロードされます： mocha -r babelhook -r test/setup --recursive （babelhookはrequire('babel-core/register')呼び出しです）。

ghengeveld 2015年08月20日

ええ、Headerクラスと装飾されたクラスの両方をエクスポートできましたが、単体テストのためだけにソースコードを変更する必要はありませんでした。そうすると、装飾されたコンポーネントを含むすべての場所を変更する必要があります（たとえば、 import Header from 。/ components / Header`だけでなくimport {DecoratedHeader} from './components/Header' ）。

jsdomのセットアップに関しては、ユースケースを示す方法として、ドキュメントから例をコピーしただけでした。メインのセットアップとしては使用せず、単なる例です。

ernieturner 2015年08月20日

上記のコードサンプルが不完全であることに気づきました。スマートコンポーネントを直接テストするには、レンダリングの結果だけでなく、ユーティリティメソッドからrefs.wrappedInstance返す必要があります。これにより、接続で装飾されたコンポーネントが得られます（上記のセットアップ関数で更新されます）。。これもまた、ユニットテストをReduxの内部（この場合、特にreact-reduxの内部）に依存させます。だからそれは動作しますが、少し壊れやすいように感じます。

ernieturner 2015年08月21日

@ernieturnerこのためのgetWrappedInstance()パブリックAPIも提供しているため、 refs直接アクセスする必要がある場合は信頼できます。そして、これを透過的にするためのreact-test-treeのようなユーティリティもあります。

gaearon 2015年08月21日

//header.js
export class HeaderDumbComponent {
  render() {
    return <header><div>...</div></header>;
  }
}

export default connect(
  (state) =>  {numberOfTodos: state.todos.length},
  TodoActions
)(HeaderDumbComponent);

eugene1g 2015年08月21日

👍18

@ eugene1g @ghengeveldこれは実際には問題には本当に良い解決策です。それを説明する「ライティングテスト」ドキュメントにPRを送ってください！

gaearon 2015年08月21日

@ eugene1gそれはまさに私が意味したことです。
@gaearonやります。

ghengeveld 2015年08月21日

@ghengeveld誤解をお詫びします。私はまだCommonJSスタイルのインポートを使用しているので、ES6モジュールではまだかなり錆びています。これは、ドキュメントで公開するのに適したソリューションのようです。 mapStateToProps / mapDispatchToPropsメソッドも公開して、ストアのモックアウトを処理せずにテストできるようにすることもできると思います。

export class HeaderDumpComponent ...

export function mapStateToProps(state) ... 
export function mapDispatchToProps(dispatch) ...

export default connect(mapStateToProps, mapDispatchToProps)(HeaderDumpComponent);

ほとんどのマップメソッドは、単体テストを必要としないほど単純である可能性がありますが、コンポーネントの機能の非常に重要な部分であるため、検証する価値のあるものがいくつかあります。

皆さんの提案に感謝します。ドキュメントについてサポートが必要な場合は、お知らせください。

ernieturner 2015年08月21日

現在、上記の推奨アプローチを試していますが、完全に満足できるものではありません。これにより、 connect渡されたパラメーターは、統合テスト以外ではテストされredux-mock-storeのようなものが飛び込む可能性があると思います。その方向性についてどう思いますか？

carpeliam 2015年11月03日

@carpeliam

普通の店を使って、特定の初期状態で水分補給してみませんか？
どのアクションがディスパッチされているかをテストする場合にのみ、モックストアを作成する必要があります。

gaearon 2015年11月03日

@carpeliam

このリポジトリのcounterとtodomvc例の単体テストを参照してください。

gaearon 2015年11月03日

別のコンポーネント内でスマートコンポーネントをレンダリングしていて、浅いレンダラーを使用できないという問題がありました（コンポーネントはcomponentDid *メソッドを使用していました）。私たちが行ったのは、接続関数をスタブ（sinonを使用）して、単純なReactコンポーネントを返す関数を返すことでした。

壊れやすく、React 0.14に移行できるようになったら、浅いレンダラーに移行したいと考えていますが、この方法では、当面の間、テストのブロックを解除しました。

songawee 2015年11月24日

私もこれに問題があります。私はReactとReduxの両方にかなり慣れていないので、これが私を妨げている可能性があります。どのようにしてそれを回避することができましたか？ @songawee

adrianObel 2015年12月02日

提案された二重エクスポート方法では、select（mapStoreToState）関数はテストされません。個別にテストするには、エクスポートする必要がありますが、テストの名前をさらに変更します。

浅いレンダラーをconnectのラップされたコンポーネントで動作させる方法を見つけることに興味があります。私の現在の問題は、浅いレンダラーを使用すると、Connectコンポーネントのみが返されることです。これは予想されることです。

wwalser 2016年02月19日

提案された二重エクスポート方法では、select（mapStoreToState）関数はテストされません。個別にテストするには、エクスポートする必要がありますが、テストの名前をさらに変更します。

厳密には「テストの名の下に」ではありません。実際、レデューサーと一緒にセレクター関数（最終的にはmapStateToProps ）を定義し、それらを一緒にテストすることをお勧めします。このロジックはUIから独立しており、バンドルする必要はありません。いくつかのセレクターのshopping-cart例を見てください。

gaearon 2016年02月19日

👍3

@gaearon 、この_selector_関数を使用して状態からすべてのデータを取得することを提案していますか？ほとんどの場合、人々は状態からプロパティの束を読み取り、それらをコンポーネントの小道具に割り当てるだけなので、それは多くの不要なオーバーヘッドをもたらしませんか？

romulobr 2016年06月15日

はい、Reduxの一般的な推奨パターンは、 state.some.nested.field直接アクセスするのではなく、ほとんどすべての場所でセレクター関数を使用することです。これらは非常に単純な「単純な」関数ですが、最も一般的には、メモ化機能を提供するReselectライブラリを使用してまとめられます。

なぜそれが余分なオーバーヘッドを生み出すのでしょうか？

markerikson 2016年06月15日

ここで説明するように二重エクスポートを実行していますが、 connectソースを読み取ると、「コンテナ」がWrappedComponent静的プロパティの「ダム」コンポーネントへの参照を保持していることがわかりました。

コード内： https ：
ドキュメント内： https ：

したがって、代わりに：

// header.js
export const HeaderDumbComponent = (props) => <header><div>...</div></header>
export default connect(mapStateToProps)(HeaderDumbComponent)


// header.spec.js
import { HeaderDumbComponent } from './header'

it('renders', () => {
  expect(<HeaderDumbComponent />).to.not.be.null
})

「ダム」バージョンが必要な場所でWrappedComponentを使用すると、二重エクスポートを回避できます。

// header.js
const HeaderDumbComponent = (props) => <header><div>...</div></header>
export default connect(mapStateToProps)(HeaderDumbComponent)


// header.spec.js
import Header from './header'

it('renders', () => {
  expect(<Header.WrappedComponent />).to.not.be.null
})

@gaearon - WrappedComponentは、ドキュメントにあることを考えると、かなり安定したプロパティのようです。何らかの理由でこのように使用しないようにアドバイスしますか？

jeffcarbs 2016年10月21日

👍14

ラップされていないコンポーネントをエクスポートし、mapStateToPropsとmapDispatchToPropsもエクスポートして、これらの関数を単体テストできるようにします。次に例を示します。

import {ManageCoursePage, mapStateToProps, mapDispatchToProps} from './ManageCoursePage';

describe("mapStateToProps", () => {
    function setup(courses, authors, id) {
        const state = {
            authors: authors
        };

        const ownProps = {
            params: {
                id: id
            }
        };

        return mapStateToProps(state, ownProps);
    }

    it('sets the course when a course id is set', () => {
        const courses = [ { id: "1", foo: "bar" }, { id: "2", foo: "notbar" } ];
        const authors = [];
        const id = "1";

        const props = setup(courses, authors, id);

        expect(props.course).toBe(courses[0]);
    });

    it('sets the course when a course id is not set', () => {
        const courses = [ { id: "1", foo: "bar" }, { id: "2", foo: "notbar" } ];
        const authors = [];

        const props = setup(courses, authors, null);

        expect(props.course).toEqual({});
    });

    it('sets the course when a course id is set that is not present in the courses list', () => {
        const courses = [ { id: "1", foo: "bar" }, { id: "2", foo: "notbar" } ];
        const authors = [];
        const id = "42";

        const props = setup(courses, authors, null);

        expect(props.course).toEqual({});
    });

    it('sets the authors formatted for a drop down list', () => {
        const courses = [];
        const authors = [ { id: "1", name: "John" }, { id: "2", name: "Jill" }];

        const props = setup(courses, authors, null);

        expect(props.authors).toEqual([
            { value: "1", text: "John" },
            { value: "2", text: "Jill" }
        ])
    });
});

claassen 2016年11月20日

👍3

このページは役に立ちましたか？

0 / 5 - 0 評価

Redux: スマートコンポーネントのユニットテスト

Header.js（スマートコンポーネント）

Header.test.js

最も参考になるコメント

全てのコメント19件

関連する問題