テストコードについてざっくり解説!

プログラムを作成する際、テストコードを作成することがあります。テストコードは作業工程が多いため、あまり制作に対して前向きな方は多くありません。

そこで、今回はテストコードの目的や制作のポイントなどについてお話ししようと思います。

ただし、テストコードの書き方や考え方には、派閥がある場合も少なくありません。ここで取り上げるのは、あくまで一例という認識を持ってください。

テストコードの目的

プログラミングをしているエンジニア

テストコードを作成するにあたって、漠然と作業を進める方は少なくありません。しかし、テストコードを作成する目的を理解すれば、より高品質のテストコードを作成できます。

以下では、テストコードの目的について解説します。

コードの動作確認

目的のひとつが、コードの動作確認です。

企業で扱っているプログラムのなかには、コードが4桁を超えるものも珍しくありません。コードが大規模になればなるほど、初見で問題点を発見するのは困難です。

そのため、テストコードを実行して、発見しにくい問題点を洗い出す必要があります。早い段階で問題点が見つかれば、納品するプログラムの品質が向上し、企業の信頼を獲得することにもつながるでしょう。

プログラムの仕様を理解する

テストコードには、プログラムの仕様に対する理解を深める目的もあります。

エンジニアは、扱っているプログラムがどのように動いているのか理解しておく必要があります。細かい仕様を理解せず、とりあえず動いているから問題ないと判断し、雑にプログラムを納品した結果、大きなトラブルにつながるケースも少なくありません。

プログラムの挙動を言語化できるようになれば、バグを減らせるだけでなく、エンジアとしても大きく成長できるでしょう。

テストコードの種類

テストコードは単体テスト、そして結合テストの2種類にざっくり分類が可能です。

2つのテストコードは、人によって粒度や作り方、考え方が異なる場合があります。そのため、プロジェクト内で統一できるように、最初に話し合っておくのをおすすめします。

それぞれのテストの詳細は、以下のとおりです。

単体テスト

機能単位の動作を確認するために、テスト工程で最初に実施するテストが単体テストです。現場によっては、ユニットテストとも呼ばれることもあります。

ソースコードが明らかな状態で実施するのが、ホワイトボックスステストです。ホワイトボックスステストでは、プログラムの内部構造に重点を置きます。そのため、プログラミングに対する深い知識と理解が必要です。

一方で、ソースコードが不明な状態で実施するのが、ブラックボックステストです。ブラックボックステストでは、入力と出力の整合性にのみ重点を置きます。コーディングの知識やスキルはとくに必要なく、ソフトウェアの動かし方さえ知っていれば誰でも実行が可能です。

結合テスト

単体で動いていたプログラムを、複数組み合わせて行うのが結合テストです。より本番に近い状況を設定し、プログラムが想定通りの動作をするか確認します。

結合テストには、インタフェーステストや負荷テストなどの種類があります。

テストコードを作成する際の流れやポイント

プログラミングをしている手元

テストコードは、種類によって作成ポイントや考え方が異なります。

単体テストと結合テスト、両者の作成ポイントと考え方の詳細は、以下のとおりです。

単体テストの場合

まず、単体テストを実施する際の対象は、基本的に1クラス1テストで考えます。1クラス1関数くらいの粒度で実装をしているため、1:1で作れるようになってるからです。ただし、repositoryなどでCRUDが1クラスに纏まってる場合は、規模によって1関数1テストの単位まで落とすこともあります。

次に、モックの有無です。モックを使用する大きなメリットとして、不具合の箇所が明確になる点が挙げられます。1クラス単位のテストで関連してるクラス類はモックにしているため、実際にテストが落ちたときの原因をテスト対象のクラスに絞ることが可能です。

デメリットとして、変更時の修正箇所が増える、後述する結合テストも含め2回テストを実行してるなどが挙げられます。モックの有無については、テストコードの制作者ごとに流派があるようです。気になる方は、調べてみると面白いと思います。

最後に、テストコードの書き方についてです。有名なものとして、同値分割や境界値分析などがあります。実際にテストを書く前に、テスト条件のマトリクスを作ってから進めると漏れが少なくなるため、最初に作っておくとよいでしょう。

結合テストの場合

結合テストは、単体テストと異なり大きなくくりでテストします。APIでいうと、1APIで1テスト程度の粒度で実行します。

また、モックを使用せずに実際の動きに近いテストを行うことで、単体テストで出なかったクラス間のやりとりなどの部分もテストが可能です。

書き方については、単体テストと同じくテスト条件を洗い出してやっていくのは変わりません。テストは重要な機能から始め、徐々に範囲を広げていきましょう。

その他テストコードのポイント

テストの実行頻度に関しては、ciなどで自動化してコミットごとに実施できるようにしておかないと、テストを作ってもその恩恵を得にくいです。

また、カバレッジを見てみると、テスト実施した際に動いたコードを教えてくれます。それを見ながら足りてないところを確認すれば、テストの抜けを減らせるでしょう。

まとめ

テストコードは、実装の2倍工数が必要といわれます。また、恩恵を感じにくいため、後回しになったり作業自体が辛くなりやすいです。

しかし、テストコードによって、プログラムの品質やデプロイの安心感を得られます。実装の段階でデグレにも気づけるため、頑張って作っていきましょう。

あわせて読みたい記事