07.テストの戦略

ここまで学んだ事を前提に、私なりのテストの戦略を立ててみました。

目的

  • 開発と同時進行で書けて、開発の助けになるテスト
  • バグつぶしの証明になるテスト

手法

  • 列挙型のインテグレーションテスト(を見つけたい)

譲れない事

  • 正常値も異常値も渡したい
  • 再検索とかちょっとイレギュラーな操作も確認したい

戦略というか、ただやりたい事を書き起こしただけなんですけど。でもこれらをクリアしていたのが今までのカオスなコードだった訳で、同じ事ができないとカオスから抜け出しても意味がないのです。

捨てるもの

同時に今まで書いていた捨てるものを考えてみました。

コンテナコンポーネントのテストで内包するものまで全部テストする

子コンポーネントをいくつか持つコンテナとなるコンポーネントで、子コンポーネントをモックせずに本物の実装を使って挙動をテストしていたようなケースです。これは結合テストとして実施すべきもので、ユニットテストの範疇を超えています。これをやり始めると他のコンポーネントについてもつい同じパターンでテストを書きたくなってしまい、テストが巨大になりがちです。

ユースケースを追わない

検索〜クリア〜再検索〜キャンセル、のようなバグの再現手順を示すようなテストを書くのはやめました。 バグが出るという事は、どこかのタイミングでステートがおかしくなっているはずです。そのステートを探し出してステートに対するテストを書いたほうが、シンプルさを保つ事ができます。

コンポーネントの初期表示テスト

ほぼバグが出ないのに毎回せっせと書いていたものです。もしバグが出たとしたら、ステートが空っぽになった時の挙動がおかしいはずです。これも同じようにステートに着目したテストに変更します。