テストリストの作成は備忘録を書くようなもの
はじめに
ここでは、テストリストの作成について今一度振り返ってみようと思います。
2023年12月に、テスト駆動開発（TDD: Test-Driven Development）の考案者、Kent BeckさんがTDDの定義を再度明確化されていました。
twadaさんがその内容を翻訳し、fukaboriのPodcastで詳しく解説しており
その内容を聴いて、自分がテストリスト作成のやり過ぎに陥っていたことに気付かされました。
自戒の念を込めつつ、どのような状態になると過度なテストリストの作成になっているのか振り返ってみようと思います。
改めて明確化されたTDD
twada さんが翻訳している内容を引用しています。
【翻訳】テスト駆動開発の定義より
- 網羅したいテストシナリオのリスト（テストリスト）を書く
- テストリストの中から「ひとつだけ」選び出し、実際に、具体的で、実行可能なテストコードに翻訳し、テストが失敗することを確認する
- プロダクトコードを変更し、いま書いたテスト（と、それまでに書いたすべてのテスト）を成功させる（その過程で気づいたことはテストリストに追加する）
- 必要に応じてリファクタリングを行い、実装の設計を改善する
- テストリストが空になるまでステップ2に戻って繰り返す
テストリストの作成
前提として、TDDにおいて、レッド→グリーン→リファクタリングのサイクルを回し続けることが注視されますが、
本来であればテストリストの作成（Todoリストの作成）も含まれるというこが述べられています。
テストリストを完璧に作る（網羅する）必要はない
ここが特にテストリスト作成において「やり過ぎ」に陥りやすいポイントだなと感じたところです。
まず、テストリストは備忘録を書いているような温度感で進めること。
これをテストリストの段階でテストケースを網羅しなければいけないという脅迫じみた状態になることがあり、
そもそもの認識を誤ることで午前中まるまるテストリストの作成に費やしてしまう状態に陥ることがありました。
テストリストの作成では、今わかっていることを書き出すことに留め、テストを書き、実装を行い、そこで得たFBを素直に受け取り、テストリストを修正していくことが今回より述べられていました。
過剰になりやすい状態
どのような状態の時に過剰なテストリストの作成に繋がるのかについても考えてみようと思います。
※あくまで、個人的な経験則に基づくものをPodcastと照らし合わせた内容になります。
- テストリストの作成がそもそもTDDのステップとして認識されていない
- やってみないとわからないような、具体的なケースの話をしている
- 目の前のこと（今やるべきこと）以外の話をしている
設計を都度改善する意識
こちらは経験ある方も多いと思いますが、テストリストを書いている時よりも、実装をしているタイミングがより新しいケースに気づきやすいということです。
そのためそのタイミングでテストリストを出し切ることができれば、まずは「ひとつだけ」選び、テストを通していく中で、設計について改善できているかを意識することにより重きを置いていくとテストリストに執着することもなくなるのではないかと思います。
まとめ
テストリストの作成は大切であるが、あくまで網羅しようと執着せず、備忘録を書くような温度感で書き進めること。
そして実際に得られたFBを反映すること。
今はそのように理解をしています。
最後に
今では、当たり前のようにTDDというワークフローを採用していましたが、どこかで上手く進められていない感覚がありました。
そこで今回のPodcastをきっかけに、その一つにテストリストの作成において認識を誤っていることに気づくきっかけとなり、振り返ることができました。
TDDに対する理解においても、TDDはもっとカジュアルなものであり、プログラミングの楽しいところが長続きする、させるためのものである
そのように認識を持てたことが大きな収穫だなと感じています。
Discussion