RailsのTDD（テスト駆動開発）を1日やってみた感想

約10ヶ月ぶりにRubyとRailsを触ってみて、この際だからTDD（テスト駆動開発）を試してみよう！と思い本日試してみました。

すると…

意外とありかも！

と思ったんで少しだけ記事にしてみようと思います。

< テスト駆動開発 >
テスト駆動開発 (てすとくどうかいはつ、test-driven development; TDD) とは、プログラム開発手法の一種で、プログラムに必要な各機能について、最初にテストを書き（これをテストファーストと言う）、そのテストが動作する必要最低限な実装をとりあえず行った後、コードを洗練させる、という短い工程を繰り返すスタイルである。多くのアジャイルソフトウェア開発手法、例えばエクストリーム・プログラミングにおいて強く推奨されている。近年はビヘイビア駆動開発へと発展を遂げている。
- Wikipediaより

テスト駆動開発 - Wikipedia

< 目次 >

1. テストコードがあるから動作がわかる
2. 一括テストよりも修正が減るかも？
3. 動作が決まっていないケースには使えない
4. まとめ

1. テストコードがあるから動作がわかる

TDD（テスト駆動開発）では予想される動作が先に決まっているものは、実際の処理を書く前にテストコードとして先に落とし込む事が当たり前に行われているそうです。

それにより、コードを本来の処理が完成する前から自分以外の人が処理を想定して別の作業に当たれるメリットがあります。

Q. どんな時に便利？
A. フロントエンドエンジニアに先に処理を想定してもらえる。

なんと共同開発時には先に書いたテストコードで動作の確認を事前に周知できるメリットがあるようです。

その他にもテストコード自体が動作のエビデンスになるので後からコードを追う人にとっても動作を想定しやすいメリットも存在します。

2. 一括テストよりも修正が減るかも？

TDD（テスト駆動開発）には「バグを事前に潰してしまえ！」という発想があるそうで、TDDを取り入れることで後々の修正を最小限に減らす事ができます。

今回実際にやってみた感想では後々の一括テストも最初から書いておいたテストコードを動かすだけで終わりなので正直いつも面倒な一括テストが殆ど不要になるのは精神的にありがたいかもしれません。

また、以前PHPカンファレンス2018に参加した時にLaravelでのTDDの講義を聞いた時は「TDDはリズムだ！」とおっしゃっていたのですが実際にやってみて「テストコード ▶エラー（わざと）▶ 実装 ▶ エラー ▶修正 ▶ OK」の手順をどれだけ早く小気味よく回していくかが重要なのかが理解できました。これはリズムよく進めていかないと実装スピードに影響が及んでしまう事を考えてリズムと言っているっぽいですね！

ただTDD（テスト駆動開発）にもメリット・デメリットが存在していて意見が分かれるケースもしばしばあるようです。

== メリット ==
・デバッグの時間が短くなる
・要件への理解が早まる
・リグレッション（回帰）テストができる

== デメリット ==
・実践するには慣れが必要
・コーディング時間が伸びる
・テストするのが難しいこともある
・テストコードを保守する必要がある

バグは早めに潰す！テスト駆動開発(TDD)の概要とメリット・デメリット | tracpath:Works

3. 動作が決まっていないケースには使えない

もちろんですが動作が決まっていない処理を事前にテストコードを書いて実装する事は不可能です。また、テストをどうしてもやりにくい場合なども存在しているため万能とは言い切れないのがTDDです。

実際の開発現場では動作の決まっていない処理何かもザラにあるのでそういった場合は全然機能しないかもしれませんね！

4. まとめ

・慣れが必要
・動作を想定してもらえる
・一括テストがほぼ不要になる
・実装時間が増える
・テストコードの保守が必要になる