雑に動くものを最初に作る理由

最初は見た目とか、異常系とか、細かい仕様とかを無視して、正常系が一通り動くものを作ります。

これはこれから作ろうとしているものの認識が合っているかどうかをPO（プロダクトオーナー）に確認するためです。
実際に動く画面を見せると「こんな感じでOK」とか「ここはこういうふうにしたい」というフィードバックをもらうことができます。

また、開発者としてもコードを書きながら「あれっ、こういう場合はどういう仕様にしたらいいんだろう？」という考慮漏れの仕様が見つかったりすることがあります。

Tips: あとで作り込む部分は忘れないように適宜TODOコメントを入れておくと良いです。

その次に見た目をきれいにしたり、機能を作り込んだりする理由

方向性を確認したら、見た目や機能の詳細を作り込んでいきます。

この時点でテストを一緒に書いていくこともありますが、「テストを書くのは時間がかかりそうだな」と思ったら、テストを全く書かずに進めることもありますたとえば、その機能に関連する既存のテストがなく、テストコードをゼロから書かないといけない場合などです。（一方、「これはテストを先に書いた方が、手と目で動作確認を繰り返すより速くなりそうだな」と判断することもあります。よって、書く、書かないはケースバイケースです）。

こうする理由は万一、何らかのトラブルでスケジュールが遅れそうになったときに「テストもないし、コードも汚いけど、最悪この状態でリリースすることは可能」という状態に持っていくためです（あくまで最悪のケースですよ！！）。

「テストをがんばって書いてたら当初のリリーススケジュールをオーバーしてしまった」よりも、「テストはまだ書けてないけど、とりあえずリリースはできた。順番が逆になったけど、リリース後にテストを書こう」の方がビジネス的には望ましいはずです。

最後にテストを書いてリファクタリングする理由

一通り実装が終わったらテストを書きます。テストファーストならぬ、「テストラスト」ですね。

一通り実装が終わって「最悪このままでもリリースできる状態」になっているので、精神的な余裕をもってテストを書くことができます。

ちなみに「リファクタリングをしてからテストを書く」のではなく、「テストを書いてからリファクタリングする」というのがポイントです。

リファクタリングは「リファクタリングの前後でプログラムの挙動が変わらないこと」が大前提です。
この「挙動が変わらないこと（リファクタリングが原因でプログラムが壊れたりしないこと）」を担保するためにはテストコードの存在が必須です。

もしテストより先にリファクタリングをやってしまうと、挙動が変わらないことを開発者自身の手と目で担保しなければなりません。
これは非効率ですし、うっかりミスでプログラムを壊してしまう恐れもあります。

参考：コードレビューも分割して良い

作成する機能が大きいときは上記のステップが終わるたびにプルリクエスト（PR）を作成して、コードレビューしてもらいましょう。
すなわち、

雑に動くものを作る
　　↓
PR作成＆コードレビュー
　　↓
見た目をきれいにする＆機能を作り込む
　　↓
PR作成＆コードレビュー
　　↓
テストを書く
　　↓
PR作成＆コードレビュー
　　↓
リファクタリングする
　　↓
PR作成＆コードレビュー

とするわけです（テストとリファクタリングはまとめてコードレビューでも可）。
あ、もちろんコードレビューが終わってもmainブランチにはまだマージしませんよ。mainブランチにマージするのはリファクタリングが完了してからです。

特に「雑に動くものを作る」段階で一度コードレビューしてもらうことは重要です。
なぜなら、コードレビューを受けることで技術的な方向性の根本的な誤りを指摘してもらえるかもしれないからです。

また、最後にまとめてPRをどーん！！と作成すると、diffが大きくなりすぎてレビュアーが苦労する可能性もあります。
PRはなるべく小口化することを心がけてください。

プルリクエストをレビューするとき、僕は変更されたファイル数で大きさを見積もることが多い。感覚としてはこんな感じ👇

- 10以下 = すぐ見ま〜す😄
- 10〜30 = まあふつう
- 30〜50 = げ、ちょっとしんどいな
- 50〜100 = 大きすぎる。もっと小さくして！
- 100以上 = 見たくない！出直してきて！！pic.twitter.com/wlCIS1jasD

— Junichi Ito (伊藤淳一) (@jnchito)2020年9月29日

テストファーストで作ることはないの？

いえ、もちろんテストファーストで作るときもあります。
僕は以下の条件がどちらもYESになったときにテストファーストで開発します。

• プログラムの仕様が明確である（作りながら「どうしようかな？」と考える部分がない）
• その仕様を担保するテストコードをすらすら書ける自信がある（＝テストを書くコストが低い）

たとえば、「 "alice@example.com" を "a...e@example.com" のように、ユーザー名の最初と最後の1文字だけ残してマスキングするメソッドを作れ」という要件があったりした場合は、上の2つの条件を満たすので次のようなテストコードを先に書いてしまいます。

RSpec.describeUser,type::modeldo  describe'#masked_email'do    context'ユーザー名が3文字以上'do      exampledo        user =User.new(email:'ken@example.com')        expect(user.masked_email).to eq'k...n@example.com'        user =User.new(email:'alice@example.com')        expect(user.masked_email).to eq'a...e@example.com'endend    context'ユーザー名が2文字'do      exampledo        user =User.new(email:'me@example.com')        expect(user.masked_email).to eq'm...e@example.com'endend    context'ユーザー名が1文字'do      exampledo        user =User.new(email:'x@example.com')        expect(user.masked_email).to eq'x...x@example.com'endendendend

上のテストコードは何もドキュメントを見ずに、テストも一切実行せずに、エディタ上でひたすらコードを打ち込んだものです。
あとはmasked_emailメソッドを実装してテストを全部パスさせればいいだけですね。

こういうケースはテストファーストで開発するスタイルが有用です。

不具合修正するときもテストファースト

他にも不具合を修正するときもテストファーストで修正します。
具体的には以下のような流れです。

エラーを再現させるテストコードを書く（この時点ではテストの結果はRED🚨）
　　↓
エラーを修正する（場合によっては修正する前に、デバッガも併用しながらテストを実行してエラーの原因を調査する）
　　↓
テストがパスすることを確認する（テストの結果はGREEN✅）

テストを書いておけば不具合の再発も防止できるので一石二鳥です✌️

あわせて読みたい

そもそもテストコードってなんで必要なんだっけ？という基礎から学びたい方はこちらのスライドをどうぞ。

RSpecを使ってRailsのテストをすらすら書けるようになりたい！という人は、「Everyday Rails - RSpecによるRailsテスト入門」をどうぞ。
leanpub.com