リーダブルコードも最終章に近づいてきましたね。
今回はテストコードについて。
以前のプロジェクトではテストコードを書いていたのですが、今携わっているプロジェクトでは書いてないです・・・
テストを書く目的ですが、単純にテスト工数を減らす以外に「本物のコードの動作と使い方を示した非公式の文書」という見方もありますね。先輩からも「仕様書の一種」といわれていたので、単純な動作確認以上の目的があるようです。
ポイントとしては下記のようなことが挙げられています。
Contents
重要な情報を目立つようにする
仕様がすぐにわかるような情報を書く、ということですね。
最適なエラーメッセージを書く
ディフォルトのExceptionのエラーメッセージに任せるのではなくて、エラー内容をわかりやすくカスタマイズしたメッセージを出力しよう、ということですね。これはテストコードだけではなく、普段のプログラムでもそうですねぇ・・・
テスト入力値は単純で網羅性のあるものにする
テストパターンの網羅ですが、下記3点が大切ですね。
- 漏れがないこと
- なるべく単純であること
- 一度に複数の仕様をチェックするよりは、複数に分ける
テストコードを意識した、コードにする
普段コードを書いているときから、テストコードを書きやすいコードを意識することが大事と書いてあります。
ポイントとしてはよく言われますが、疎結合にすることですね。プログラムがお互いに依存している場合、テストがとても面倒で大変になります。細かい部品群にわけてあればそれだけテストをするのが楽になります。
テストしにくいソースの特徴
- グローバル変数を使う
- 外部コンポーネントへの依存
- 各プログラムへの依存度が高い
テストしやすいソースの特徴
- クラスが小さい。内部状態を持たない
- クラスや関数が１つのことをしている
- クラスや関数が独立している
まとめ
これらがテストしやすいソースの特徴ですね。ただし、ほどほどに、ということはリーダブルコードでも書かれていますね。
私が依然かかわっていたプロジェクトでもテストコードのために時間を取られるという本末転倒な事象がおこっていました。どんなことでもバランスが大切です。
