テスト駆動開発って良さそうだけど面倒そうですよね…
実際はどうなんですか？
慣れるまでは面倒に感じるかもしれませんね…
ソフトウェアの開発手法の一つにテスト駆動開発という物があります。
これはテストコードを先に書くことでプログラムの品質を高める開発手法になりますが、手順を見ると
- テスト内容を作成する
- テストコードを書く
- テストを失敗させる
- 最小限のコードでテストを通過させる
- プログラムを綺麗にする
ということで、とても面倒そうです。
これって本当にいい開発方法なの？メリットあるの？もしかしたらそんな疑問が湧くかもしれません。
今回は、開発歴約20年にも関わらずテスト駆動開発は未経験だった私が、テスト駆動開発を初めて経験した中で感じたメリットとデメリットをご紹介します。
「テスト駆動開発を試してみたい！」と思っているのであれば参考になると思うので、ぜひ最後まで読んでください！
ご確認ください
開発言語はC言語を使いました。そのため、他の言語の「メソッド」と呼んでいる物は「関数」と書いています。予めご了承ください。
用語説明
記事内の用語説明です。
| TDD | テスト駆動開発（Test Driven Development）の略 |
| テストコード | テスト用のプログラム |
| プロダクトコード | 製品用のプログラム |
| リファクタリング | プログラムを綺麗に整理すること |
この記事内では、上記のような意味で使っています！
テスト駆動開発のメリット
私がテスト駆動開発（以下、TDD）をする中で感じたメリットは次の５つです。
- プログラムが綺麗になる
- バグが混入しにくい
- デバッグが楽になる
- プログラムを安心して修正できる
- 技術力が上がる
他の方が挙げるメリットとあまり違いはないかもしれませんが、これはウソ偽りなく、実体験として感じたメリットになります。
それではそれぞれについてもう少し詳しくお話をしていきたいと思います。
1. プログラムが綺麗になる
まず、TDDを採用したことでプログラムが綺麗になったと実感できました。
なぜ綺麗になったのか？
理由は必要最小限のプログラムしか書かないようになったからです。
TDDでは、基本的に一つのテストにつき、プロダクトコードの動作を一つだけテストしていきます。動作を一つテストするだけなので、そんなに難しいプログラムにはなりません。
さらにTDDはテストを通過させるための最小限のプログラムを書くことがルールになるため、完成したプログラムはとてもシンプルで無駄がなくなります。
この工程を繰り返していくと、全体を通しても無駄の無いとても綺麗なプログラムになります。
私自身、TDDでプログラムが綺麗になるというのは半信半疑だったのですが、実際にやってみるとシンプルで分かりやすいプログラムなっていることを実感できました。
2. バグが混入しにくい
TDDを使って感じた２つ目のメリットはバグが混入しにくくなったことです。
なぜバグが入りにくくなったのか？理由はTDDをすることで発生した瞬間にバグを見つけることができるようになったからです。
バグは、プログラムは関数を新規作成した段階ではなく、プログラムを修正した時した時に発生することが多いです。つまり、プログラムの修正した時に、これまで作ったプログラムが全て正しく動作することを確認できればバグは入りにくくなるということです。
TDDはまさにこれを実行してくれます。
TDDでは、新しくプログラム書いてビルドをするたびにこれまで書いたテストを全て実行します。もし新しく書いたプログラムが原因で、これまで書いたテストが違う結果を返すようになったら、その時点ですぐにエラーとなって発見されるということです。
これによりバグが混入する可能性が大幅に減ります。
このメリットはすぐに実感でき、開発の途中段階で何度もテストのエラーにより、バグの混入を防ぐことができました。
3. デバッグが楽になる
TDDの３つ目のメリットはデバッグが楽になることです。
デバッグ作業と言うと、大きく分けて
- プログラムコードの確認
- 製品の動作確認
この２つがありますが、TDDはこの中でも「①プログラムコードの確認」の部分を楽にしてくれます。
TDDはテストコードを書きながら開発をしていくので、プログラムコードの確認は開発中に常に行っていることになります。つまり、プログラムが完成した段階で「①プログラムコードの確認」も終了するということです。
また、TDDで作ったプログラムはテストがしやすいよう設計されています。そのため、「②製品の動作確認」の段階においても、バグが見つかった時に、テストコードを使ってデバッグをすることもできます。
原因が推測できれば出現率の低いバグでも、新しくテストを作成してバグの再現することもできるため、デバッグ効率が大幅にアップします。
このようにTDDはデバッグにおいても、とてもメリットがある開発手法になります。
4. プログラムを安心して修正できる
TDDの４つ目のメリットはプログラムを安心して修正できることです。
- プログラムを綺麗に整理する
- バグが発生したのでプログラムを修正する
これらは開発をしていると必ず発生する作業ですが、締切が近くなると他のプログラムへの影響も考えながら修正をしないといけません。
- プログラムを整理したらバグが混入した
- バグを直したら他の箇所でバグが発生した
これはプログラマーあるあるだと思います。
このようにTDDを使わない場合は、開発終盤では不安を感じながらプログラムを修正することも少なくありません。
この点において、TDDでは、プログラムを直すたびに全部のテストを行うことになるため、バグが発生したらその時点でテストでエラーとなります。これにより安心してプログラムを修正できるようになります。
開発終盤のプログラム変更によるバグの連鎖は本当に地獄です。直してた時に他に出る影響を全てチェックできるのはTDDの大きなメリットだと思います。
5. 技術力が上がる
TDDを使うメリットの５つめは技術力が上がることです。
なぜTDDで技術力が上がるのか？その理由はTDDはプログラムの構成が悪いと成り立たないからです。
TDDでプログラムを開発しているとテストがうまく書けないことがあります。TDDにおいては、
テストがうまく書けない = プログラムの構成が悪い
ということになるため、テストをうまく書けるような構成を考えて修正していく必要が出てきます。
テストをうまく書くためにはプログラミングの構成や技術に関する知識が必須です。TDDをすることで、新しいプログラミング技術を学ぶ必要が出てくるため結果としてプログラミングの技術が高まることになります。
私もTDDを始めた最初はうまくテストができませんでした。その度に関数をどのようにすればいいのか、全体の構成をどのように変更すればいいのかを学び、考えながらプログラムを作成していました。
その試行錯誤の過程でたくさんの学びを得ることができました。自分が知らなかったプログラミング手法が必要になることもあるため、結果として技術力は向上したと思います。
テスト駆動開発のメリット：まとめ
以上５点がTDDをするメリットになります。
ここまで５つメリットを上げましたが、TDDのメリットは一つにまとめると、バグが入る可能性が低くなるということにつきます。
私自身もこれはものすごく感じていてい、上の５つの中では
- 2. バグが混入しにくくなる
- 4. プログラムを安心して修正できる
この２つのメリットを特に感じています。
例えば、開発をしていると何気なく修正した１行が原因でテストが通らなくなり、調べたらバグに繋がっていたということはよくあります。TDDでは、このような小さなミスを簡単に防ぐことができます。
また、プログラムをリファクタリング（整理）した時にバグってしまうこともあるのですが、TDDを使うようになってからは、リファクタリングも安心してできるようになりました。
結果として、以前よりも綺麗なプログラムが書けるようになりました。
ただ、TDDをしていると、メリットだけではなく、デメリットを感じることもあります。
それでは次は、TDDのデメリットについて解説をしていきます。
TDDのデメリットとは？
TDDはメリットばかりではなくデメリットもあります。
以下は私がTDDで開発をした時に感じたデメリットになります。
- 手順が面倒
- 難しい
- プログラムを書くのに時間が掛かる
- バグ無しを保証できるわけではない
それではそれぞれについてもう少し詳しくお話をしていきます。
1. 手順が面倒
私がTDDで感じたデメリットは手順が面倒ということです。
TDDの手順としては、
- テスト内容の確認
- テストコードを作成
- エラーを発生させる
- テストを成功させる最小のプログラムを作成
という手順になります。
このうち、「④テストを成功させる最小のプログラムを作成」がプロダクトコードの作成になるのですが、ここまでにやることがたくさんあります。慣れていない時や時間が無い時は、この手順１～３の工程がとても面倒に感じてしまいます。
更にTDDを完璧に行おうとすると、テストの量が多くなりがちです。ちょっとしたプロダクトコードを書くのにたくさんのテストを作成する必要も出てきます。
後々、バグが見つかった時はテストコードを書いておいてよかったと思うのですが、時間が無い時はテストコードの作成がかなり手間に感じることも多いです。
どんな時でも手順を守りながら開発する必要があり、それが時として面倒に感じる。
これが私が感じたTDDのデメリットになります。
2. 難しい
TDDの２つ目のデメリットは難しいということです。
TDDはテストをすることを前提とした開発になるため、どのようにしたらテストができるかを常に考えながらプログラムを作成する必要があります。
中には、テストさえしなければ簡単に書けるようなプログラムもありますが、そのような場合でも、テストコードを作成しないといけません。
私の場合、最初のうちは、
- 何をテストしたらいいか分からない
- 思ったようにテストができない
この２つの問題がよく発生しました。
TDDの考えでは、これらの問題が起こった時はプログラムの構成が悪い、ということになるため、違うプログラム構成を考えないといけません。この新しい構成を考えるのがとても難しく時間が掛かります。
簡単に書けるプログラムが時として難しくなってしまう。これも私がTDDをしている中で感じたデメリットの一つになります。
3. プログラムを書くのに時間が掛かる
TDDの３つ目のデメリットはプログラムを書くのに時間が掛かることです。
TDDはテストコードを書いた後にプロダクトコードを書くため、テストコードを書かない場合に比べてプログラム作成に時間が掛かります。
加えて２つ目のデメリットでも述べたように、テストを前提とすることでプログラムの難しさも増すため、慣れていないうちは思った以上にプログラム作成に時間が掛かることがあります。
一日掛けて数行しかプロダクトコードが書けなかった、なんていうこともありました。
このようにプログラムを書くのに時間が掛かってしまうのがTDDのデメリットになります。
4. 完璧なプログラムが書けるわけではない
TDDの4つ目のデメリットは完璧なプログラムが書けるわけではないということです。
TDDのメリットを見ると、
- TDDを使えばバグが発生したらすぐに見つかる
- プロダクトコードを常に完璧に保つことができる
と思ってしまいがちですが、実はそんなことはありません。
テストに漏れがあったり、テストする内容が足りていない場合は、もちろんバグる可能性もあります。
TDDを行うには、テスト内容を考える必要があり、良いテスト内容を考えるには程度の経験も必要です。しかし、慣れていないうちはどのようなテストをすればいいかも分からないし、どのようなテストをすれば効果的かも分かりません。
意味のないテストを書くこともあるし、テストに漏れがあり、結果としてバグが混入する可能性もあります。
このようにTDDは時間が掛かるけど、常に完璧なプログラムが書けるわけではないというのもデメリットの一つになります。
テスト駆動開発のデメリットのまとめ
以上、４点がTDDのデメリットになります。
TDDのデメリットは基本的にTDDの経験不足からくるものが多いです。実際に私も経験が足りないせいか、この４つのデメリットに苦しめられました。
でも、TDDに慣れてくると、TDDを難しく感じることも少なくなったのも事実です。
テストするべき内容も分かるようになってくるし、テストができない、ということも少なくなってきます。結果として、メリットの方だけが残るようになっていました。
TDDは、最初のうちは難しくて時間が掛かります。慣れるまでは非効率でデメリットも大きい開発方法であるということを覚えておいてください。
テスト駆動開発をするのにオススメの書籍は？
テスト駆動開発をやってみたいけど、どうやればいいのか分からない…
そんな時にどのように勉強をしたらいいのか、ということですが、個人的にはこの本がオススメです。
C言語を使って組み込み機器をテスト駆動開発する本になるのですが、この本ではTDDでやるべきことを詳しく説明しています。
ページ数が300ページ以上とかなりボリュームのある内容になっているのですが、前半の100ページ程度を読めばテスト駆動開発がどのような開発なのかしっかりと理解できます。
利用言語がC言語ということで、少し難しく感じるかもしれませんが、プログラムとしは簡単なので、プログラムの基礎的な知識がある人ならば理解できると思います。
実際にプログラム書かず読み物として読むだけでも学びが多い本だと思います。TDDに興味があるのであればぜひ一度手に取ってみてください！
まとめ：テスト駆動開発は使うべきか？
最後にまとめです。
テスト駆動開発は使うべきか？
この答えについて、私の考えでは使うべきだと思います。
理由としては、結果として高品質で綺麗なプログラムが作成できるからです。
バグらずプログラムは動けば問題ない、という考えもありますが、私はそれは違うと思います。
例えば、表面上はとてもきれいなスマホが中身を見たらあらゆる部品が雑に詰め込まれていたとしたらあなたはどう感じるでしょうか？
良い気分にはならないですよね。プログラムもこれと同じです。プログラムコードはプログラマーにとって製品です。その製品は不具合の無い綺麗な物にしないといけません。
確かに、TDDは経験が少ないうちは難しく、経験があってもTDDを使わない場合に比べてプロダクトコードの作成に時間も掛かります。
しかし、TDDを使えばバグの混入率も下がるし、高品質で綺麗なプログラムが作れます。加えて、デバッグも楽になるし、技術力も上がるというおまけ付きです。開発終了後の不安もTDDを使わない場合よりも圧倒的に少ないです。
このような理由から私はTDDは積極的に使うべきだと考えます。
ただ、TDDを使う場合は、上司や取引先に対して理解を得ておく必要があるとも考えます。理由としては、もし開発スケジュールがTDDを前提としていない場合、プロダクトコードの作成に時間が掛かり、スケジュールがタイトになってしまうからです。
上司や取引先がTDDの特徴を理解していないと仕事が遅いと認識されてしまう可能性もあります。そのため、TDDをする場合は、事前に理解を得ておいた方がいいでしょう。
TDDは、経験が足りていない間は苦労することも多い開発手法ですが、長い目で見るとメリットが多い開発手法です。
今、あなたが使うか検討をしているのであれば、ぜひ一度試してみてその効果を実感してみてください。
最後まで読んでいただきありがとうございました(^^)
