Zenn
Closed6

フロントエンドのTDD作業 / 調査ログ

Test
frontend
kazuhekazuhe

Kent C. Dodds 氏が提唱する「Testing Trophy」という概念について

Testing Libraryの開発者Kent C. Dodds氏

参照:https://testingjavascript.com/

  • E2E
  • Integration
  • Unit
  • Static
    のそれぞれのテストにはトレードオフがあり、図の上側に記載されているテストほど工数が必要だが正しい動作の保証が大きい事を表している。
    また、それぞれの体積が大きいテストほど多く書くべきとされている。
kazuhekazuhe

Testing Trophyの概念に従ったテストの方針

参考: https://qiita.com/naoking99/items/3fd211deb8711fae8204

1.実装の詳細をテストしない

リファクタリングはユーザーに対する振る舞いを変えずに実装の詳細（ユーザーから見えないもの）だけを変更する。
リファクタリングの際に実装の詳細をテストし、見た目は期待通りの動きをしている。しかし、テストが間違ってエラーを出してしまうことをしまうことがあり「壊れやすいテスト」になってしまう。
以下ポイントを参考記事より抜粋

・「ユーザーから見えるもの」という視点でテストする。
・「ユーザーから見えないもの」はテストしない。
・ テストで直接Component内のStateやメソッドをいじらない。
・ ユニットテストではなく、インテグレーションテストを最も書くようにする。
・ EnzymeのShallow Renderingは使わないようにする。
・ Snapshotテストをむやみに使わない。

2.外部システムに依存するテストはしない

外部システムと連動する部分はモックで置き換える。呼び出し回数と呼び出し時の引数をテストする。

3.モックはできるかぎり少なく

モックはあくまでもモック。システムが正しく動作する保証レベルが下がるので、モックの利用は「外部システムに依存する部分」など限定的に使用する。

4.コードカバレッジよりユースケースカバレッジを意識する

システムが正しく動作する保証レベルを上げる為にユースケースをテストでカバーすることこそが重要。

kazuhekazuhe

テスティングフレームワークのJestとCypressで「describe, it, expect」等の名前空間が競合して

Property 'toBe' does not exist on type 'Assertion'.

の様なエラーが発生。
https://typescript-jp.gitbook.io/deep-dive/intro-1/cypress
上の記事を参考にtsconfig.jsonとnode_modulesをe2eディレクトリに分けて保存。package.jsonの依存関係を分離させてエラー解消。

kazuhekazuhe

TDDのサイクル

TDD Boot Camp 2020 Online のアーカイブ
https://youtu.be/Q-FJ3XmFlT8

  1. タスクを分解して解決すべき目標（テスト容易性が高いものから）を決める
  2. 目標を示すテストを書く
  3. テストを即実行して失敗させる
  4. 目標を達成する為のコードを書く（この時コードの質は気にしない）
  5. テストを成功させる為にコードを修正
  6. テストが通っている間リファクタリング繰り返す（時間決めてやるのが良い）
  7. 1~6を繰り返す

=さらに要約=
テスト書いてとりあえず動くコード書く → テスト成功確認 → コードを綺麗にする → テスト成功確認 → 綺麗にする… をある程度繰り返す感じ。

このスクラップは2022/07/30にクローズされました