リーダブルコード：14章 優れたテストコード

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

上記書籍をまとめと自分の考えを記載します。

本書で紹介されている優れたテストの書き方について補足を入れて記載します。

必要なことが簡潔に書かれているテストは理解しやすい。

どうでもいいことがたくさん書いてある（目に見える）テストは理解しづらいです。

前準備や後処理などテストと直接関係のない（どうでもいいこと）はヘルパーメソッドを使って隠蔽すると良いです。

また、一目見て「このテストは何をテストしているか？」理解できるテストコードが優れていると思います。

テストが簡単に追加できる。

テストケースが漏れていた場合に簡潔に追加できるように、必要に応じてヘルパーメソッド等を用意しておきましょう。

そうでなければ、コピペでテストケースが追加されてしまい、重複の多いコードになり理解しづらいコードになってしまいます。

役に立つ失敗メッセージを出力する。

役立たない失敗メッセージしか出力しないテストでは、ステップ・バイ・ステップでのデバックが必要になってしまい、修復に多くの時間がかかってしまいます。

テストが簡単に追加できる。

テストケースが漏れていた場合に簡潔に追加できるように、必要に応じてヘルパーメソッド等を用意しておきましょう。

そうでなければ、コピペでテストケースが追加されてしまい、重複の多いコードになり理解しづらいコードになってしまいます。

一度にすべてのことをテストをしない。

一度にすべてのことをテストしてしまうと、そのテストが失敗した原因の特定に多くの時間がかかってしまいます。

また、テストコードの可読性が下がり、テストコードにバグが入り込んでしまうリスクも高まると思います。

テストの入力値が単純である。

単純でない入力値は読み手の混乱させます。

例えばマイナスの値をテストする場合に「-9999.0099」ではなく単純な値の「-1」を使用しましょう。

テスト関数の名前からどんなテストか理解できる。

テスト関数の名前はコメントのようにどんなテストから理解できる必要があります。「Test1()」のような名前は避けましょう。

また、私はテスト関数は他から呼ばれることがないという理由でテスト関数の名前に「日本語」を使用することには賛成です。

テストケースが十分である。

テストケースに漏れがあるとバグが入り込むリスクが高まります。

境界値分析などのテスト技法を使って、テストケースを考える必要があります。