テストコードを書くということ
ソフトウェア開発において、
ソフトウェアの品質を確保するためのテストは欠かせません。
「テストがないソフトウェアはレガシーコードだ」という言葉もあるように
プログラム製造時に対応するテストコードを書くことは当たり前になってきたように感じられます。
しかし、ただテストコードを書けばよいというわけではありませんし、
どんな場合もテストコードを書きテストを自動化することが有効かというと
一考の余地があるように思えます。
テストコードを書くメリット、デメリットとして以下があげられます。
<メリット>
- プログラムに修正が生じてもテストコードがあれば、修正確認がしやすい。
テストコードを再利用してデグレード確認、リグレッションテストができる。 - テスト作業の省力化。
- テストコードを再利用することで、
長い目で見ればテスト工数削減が期待できる。
<デメリット>
- 工数がかかる。製品コードと同程度かそれ以上のテストコード作成工数がかかることが多い上に
製品コードとともにテストコードをメンテナンスする工数もかかる。 - 開発者は製品コードに加えテストコードも理解する必要がある。
(既存プロジェクトの新規参入者に当てはまることが多い)
テストコードに対する理解がブラックボックス状態だと、テストをパスすることを目的としがちになる。 - 機能仕様に満たすことを確認できるテストでなければ、品質は確保されない
適切なテストでなければ、テストをすべてパスしても品質が確保されたといえない。
以上を踏まえると
- 開発の過程でテストを繰り返すことがあり、
それが自動実行することが可能なものならば
テストコードを書き、テストを自動化しておくことに意義がある
以前のブログで述べたアジャイル開発のような短い開発サイクルを
繰り返すようなプロジェクトやリリースが頻繁にあるプロジェクトでは、
テストを自動化することに向いている。
このようなプロジェクトでは、長い目で見れば、
手動でテストを実行するコストよりも
自動化するコストの方が小さくなる可能性がある。
- テストの自動化を導入するならば、コストがかかるという前提で開発計画が立てることが望ましい。
- よいテストコードを書くには、機能仕様の理解、相応の技術力が必要である
というようなことが言えると思います。
テストコードを書きテストを自動化するのは手段であり、
よいテストを実施することによって
品質を確保できるという考えを持つことが重要だと思います。
