skillup

技術ブログ

プログラミング全般

テストコードの考え方

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

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

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

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

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

テストの大変さ

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

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

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

テストコードの重要性

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

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

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

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

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

私「!!!!」

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

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

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

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

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

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

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

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

デグレの心配がない

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

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

精神的に楽

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

コードが綺麗になる

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

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

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

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

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

執筆者:


comment

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

関連記事

no image

エラーレポーティングサービス Sentryについて

リリースした後、運用段階に入ると定期的にバグ報告が上がってきます。 本来はリリース前に検収テストをすべきなんですが、そんな余裕ないことも多い(汗) で、そんな時に大事なのが エラーを気づけること 対処 …

no image

設定ファイルの置き場所

一般的にレベルの高いソースとは保守性が高いものを指します。特にWEB系ですと仕様変更がしょっちゅうなので変更があったときにいかに少ない工数で対応できるかが大切です。 保守性をあげる工夫はいろいろありま …

no image

テスト項目の作り方(縦項目について)

テスト項目の作り方について。 単体テスト書のレビューをしていて、なるべく効率的に網羅的にできるテスト仕様書の作成について。 納品物としてではなく、開発の高速化と品質をあげるためのテスト仕様書を。 Co …

no image

メモリに関して 静的領域、スタック、ヒープなど

実務でメモリの調査をしましたが、肝心のメモリについてほとんどわかっていないのでメモ。 メモリの領域を大きく分けると静的、スタック、ヒープに別れる。 Contents1 静的2 スタック3 ヒープ4 そ …

no image

便利すぎる道具の弊害

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

アーカイブ