はじめに
「テスト駆動開発」という言葉を教えて頂く機会があったので、調べてみました。
様々な記事を参考に、自分なりの解釈・言葉に置き換えました。
間違った認識をしていましたら、ご教授頂けますと幸いです。
前回記事 → テスト駆動開発とは？ 1
テスト駆動開発(TDD)の流れ
- 「レッド」 → 「グリーン」 → 「リファクタリング」 のサイクルを繰り返す。
~心の声~
特撮系の発進前みたいだ😄（伝わりにくいかも）
それぞれの役割は何？
「 レッド 」 さん いっきま〜す！
「必ず失敗するテストコード」から書き出す。
なかなかのパワーワードですが、以下理由です。
- テスト駆動開発とは？ 1 でも触れたとおり、TDDはテストファーストです。
- 実装したい機能を実現するコードが書かれていない場合でも、まずはその機能のテストコードから先に書くということが基本。
- そして、機能を実現するコードを書いていない状態で、テストツールを使い、テストが失敗すると赤色でエラー表示されるので、「レッド」と呼ばれます。
- また、書いたテストコードは実行して失敗することも確かめています。
この段階では、実装したい機能の要件を適切な粒度に分けて、リストアップしておくことが重要のようです！
「 グリーン 」 さん お願いします！
「最小限・最低限のパスするテストコード」を書く。
- テストをパスするコードを書く段階ですが、完璧なコードは必要ない。
- 「レッド」と「グリーン」の段階を何度か繰り返しごとに、徐々にロジックを追加していく。
「 リファクタリング 」 さん やっと出番です！
「テストをパスしたコード」を 綺麗 にする。
- 全てのテストをパスしたコードの可読性を上げるのです。
- テスト対象とするプログラムコードの規模が小さいうちに行うのがbetter
- 「グリーン」の段階で、「テストをクリアしているから、リファるのは後ででいいや〜」としてしまうと・・・
- プログラムの規模が大きくなるにつれて修正負担が増え、手がつけられなくなります。怖い・・・
ざっくりとこんな流れです！
注意点
- テスト実行時間はなるべく短く！（毎回長いと開発期間がえらいことに・・・）
- 各テストに依存関係は持たせない。（1つ修正すると依存先も修正するという辛い目にあいそう・・・）
さいごに
やっぱり新しいことを学ぶのは楽しいですね！
簡易アプリを作るときにTDDでやってみようと思えました！ぜひ初学者の皆さんも！
日々勉強中ですので、随時更新します。ご覧いただきありがとうございました！