Rspecに悪戦苦闘しながらも、無事に60件のテストケースをパスさせることができました。上司からは、TDDについて調べて、テストの意味について考えてみたら？とアドバイスを頂いたので、TDDについて少し勉強をした上で、テストについて思ったことをまとめていきたいと思います。
Contents
TDD（テスト駆動開発）
TDD（Test-Driven Development）とは、簡単に言うとプロダクトコードを書き始める前に、まずテストを書こうという開発手法です（テストファースト）。
目的は、「キレイで且つ動くコードを書くこと」。そのためのアプローチの一つとして、先にテストコードを書いてから、とりあえずテストに成功するようにプロダクトコードを書いていく（動くコードを書く）。そして、動くことが分かってから清書していく（キレイにしていく）。例えるならば、ちゃんと下書きしてから絵を描いた方がキレイに書けるでしょ！という感じ。
このような考えから、TDD の進め方はシンプルに3つ。
1. プロダクトコードを書く前にテストコードを書き、それが失敗することを確認する (レッド)
2. テストに成功するようにプロダクトコードを書く (グリーン)
⇒この段階では、テストが成功すれば、それでOKなので、とにかく成功させるようにプロダクトコードを実装していく。
3. プログラムの振る舞いを変えないように、プロダクトコードの重複などを整理する (リファクタリング)
TDDの原則もシンプルに3つ。
1. テストに失敗しない限り、プロダクトコードを書いてはいけない。
2. プロダクトコードはテストを通るように書く
3. テストは少しずつ書き進めていく
TDDのメリット
・プロダクトコードが書き上がる＝テストに通っている＝きちんと動くコードである、ということなので、手戻りが発生せず、バグが少なくなる。結果として品質が上がる。
・テストコードを書くということは、そのプロダクト・プログラムの仕様を理解する必要があるので、仕様に対する理解が深まる。また、仕様齟齬に気付くこともあるので、プロダクトコードを書いている最中に、「あれ？この仕様おかしくない？」みたいな状況になりにくい。
・プロダクトコードが完成した時、つまりプログラムが完成する頃には同時にテストコードも完成しているので、新しいバージョンのリリース等でリグレッションが生じた際にも、どこでバグが発生しているのか突き止めやすい。
TDDのデメリット
・仕様が変われば、テストコードを書き換える必要が出てくるので、メンテナンスが大変。
・バグが少なくなることをメリットとして上げたが、コードの80％をテストすると高い品質になるという話もあり、そう考えると単純に2倍のコードを書く必要があるので、コーディング時間が2倍近くになってしまう。
https://postd.cc/test-driven-development/
実際に60個のテストコードを書いた後に、TDDのメリット・デメリットを調べてみて思ったこと
一つ一つのプロダクトコードの意図・目的が鮮明になった。
TDDとは真逆ですが、今回の私の場合は、先にプロダクトコードを書いてからテストコードを書きました。テストコードを書き始める前に、「テスト仕様書」を書くことで、具体的にどのようなテストをする必要があるのか、テストケースを片っ端から洗い出していきました。すると、モデルのバリデーション関連のテストだけで40件以上出てきました。
「マジかよ・・・」と思いましたが、裏を返せば、自分がモデルに設定しているバリデーションはプログラムにおいて◯◯な状態を実現するために、40件以上のケースに対して制約を加えるような記述をしているということが理解することができました。さらに、テストケースを洗い出すなかで、「この仕様おかしくない？」「このバリデーション甘いな・・・」等、自身の考慮漏れに気付くことができました。
テスト仕様書が完成する頃には、自分のコードの修正点がいくつか出てきました。
「先にテスト仕様書を書いてからプロダクトコードを書けば、コードを修正する必要なかったなー」と思い、完全にTDDの思考になっていました笑
また、テスト仕様書を作成する過程で、「この仕様だと〇〇な可能性ないかな？」「◯◯機能って分解すると、どんな処理に分けれるかな？」等、プロダクトコードを書いているときには考えなかったような、細かい仕様まで考えるようになりました。
仕様変更に伴う、メンテナンスが大変そう
テストコードを書くことの恩恵は受けましたが、一方でTDDを実施するとなると大変だなと思いました。今回、テスト仕様書を書いている途中で、たまたま仕様変更がありました。すると、
「仕様変更に伴ってテストケースを考える際に、考慮する内容が増えた」
「テスト仕様書に仕様変更を随時反映させる必要があった」
「テストコードが10件以上増えた」
等々、仕様変更に伴って、タスクがぐっと増えました。今回私が作成していた仕様書は規模が小さいものだったので、そこまで苦にはなりませんでしたが、これが大規模なプログラムで且つ、複数の機能の仕様変更があったと考えたら、「・・・」って感じになりました。
TDDには、もちろんメリット・デメリットはありますが、私みたいなエンジニア初心者には得るものが多いと思うので、一回くらいはやってみた方が良いと思いました。
