良いコードを目指して ~テストコードを考える~

テストはどんなエンジニアの方でも必ず通る道です。

実際にテストする場合には、画面や統合開発環境上で操作・実行して結果を確認することもあれば、jUnitのようなフレームワークを利用してテストをすることもあると思います。
(余談ですが私がメインで開発していたSalesforceもテストクラスなるものが存在します)

思い返すと、既に完成したテストクラスを見て"…何でこれを比較しているんだ？"となることがありました。

便利かつヒューマンエラーを発生させないためのテストクラス自体が理解し辛くては、思わぬバグを見落としてしまう可能性もあるかもしれません。

今回は、テストの際に利用するテストコードについても、良いコードにすることができないかを書いていきたいと思います。

テストコードを利用する目的

まずはテストコードを利用する目的について考えましょう。
目的というよりはメリットという表現が正しいかもしれません。

負担を減らす

作成・改修した１つ１つの処理について都度実行し、結果を確認していくことは非常に時間がかかります。
とても効率的な作業とは言えません。
テストコードを利用することで、ほぼ一瞬にしてテストを実施し更に結果まで表示をしてくれるのです。
テストコードによって、テスト実施者の負担を減らすことができるのです。

ヒューマンエラーを無くす

テスト作業は、開発規模が大きければ大きいほど膨大なケース量が必要となります。
１日に数十〜数百のテストケースを実施していれば、小さな不具合を見落としてしまう可能性もあるでしょう。
それではテストを実施する意味がなくなってしまい、終いにはまた１からテストをやり直し、なんてことも。
テストコードを用いてテストをすれば、プログラムが値を比較してエラーを吐き出してくれるので、人間による思わぬ見落としが無くなります。
良くも悪くも、プログラムのせいということです。(笑)

テストを固定化する

既存機能を改修したときに、その機能部分しかテストをしていなかった。なんてことが原因で他の機能がデグレーションしてしまうことがあるかもしれません。
そういったことを防ぐために、テストコードで実施テストを固定化するのです。
例えばA,B,Cという機能があり、それぞれの機能のテストコードが存在するとします。
機能Bを改修した後に、機能A,B,Cのそれぞれのテストコード実施結果が問題なければリリース可能と判断する。といった具合にシステムの信頼性の一つのハードル(指標)となります。

テストコードを利用する注意点

テストコードを利用する注意点について記載していきます。

テストコードの結果だけを見ない

上記の目的・利点を鑑みると、テストを実行していればそれ以外は必要なく感じるかもしれません。
しかし、それは危ないです。
システムのコードは、要望によって改修されていくものです。
しかしテストコードというものはシステムに直接影響のあるものではないため、必ずしも仕様に沿っているとは限らないのです。
そのため、テストを実施する際には全てでなくても良いのでざっとテストコードに目を通しておくべきでしょう。

読みやすく改修のしやすいテストコードを意識する

テストコードは１度きりのものでも無ければ、手を加えることも多くあります。
そのため、テストは読みやすくかつ改修がしやすいコードにすることがベストです。
参考書に書いてありましたが、テストコードは言い換えれば仕様書だ、と。
やっと本題に辿り着いたので、ここからはテストコードの書き方に注目していきましょう！

テストコードを書くときに意識すること

テストデータの作成をメソッドで用意する

テストコードを利用する際に、実際のプログラムが問題なく動作するかを確認するためにテストデータを用意することになります。
その際に、テストコードの大部分がテストデータの用意で埋まってしまっては非常に見づらいです。
テストデータの作成は、固定データを作成するよなメソッドやパラメータに応じたデータを作るメソッドを用意し、読み解くのに必要でない情報は極力メソッドに移しましょう。
また、上記を行うことで再利用化も実現できるので良いことだらけです。

テストコードは増えても良いので確認事項をシンプルに

確認事項1,2,3を全て１つのテストメソッドで確認するよりも、３つのメソッドに分けるように意識しましょう。
小さなテストを複数作る方が簡単且つ効果的であり、非常に読みやすいです。
更に後から手も加えやすいので、基本的に必要がない限りはシンプルなテストメソッドを心がけましょう。
しかし、状況に応じて多少複雑なケースはあるかと思いますので、そのあたりは臨機応変に....。

テスト機能に名前をつける

テストコードはメソッドになっていることが多いと思います。
１つの確認事項に対して、１つのメソッドが用意されているようなイメージです。
私が今までいた現場では半分くらいが、TestCase001(){・・・}のようなメソッド名になっていました。
実際に何をしているのかは中を見ないとわかりませんでした。
これでは、読みやすいコードとは言えません・・・。
テストメソッド(テストコード)には確認したいことがわかるように名前をつけましょう。
例えば、事業所コードに紐付く累計売上データの確認テストメソッドならば、どんな名前がいいでしょうか。
"Test_CheckTotalSalesFromOfficeCode"とかが適切じゃないかと思います！（FromはWithとかAttachでもあり？）
このような名前にすることで、テストをしているメソッドであることと、その中で何をしているのかが予測できます。
事前に予測できている状態でコードを見るのと、何も知らないでコードを見るのでは、理解度はかなり変わると思います。
中々面倒かもしれませんが、名前の意識もしていきましょう。

ここまでテストコードについて書きましたが、実際に簡単なことではありません。
事実、テストコードは本来のプログラムありきなものなので、そちらに左右されてしまうことも十分にありえるかと思います。
しかし逆を言えば、テストを意識してコーディングをすることで、よりテストコードが書きやすく読みやすくなるとも考えられます。
私自身もそんな余裕はあまりありませんが、テストを意識しながらコーディングをしていくのも良いのではないでしょうか！！