skillup

技術ブログ

プログラミング全般

テストコードの考え方

投稿日:2015年4月7日 更新日:

一般的なプログラマにとって日々の業務で何がいやかというと、

  • 理不尽な納期
  • むちゃくちゃな仕様変更
  • 頻発するバグ・不具合

であることは異論がないでしょう。仕様変更や納期などは自分で何とかしがたい部分もありますが、バグに関しては自分の努力でなんとかしたいものです。

バグを減らすためにすべきことといえば、テストや検証作業をきっちりやることです。ただこれは「言うは易し、行うは難し」の典型的な例でしょう。

テストの大変さ

テストというのは大切であるにもかかわらず、

  • 単純作業の繰り返しで疲れる
  • 網羅性のあるテストを作るのは非常に大変
  • 修正のたびに全テストをすると天文学的な時間が必要
  • どこまでやればゴールかがわからない

など作業者にとっては精神的&肉体的な負担が大きい作業です。(※上記のテストは目視を前提にしています。)大切なことはわかりつつも上記のような点があるため納期がきつかったりするとテストにしわ寄せ(期間があまりとれない)がいきます。

テストコードの重要性

上記のテストのデメリットというのは全て人間が目視で確認することを前提にしています。1回1回、エクセルにチェックをしたりなど原始的な方法でやる場合ですね。原始的とはいいつつもいまだに主流なやり方かと思います。

テスト自体をプログラムにさせれば上記のデメリットは全てではありませんが解消されます。ただ、私自身は実装が全部終わってからテストコードを書くのは大変だなあ・・なんてトンチンカンなことを考えてました。

先日、社長(熟練のJavaプログラマ)とテストコードについて話していて、衝撃をうけました。

私「いやーテストコードって大切なのはわかりますけど実装全部終わってから書くの面倒くさくないですか?」

社長「? ひとつのメソッドを書き終わってテストコード書けばすぐにチェックできるし、デグレの心配もありませんよね?仕様が決まった段階で書いてもいいですが・・」

私「!!!!」

常日頃からテストコードを書いている方にとっては当たり前のことかと思いますが、私にとって「テスト=実装が全部終わってから1つずつやるもの」という認識があったため、天地がひっくり返るほどの衝撃でした。

上記のように1メソッドを書いた後にテストコードを書けば、そのメソッド単体のテストを行なうこともできます。私の場合、全てWEB案件で全てブラウザから値を直接入力してやっていたのでそのような発想にたどり着きませんでした。

テストコードを書くメリット

もともとテストのやり方(目視でチェックしていく)には疑問を抱いていましたが、テストコードというものをよく知らなかったり、上記のように実装全てが終わってからやるものと思っていたため、なかなか着手できずにいました。

ただ、短納期で高品質なプログラムを書くには必須の開発手法といえるでしょう。テストコードを書くメリットについて簡単にまとめさせていただきます。

メソッド単体で行なうため網羅性が高い

かつての私のように実装が終わってからテストを書きますと、随所で抜けが発生します。一般的に1つの機能は複数のメソッドが連動していることが一般的です。1つの実装が終わってからテストをすると、テストケースが無数になり、かなりの確率で漏れが発生します。

1つ1つのメソッドに関してテストコードを書いていけば、漏れの確率を大幅に減らすことができますし、結果として組み合わせにびびることもありません。

デグレの心配がない

修正がはいったとしても、テストコードを書いておくことで安心して改修に取り掛かれます。ものすごく汚いソースだけどすでに動いているからってことで修正できないソースが今まで何度もありました。

そのようなときに安心してリファクタリングできますね。

精神的に楽

メソッドを1つ書くたびにテストを書いておけば、「この処理は大丈夫」といった自信を持ちながら作業を進めていくことができます。納期がタイトだったり、処理が複雑な場合、この精神状態を保っておけるのは非常にありがたいです。

コードが綺麗になる

テストをする前提になりますとテストしやすいようなコードを書かなくてはいけないので綺麗なソースになります。テストを意識することで必然的に細かく分割され、引数と戻り値が明確に判定できるようなソースになるでしょう。

この様なメリットがあることから、テストコードは必須といえると思います。今年のテーマとしては開発体制を整えることが目的です。その中の1つがテストコードの実装です。

もちろん実際に作業をし始めると一筋縄ではいかない部分もあるとおもいますが、これだけメリットがそろっていることと、なによりバグを減らすにはこれしかないと思っています。

これを読んでいる方もテストコードの重要性に気づいてもらえたらうれしいです。

-プログラミング全般
-,

執筆者:


comment

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

関連記事

no image

変数の役割について

前回のエントリーの主眼は変数を置くことで、適切な情報量に分割し、コードを読みやすくしよう、ということでした。 今回はそれとは少し逆の観点でして、不要な変数を削除して、コードを読みやすくしよう、というこ …

no image

オブジェクト指向設計 依存関係の管理

オブジェクト指向シリーズ。読みにくい本が多い中でオブジェクト指向設計実践ガイドは勉強になるなー。 Contents1 依存関係の管理1.1 メモ1.2 実際のコーディング上のコツ1.3 感想 依存関係 …

no image

アプリケーション間のデータの連携方法に関して

以前やった「現場で役立つシステム設計の原則」を再読してます。 今、読んでいるのはアプリ間のデータ連携に関して。 複数のアプリ間でデータをやり取りする場合、以下のような方法が考えられます。 ファイルを直 …

no image

便利すぎる道具の弊害

現在、Javaのプロジェクトでは会社でNetbeansを使っていますが、IDEを使っているばっかりに理解できていないところがありました。便利すぎる道具の弊害ですね・・・ IDEについて一応説明をしてお …

no image

オブジェクト指向 データベース層

本日も引き続き「現場で役立つシステム設計の原則」を読み進めてます。 本日は主にデータベース層の考え方について。 Contents1 データべース層1.1 要点1.1.1 典型的なダメテーブル設計1.1 …