C# テスト駆動開発の実践方法:テスト駆動開発のメリット・デメリット #2

当連載ではC#を使って「テスト駆動開発」を行っていくために基礎知識や方法を解説していきます。前回は導入部分としてテスト駆動開発についてと、テスト駆動開発を学ぶ理由について紹介しました。これまでのアーカイブは「C# テスト駆動開発の実践方法」から確認することができます。

今回はこの記事では「テスト駆動開発のメリットとデメリット」を紹介したいと思います。テスト駆動開発を実践するうえで、どのような効果があり何がネックになるのかを知っておくと、開発手法の引き出しが増えるので重要です。

テスト駆動開発のメリット

まずはテスト駆動開発を行う上でのメリットを紹介していきます。テスト駆動開発の主なメリットは「安心」という言葉がぴったりかもしれません。常にテストを行いながら開発を進めていくのが大きなメリットになると考えています。

1.バグへの不安が減る

テスト駆動開発はテストファーストな開発手法であるため、バグへの不安が大きく減ることを意味します。プログラマーであればバグのすべてを消し去ることは難しいのが共通認識だと思いますが、それでも極力発生するバグは減らしたいというのが本音です。

その点、テスト駆動開発はテストと実装を短いスパンでこなしていくため、各機能に対するバグへの不安を取り除くことができます。バグのない細かい部品を集めていけば、組み合わせさえ間違えなければ、おのずとバグは減っていきますね。

またバグを潰しながら進めていけるので、不具合を後工程に残さずに先に進めることができます。目の前のテストを攻略することを主眼に開発を行っていく手法ならではのメリットと言えるでしょう。

2.機能をしっかりと捉えられる

テスト駆動開発はテストを先に書くため、要件・機能をしっかりと理解しておかなければなりません。理解が不足していれば正しいテストケースを書くことができないからです。要件や機能を理解しながら進めることができるので、アプリケーションへの理解も深まっていきます。

いくらプログラマーとして働くとはいえ、技術ばかりに気を取られるわけにはいかず、お客さんのビジネスもしっかりと理解しなくてはなりません。そういう点から言えば、機能を理解してテストを書いていくことは、要件や機能に対する理解を深めてから実装するという段階を踏むことになります。

アプリケーション開発をするうえで、構築対象をしっかりと捉えることは長期的な開発を見据える上で必要なことであると言えますよね。テスト駆動開発はそういう点を考慮した開発手法、と言えるでしょう。

3.快適な開発ができる

これは個人的な意見も入ってきてしまうかもしれませんが、テスト駆動開発でアプリケーションを構築していくと、「快適」に実装を進めることができます。その理由は多分、「テストに通る」という心理的な安心があるからだと思います。

自分が想定した結果の通りにコーディングを行い、その結果を即座に評価してリファクタリング・次の実装に移れるというのは「不安要素」を引き継ぐことなく実装を先に進められるからだと思います。

テスト駆動開発を学ぶことでコーディング作業に明確性を持つことができ、自分が行うべき内容を明確にしながら作業ができるのが大きなメリットと言えるでしょう。例え自分が書いたテストコードでも、テストがちゃんと通れば嬉しくなるものです。

またテストは何度でも実施できるので、ソースコードの修正を行ったとしても機能を保証できるのも「快適」に開発が進められる理由なのかもしれません。例えそれがユニットテストであっても「テストに通る」というのは嬉しいものなのです。

テスト駆動開発のデメリット

さて、ここまでテスト駆動開発のメリットを大々的に書いてきました。まるでテスト駆動開発は完璧なように聞こえているかもしれませんが、実はそうでもありません。メリットもあればデメリットもあるのは万物に共通することです。

ということで、次はテスト駆動開発のデメリットについて触れていきたいと思います。テスト駆動開発はテストを行うことで得られるメリットもありますが、テストを行うことで発生するデメリットもあるのです。

1.コード量が約2倍になる

率直にいってしまうと、テスト駆動開発はテストファーストな開発手法なので、テストコードを書かなくては始まりません。要するにテストコードの分量とプロダクトコードの両方のソースを記述する必要があるということです。

あまり厳密ではないと思いますが、実感としてプロダクトコードで記述した分量と同じくらいのテストコードを記述する必要があります。ということはコード量が簡単に考えると約2倍になってしまうというのがデメリットになります。

イテレーティブな開発現場で、しっかりと納期までの期間が確保されている場合はよいのですが、スケジュール的に厳しい現場ではテストコードを書いていく時間は少なくなるのが現実です。

テスト駆動開発は素晴らしいアプローチですが、それはあくまでも「労力に見合うだけの時間がある」ということが前提になると言えるかもしれません。ピンポイントで特定の機能を実装するときだけテスト駆動開発を組み込んでいく、みたいなパターンがあると思います。

2.メンテナンスが大変である

テスト駆動開発ではテストファーストな開発手法でありますが、それは機能・要件が決まったうえで導かれる「結果ありきの開発スタイル」です。ということは、導くべき結果が変わってしまえばテストの期待値も変わっていくことを意味します。

要件や機能が修正されてしまった場合、過去のテストコードは完全とは言えないモノになり、新しい要件や機能に合致した内容に書き換える必要があります。要するにテストコードもメンテナンスしていかなければなりません。

数多くの要望が入り混じるような現場では、テスト駆動開発で開発を進めていくのが難しい場合があるかもしれませんので、やはりテスト駆動開発は万能とも言えないということになります。テストコードも常にメンテナンスしなければならない、というのがデメリットなのです。

テスト駆動開発をどう使うか

テスト駆動開発のメリット・デメリットを見てきました。メリットの側面だけに光を当ててみると、テスト駆動開発は素晴らしい開発手法の一つであることは間違いありません。しかしながら、それ相応のテストコード記述してメンテナンスを続けるのは容易なことではありません。ましてや納期が厳しい案件においては、現実としてテストコードを記述する工数すら取れないような場合もあります。

とはいえ、テストコードのメンテナンスも行いながら開発を続けられる場合は、「テストコード自体が要件・機能を示す優れたドキュメント」になる可能性もあります。適切にメンテナンスが行われているテストコードは、要件・機能の結果を映し出したものになり、機能の修正箇所を特定するのに役に立つ羅針盤にもなり得ます。

以上から、テスト駆動開発は優れた手法であることは間違いありません。しかしながら、それ相応のコストが求められるのも事実になります。テスト駆動開発を「どうやって開発に組み込むか」というのが重要になるかなと考えています。