skillup

技術ブログ

プログラミング全般

テストコードを読みやすくする

投稿日:

リーダブルコードも最終章に近づいてきましたね。

今回はテストコードについて。

以前のプロジェクトではテストコードを書いていたのですが、今携わっているプロジェクトでは書いてないです・・・

テストを書く目的ですが、単純にテスト工数を減らす以外に「本物のコードの動作と使い方を示した非公式の文書」という見方もありますね。先輩からも「仕様書の一種」といわれていたので、単純な動作確認以上の目的があるようです。

ポイントとしては下記のようなことが挙げられています。

重要な情報を目立つようにする

仕様がすぐにわかるような情報を書く、ということですね。

最適なエラーメッセージを書く

ディフォルトのExceptionのエラーメッセージに任せるのではなくて、エラー内容をわかりやすくカスタマイズしたメッセージを出力しよう、ということですね。これはテストコードだけではなく、普段のプログラムでもそうですねぇ・・・

テスト入力値は単純で網羅性のあるものにする

テストパターンの網羅ですが、下記3点が大切ですね。

  • 漏れがないこと
  • なるべく単純であること
  • 一度に複数の仕様をチェックするよりは、複数に分ける

テストコードを意識した、コードにする

普段コードを書いているときから、テストコードを書きやすいコードを意識することが大事と書いてあります。

ポイントとしてはよく言われますが、疎結合にすることですね。プログラムがお互いに依存している場合、テストがとても面倒で大変になります。細かい部品群にわけてあればそれだけテストをするのが楽になります。

テストしにくいソースの特徴

  • グローバル変数を使う
  • 外部コンポーネントへの依存
  • 各プログラムへの依存度が高い

テストしやすいソースの特徴

  • クラスが小さい。内部状態を持たない
  • クラスや関数が1つのことをしている
  • クラスや関数が独立している

まとめ

これらがテストしやすいソースの特徴ですね。ただし、ほどほどに、ということはリーダブルコードでも書かれていますね。

私が依然かかわっていたプロジェクトでもテストコードのために時間を取られるという本末転倒な事象がおこっていました。どんなことでもバランスが大切です。

 

-プログラミング全般
-

執筆者:


comment

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

関連記事

no image

オブジェクト指向について その3

今回は場合分けによる変更コストとオブジェクト指向のメリットについてです。 例えば給付金が発生して、その金額を死亡時、退職時、通常時で場合分けするとき、if-elseで書けば下記のようになります。 [c …

no image

ファジープロジェクト対策 その2

前回に引き続き、大事だと思ったこと。一部単なるフレームワークの作り方的な内容になっているかも。 Contents1 テンプレート共通化2 バリデーション3 ログ出し4 異常系の処理5 新規プラグイン+ …

no image

ダミーデータの作り方 まとめ

現在作っているアプリを顧客先で見せる機会があり、そのためダミーデータを入れる、という仕事がありました。 といっても画面からポチポチやったんでは時間もかかりますし、何より精神的にやられてしまいます。(汗 …

no image

オブジェクト指向設計 ダックタイピング

オブジェクト指向シリーズ。ダックタイピング・・読む前は名前は聞いたことあるような気がする・・程度で細かいことは何一つわからない状態でした。今回具体的なコード例があった分イメージを何とかつかむことはでき …

no image

フレームワーク作成時の注意ポイント

以前も多分書いていますが、フレームワーク作成時のポイントなどを列挙。 次元が違うものも多々含まれているかも。 ルーティング機能 基本設定情報の読み込み キャッシュ機能 データベース Form情報の管理 …