小難しいことは抜きにして１０分で理解する単体テスト
2017.01.16:更新しました！
業務システムで単体テストを書いた事がない場合、どうやって書けば良いのか最初は全く分からないんですよね。特にVB6を始めとした企業向けのエンタープライズ系エンジニアは顕著です。
例えばサンプルとかを参考にしてみても、サンプルは汎用的な内容が多いので、「言いたいことは分かった。で？」となっちゃう。
知りたいのはそこじゃないんだ！もっと深い所なんだ、知りたいのは！なんならテストを書いてみてくれ！！と思うわけです。
結論を先に言いますと、「テストを書けない！」と言っている方は１００％を目指されている、もしくは目指さないといけない！と思っているのではないかと思います。
１００％を目指す必要はありません！
※ここで挙げる「単体テスト」は納品物である「単体テスト仕様書」ではなく、プログラムで書く単体テストを指します。
shin21.hatenablog.com
まずは小さい所から始める
僕自身もそうでしたが、凄く難しく考えてしまって「何処から手を付けて良いのか分からない」状態になります。
ですので、最初は何も考えずに取り敢えず１つメソッドなりクラスなりのコードを書いてしまいます。最悪はTrueが返るだけの簡単なものでもひとまずOKですので、とにかく一応は動くメソッドを完成させます。
次にそのメソッドに対するテストを準備します。ここでも取り敢えずテストがパスをする簡単なテストのみを書きます。
テストを動かすと、当然パスします。これでいいのです。
必ずパスするテストに意味はあるの？
もちろんですが、このままでは意味は全くありません。ここから肉付けをしていきます。
出来ればテストの方に、理想とする結果を書いていきます。その結果をパス出来る本番コードをメソッドに実装していきます。
仮に、「難しいな」と思う場合はメソッドの方を先に完成させて、パスするテストを書くという順番でも大丈夫です。取り敢えずコードに残します。
さて、メソッドが書けたらコードが動くか動作を確認する訳ですが、従来でしたらデバッグ実行でいちいちプログラムを動かして、確認するしか術は無かった訳です。
でも、テストを書くとテスト項目からお目当てのメソッドを直接呼び出せるので、デバッグ画面を開く必要性が無いのです。時短です。
また、確認する項目をコードに書いているので毎回同じチェックをする事が出来ます。
「いやいや、一度パスした内容なんだから毎回チェックなんて要らないでしょ」と思うかもしれません。
今は開発中なのでいいのですが、数カ月後数年後だとハッキリ言って覚えていません。でも、テスト内容をコードに残しておけば当時と同じ確認を常に出来る訳です。
テストは「同じテストを常に行う」為に行うのです。
小さな所から枝葉を広げていく
一つのメソッドが終われば、クラス全体へ。そしてそのクラスを呼び出している先へとドンドン派生していきます。
もちろん、全体の仕様を考えてトップダウンでテストを書ければ何も言う事はありません。
でも、単体テストが苦手・良くわからないと思っている人は「トップダウンでいきなり行おうとするので失敗する」傾向にあります。
ボトムアップで小さい単位から少しずつテスト範囲を増やしていく、という考えで一度テストを書いてみてください。
デバッグ部分であったり、ちょっとした動作を確認する箇所で「あれ？テストって便利だぞ」と気付く箇所が出てきます。その内、条件でテストパターンを増やしていけば、毎回分岐テストを行わなくても済むようになり、さらに「便利だぞ？」と思う範囲が増えます。
ポイントは、「テストって便利だな」と思うポイントを見つけることです。
便利だと分かれば、積極的にテストに取り組んでいけます。
最初は形とか１００％のテスト像を思い浮かべるのではなく、少しでも自分の作業が楽になるという観点で捉えてみてください。
Visual Studio の機能になりますが、コードカバレッジという物があります。
コード カバレッジを使用した、テストされるプロジェクトのコード割合の確認
どれだけテストを網羅しているかが測定できるのですが、この機能の便利な所はテストで通る箇所が色分けされるんです。
つまり、テストを書いていない条件分岐の箇所が一発で分かります。通っていない箇所が分かると、必ず通らせたくなりますよね？
そうなってくれば、自ずとテストを書くという事が苦ではなくなります。
私自身もまだまだ勉強中ですが、キッカケを掴むと単体テストを自主的に書くようになりました。
なんとなく「意味がないからしない」と思っている方は、一度騙されたと思って「簡単な所から」始めてみてください。