Open2
スタートアップ初期フェーズでのフロントエンドテストを考える
Izumiこのスクラップの目的
フロントエンドのテスト戦略を考えて欲しいと言われたのでまとめる前に雑にスクラップしていく
Izumiなぜフロントエンドのテストが必要なのか？
テストやStorybookを書くメリットとして以下が挙げられる
- 挙動のバグやUIのデグレを防げる
- 影響範囲が分かりやすいので安心してリファクタや変更ができる
- まだ変更が多いフェーズにおいても、どこが変わるかを認識できることが心強い
- 実装者以外の人が触る場合も自信を持って変更できる（もしくは変わらないことを確かめられる）
- 要件・実装の考慮漏れに気付ける
- 特に「ざっくり要件」のときにTDD的にテスト書いとくと有効
- デザイナーと認識を合わせやすい(Storybook)
一方でデメリット（というか懸念点）もある
- （テストの書き方を理解していない場合）テストを書くための学習コストがかかる
- テストを書く分の工数が増えるので、プロジェクトの進捗に影響する
- テストコードのメンテナンスを継続的に行っていく必要がある
特に、機能追加が多くあったり要件自体が変わる可能性が高いプロジェクト初期フェーズにおいてはなるべく工数をかけすぎて開発スピードを落とさないようにしたい
ただ、t-wada先生の以下の話はどのフェーズであっても言えるはず
内部品質や保守性を犠牲にすれば開発スピードは得られるかというと、短期的には得られるが、1カ月後には逆効果になって、長期的には致命傷になる
誰のためのテストか？といえば、安心して素早く実装できるようにする自分のためのテストと考えると書くモチベーションになりそう？
参考