単体テストの話

 

こんにちは。
タイトルについて。

 ぼくの会社へ入社した友人から質問されたので書き書きします！

目次

そもそも単体テストってなんぞ？

作った個々のプログラムに対して『ちゃんと動くよね？』と確かめるテストです。

友人くんは車が好きなのでそっちで例えましょう。

車ってどうやって作られてる？

タイヤ、シート、ライト、ハンドル...などの個々の部品を組み合わせて作られてますね。

こいつらで言うと、

・タイヤは丸い？

・ライト、着くよね？

・シートはリクライニングできるよね？

・ってかハンドル切れるよね？

 などなど、ホントに基本的なことを確かめるのが単体テストと呼ばれるものです。

これがまたキツいんだ。

で、なにが必要なの？

 単体テスト仕様書が必須です。

・テスト番号

・確認項目

・前提条件

・実施方法

・予想結果

・実施結果

 といった内容がつらつらと書かれています。大体どこでもエクセルを使ってます。

 プログラム作成者がテスト仕様書を書き、テストも実施するのが多い気がする。

↓ テスト仕様書はこんな感じかな。

テスト仕様書通りに、ポチポチ実施していくのです。

今の現場でこんな感じで書いたら『細かいッスね』って言われた。いいじゃんね。

『書いた人以外でも実施できる』仕様書を心がけましょう。できない人多すぎ。

分かった。で、どうやるの？

書いてる通りにやれ！以上だ！

....ではなく、色々と準備をせねばなりません。

• テストケースに沿ったデータを作りましょう。
• テスト実施前のデータベース情報を取得しましょう。
• ログもテストケース毎に分けると、後で見やすいでしょう。

などなど。ここがイチバン面倒で大変だったりします。

準備できたおー

 やっとか！じゃあテスト開始だ！

 エビデンスは必ず取るんだぞ。

ただテストケースを消化するだけでオッケーではなく、第三者(リーダさんとか)に確認してもらう資料を用意せねばなりません。

『ちゃんとテストケースやったよ。オッケーだったよ。証拠(エビデンス)あるよ。』と示せるモノです。

エビデンス取るときに注意することあんの？

『他の人が見ても分かるようなエビデンスを取りましょう。』

テスト仕様書作成と同じ感じですね。

個人の能力によって理解できない要素は極力減らすべきです。

キャプチャーとかテーブルデータをドーン！と貼って終わりって人を見かけますが、頭おかしいんじゃねえの？って下に見てます。

↓こんなの

後から確認する人に『どこを見てほしいのか』が分かりません。

ぼくが確認する側だと発狂します。

じゃあどうすんの？

コメントを入れましょう！

↓こんなの

他人に見てもらうようなモノの場合、たった数秒の心遣いが工程をガッツリ減らすことに繋がります。

もっと複雑なエビデンスだと、で囲むとかするとさらにGOOD！

あなたの評価はうなぎのぼりだ！

ただし、凝りすぎて時間をかけるのはだめです。ほどほどにしましょう。

頑張ってるアピールをする必要はないのです。

さいごに

ぼくが気を付けてることを書きました。

参考になれば幸いでございます。

『誰が見ても分かるテスト仕様書を書く』

『誰が見ても分かるエビデンスを残す』

この2つを守るようにしてれば大体うまくいきますという経験談でした。