【システム開発】テストコードを書くことの5つのメリット、デメリット、テスト駆動開発

システム開発においてテストコードを書くことは非常にめんどくさいですがいくつかのメリットがありますのでご紹介いたします。

これらのメリットを知ってゆくゆくはTDD（テスト駆動開発）等の開発手法も行えるようになると良いと思います。

テストコードを書く5つのメリット

• 長く使っていくアプリであればテスト全体にかかる工数の削減
• 変更を気軽に行えるようになる。
• 仕様変更の影響を簡単に把握できる。
• 仕様書やドキュメントとしても使える。
• 通常のコードが綺麗になりやすい。

変更を気軽に行えるようになる。

環境要因のバージョンアップやリファクタリング作業を頻繁に行える。

例えば、Railsで言えばRails自体のバージョンアップやgemはすぐにバージョンが上がってしまいます。その中にはクリティカルなセキュリティパッチとかも含まれていてアップデートを行わざるおえなかったりする場合も多いです。

この環境のバージョンアップを行う上での動作確認に関しては自動テストを行う仕組みがあるかどうかはかなり重要になることは想像が容易につくでしょう。また、ソースコードのリファクタリングをしたい場合でも同様です。

仕様変更の影響を容易に把握できる。

例えば、何何の機能を改修したいとなった場合に試しにあえてエラーになるような修正をして自動テストを実行すればそのエラーの件数によって簡単に影響を把握することが可能です。自動テストがない場合はいちいちソースを検索したりして目視で影響を把握しなければなりません。

仕様書として機能する。

入出力の結果がテストコードを読めばすぐにわかるので仕様書としても使えます。しかもテストコードは検証済みなのであれば普通のドキュメントよりも確実になります。（普通のドキュメントだと全て人手を介して修正しているのでミスがあったり一部仕様がふるかったりするのがざらにあります。）、Railsの代表的なテスティングフレームワークのRspecなんかはこの仕様書としての役割もかなり追求したフレームワークではあります。

通常のコードが綺麗になりやすい

テストコードだけではなくテスト対象のソースコードもテストがしやすいように粒度を分けて記述することを意識するようになるので綺麗になりやすくなります。

テストコードを書くことでのデメリット

メリットばかりではありません。下記のデメリットもあります。

• テストコードを記述する工数がかかる。
• 仕様の変更でテストコードを修正しなければならなくなる。

最初から全ての機能のテストコードを記述するのは現実的ではないかもしれません。まずは主要機能のテストコードから優先して記述するようにしましょう。

TDD(テスト駆動開発）とは？

実際に動く納品するプログラムから作成していくのではなく、テストコードから作成していく開発手法です。

ただ、特定の条件が揃わないと実施しない方が良いため、基本的に業務ではあまりこの手法で開発することはないと思います。

TDDで開発した方が良い条件

• プログラムのインプットとアウトプットが明確である場合
• テストコードの書き方が最初からイメージできる場合

開発サイクル

1. 先にテストコードを書いて失敗させる。
2. テストが成功するような最小限のコードを書く
3. リファクタリングする。