Libraryについて説明します。Libraryを使ってみました。Enzymeを使っていたときは、find(#id)やfind(displayName)といったコードをよく書いていました。このようなコードを書くと、id名やdisplayNameを変更するというリファクタリングをしただけでもテストコードを書き直す必要が出てきてしまいます。Libraryというライブラリがあることを知りましたのでこのライブラリを使用してみました。Trophyという考え方が提唱されているということも知りました。Libraryの考え方と、この考え方を実際のテストコードに適用した例を説明します。コンポーネント単体のテストまず最初にコンポーネント単体のテストについて考えます。Dodds氏の言葉にあるように、propsと描画される結果に着目します。output.また、ロジックがない部分については、単純な実装でありテストをする必要性が低いものであったり、型チェックなどができるため、コンポーネント単体のテストの対象からは除外します。down.つまり、コンポーネント単体のテストとしては、以下のようなコンポーネントをテストする方針とします。前述したテストの方針を踏まえて、以下の手順でテストケースの設計を行います。コンポーネントのpropsをリストアップする各propsが取り得る値をリストアップするpropsの初期状態がどのようになっているか正常時にはpropsがどのような値を取り得るかエラー時にはpropsがどのような値を取り得るか各propsの取り得る値ごとに期待値(=コンポーネントの描画結果)を定義するそれぞれの状態をテストケースとするテスト設計とテストコードの実例では、実際にテストケースの設計とテストコードの実装を行ってみます。テスト対象のコードとして、Reduxのチュートリアルで使用されているTodoリストを使用します。(本記事では、Todoリストアプリのコードについては説明はしませんので、コードの内容はReduxのチュートリアルページを見てください。Todoリストアプリの完成イメージはこちらで確認できます)1つ目の例として、Todoコンポーネントのテスト設計をします。stringになります。line-throughのstyleが適用されていない4.それぞれの状態をテストケースとする1〜3をまとめると以下のようになります。none実際のコードは以下のようになります。Libraryの各APIについては、公式のAPIリファレンスをご参照ください。rendergetByText2つ目の例として、TodoListコンポーネントのテスト設計をします。todosの配列の要素数分だけ、Todoリスト(list要素)が描画される4.それぞれの状態をテストケースとする1〜3をまとめると以下のようになります。3つ実際のコードは以下のようになります。Libraryの各APIについては、公式のAPIリファレンスをご参照ください。queryAllByTestIdここで、queryByTestIdというものが出てきましたので少し補足します。ByTestIdというのは、APIリファレンスによると以下のようなものになります。possible.つまり、画面に表示されるテキスト(ByText)やラベル(ByLabelText)のようにユーザーから見えるDOM要素を取得するべきなのですが、今回の様なテストケースではそういったものがないため、ByTestIdで代用します。ByTestIdで要素を取得できるようにTodo.jsコンポーネントも以下のように修正します。Todoシナリオテスト次にシナリオテストについて考えてみます。テストの方針シナリオテストとしては、ユーザーが実際に操作する方法でテストを行えばよいかと思います。具体的なテストケースとしては以下のような手順で設計します。ユーザーがアプリケーション使用する際のシナリオを書き出す要件定義書や設計書があるならば、ユースケース一覧やユースケース記述からシナリオを書き出せばよいかと思います。引き続き、Reduxのチュートリアルで使用されているTodoリストアプリを使用して実際のテストケースの設計を行ってみます。1.ユーザーがアプリケーション使用する際のシナリオを書き出すシナリオとしては以下の3つになります。(c-3)[Todoリストを完了済みから未完了にする]・未完了にしたTodoリストには取り消し線が削除される実際のテストコードとしては以下のようになります。Libraryの各APIについては、公式のAPIリファレンスをご参照ください。storeの値をコンポーネントを渡す方法は、公式サイトに記述されている方法を参考にしています。upLoginユーザーは見つかりませんでした。