04.問題はここだ
どうやら簡単に改善できそうにないので、テストコードの何が問題なのかを改めて考えてみました。
その１）思いつき列挙
私のテストコードは、初期表示、想定されるユーザーの操作のシミュレーション、API レスポンスのパターン、バグがありそうなイレギュラー操作パターンなど、思いついたものを次々に追加するスタイルです。開発中はひとつのテストケースに注目しているので特にストレスを感じませんが、後からテストを追加する時にテストコード全てを読まないと何がどこに書いてあるのか分からなくなります。
その２）テスト対象がバラバラ
コンポーネントのテストを書く時に、テスト対象がコントローラだったりレンダリングされた HTML だったり、はたまた子コンポーネントや依存サービスがモックだったり本物だったりと、テストファイルによりバラつきがありました。テストを書いている時は「モックでなく本物を使って実際の挙動を確認したい」というような思いがあるのですが、後から見るとその意図を汲むのにひと苦労します。
その３）よくばり
保存ボタンがクリックされた時のテストを例に挙げると、保存ボタンが disabled な状態になる事、リスト選択ができなくなる事、API リクエストがコールされる事、保存中を示すアイコンが表示される事、これらが１つのテストケースに盛り込まれています。これがあちこちのテストケースで繰り返されているため、例えばドラフト保存ボタンなど新しい機能を追加した時に、テストコードを上から下まで眺めて新たなコードを追加するべき箇所を探し回る必要があるのです。
結論
私がテストコードを書く時に考えていた事は「リリース前になるべく多くのバグを発見して潰すべし」です。そのために画面のあちこちを検証し、サービスがコールされた事を検証し、足りないと思うテストケースをどんどん追加していました。これがカオスを生み出していた原因のようです。