はじめに

開発者の多くは、テストに対して少なからず苦手意識を持っているのではないでしょうか。

テストは、問題がなければ工数がかかるだけの負担に見えます。
そして、いざ不備が見つかれば、問題を白日の下に晒されるため、「忌むべきもの」として感じられがちです。

つまりテストは、役に立ったときは厄介な存在に見え、役に立たなかったときは無駄に見える。
どちらに転んでも、あまり良い印象を持たれにくい性質があります。

QAから見た姿と、開発から見た姿との、テストのズレ

テストというものは基本的に 「バグが存在することの証明」 しかできません。

QAの立場にいた頃は「バグを発見し、報告する」ことが基本的な業務内容であり、
テストの性質には何の違和感もありませんでした。

しかし、開発の立場となった時、テストの存在が疑問になります。
「バグを見つけるため」にテストをするのは腑に落ちません。
テストする内容は考慮済であるからして、「バグを見つけるため」のテストとして考えるのは的を得ていません。

開発者が持つべきテスト観

テストというものは基本的に「バグが存在することの証明」しかできません。
しかし、「実行したテスト条件下と完全一致している」 のであれば「バグは存在しない」と言う事ができます。
ですが「実行したテスト条件下と完全一致している」ことは基本的にあり得ないために「バグは存在しない」証明とならず、一般的にこの方向性でテスト結果を用いられることはありません。

つまり、開発は「バグの存在」について論じるためにテストを使うべきではないのです。
使うべき方向性はシンプルで「どの条件で、どう動作するか」という仕様書としての役割です。
しかし、テストという名の仕様書は、社内に性能を開示するものでも、お客様に使用感を伝えるためでもないです。
あなたの考えが正しいと 「その機能を作るまでのすべての考慮とその過程を表し、それらの要件を機能が満たしていることの証明」 を行うのです。

開発者はどんなテストを書くべきか

あなたが考慮したすべてを書くべきでしょう。

「書いてあるコードを読めばわかる」とはよく言いますが、一見必要そうな処理が不要と判断して書かなかったことを自慢したくないですか。
「手順書に書いてあるから」とも言いますが、あなたが熟考を重ねた末に見つけたエッジケースへの対処を誇りたくありませんか。
あなたの全身全霊の結果を、余さず表せるのはテストです。

「テスト観点」などと呼ばれるものは「開発時に気を付けた事」とほぼ表裏一体である、と私は考えます。

さいごに：開発者のテストは「開発時に考慮した動作の全リスト」

テストを書いておくことで、他にも良いことがたくさんあります。
あなたの開発内容が正しいことを証明するため、テストを書きましょう。

もし自信が無いのであれば、やはりテストを書きましょう。
あなたがどこまで考えたのかが可視化され、考慮の抜け漏れを他の人が発見しやすくなります。