開発が中心になって単体テストを自分で書くことが少なくなりました。
個人開発している分ではざっくりとしたテストは行いますが、資料として作成することはありません。一応テストコードは作成するようになりました。
久しぶりにテストをすることになり、人の書いた単体テストをしてみると自分は案外ちゃんとしたテストを教わったのかもしれない。と思うようになったので書いてみます。
単体テスト
単体テスト、結合テスト、総合テストなどテストの種類はいろいろとあると思います。
webの単体テストは画面ごとの機能におけるテストで、表示が正しいか、登録できるか、入力チェックなどテストの内容は細かいものになると思います。
テストはプログラムを書く人でないと書けないか。というと、そうではなくプログラムができなくてもテストだけ書くこともできます。テストは仕様を理解して、ちゃんと期待通りに動いているかを確認する工程のため機能を理解していれば書くことが可能です。
じゃあ、仕様を理解している人が優れたテストをかけるかというと、個人的には違うと思っています。
個人的にはテストの経験が多い人や失敗が多い人ほど優れたテスト、必要なテストを書いている印象になります。
なぜか。というと、テストをしてリリースしても不具合を出ることを経験しているので、次のテストで同じ不具合を出さないようにテストケースを作成するからでしょうね。
単体テストをちゃんと行うほど、残念な不具合は減ると思います。
今回テストをおこなっていて足りないと思った内容を書いてみます。
境界値テスト
入力値のテストや検索入力の境界テストです。「=」があるかないかで挙動が変わるためです。
例). 公開日のある一覧のテスト ・公開開始日の昨日 -> 一覧で表示される ・公開開始日の当日 -> 一覧で表示される ・公開開始日の明日 -> 一覧で表示されない
例). 入力欄 数値の1 以上 100以下の入力制限 0を入力 -> エラーが表示され登録できないこと 1を入力 -> 登録できること 2を入力 -> 登録できること 99を入力 -> 登録できること 100を入力 -> 登録できること 101を入力 -> エラーが表示され登録できないこと
min, maxテスト
入力制限のmin, maxまで入力して、登録できるかのテストです。
inputに入力できても、登録できないことケースや、計算結果が予期しない値になるケースがあります。
新規登録、更新のテスト
新規登録と編集の場合でプログラムが違う場合があります。
また編集時に新規で登録されるケースもあり、編集時のテストも必要になります。
新規登録時には表示が正しくても、編集時に登録されたデータが表示されていなかったり、登録できないケースがあります。
条件がある場合
設定値で表示されたり、入力できるケースがあったりします。
テストで条件の記述がなく、「表示されていること」だけある場合、人によりテスト結果が異なる結果になる可能性が発生します。
条件により変わる場合は、ちゃんと条件を記載して、他の人がやっても同じテストを実施する工夫が必要になります。
粒度について
一つのテストで、複数のテストが含まれているケースは単体テストとしてはあまり良くないことです。
簡易入力をクリックした場合、 詳細入力欄を非表示とすること。簡易入力欄を表示すること。 詳細入力をクリックすると、 詳細入力欄を表示すること。簡易入力欄を非表示とすること。
・簡易入力をクリックした場合、簡易入力に切り替わること。 ・詳細入力をクリックした場合、詳細入力に切り替わること。 ・簡易入力の場合、簡易入力欄が表示されていること。 ・簡易入力の場合、詳細入力欄が非表示になっていること。 ・詳細入力の場合、詳細入力欄が表示されていること。 ・詳細入力の場合、簡易入力欄が非表示になっていること。
これくらい分けてもいいと思います。
テストの難しさ
プログラムや設計の本も多いですが、テストについて詳細に書いてある本もあります。
それくらい必要な知識になりますが、テストを実施する。という意味では実施できる人が多くなるため、あまり重要とされないこともあります。
久しぶりに人が書いたテストを実施してみましたが、ちょっと足りないと感じたため結合テスト?かシナリオテストか確認したぐらいですが、単体テストであっていました。
テストが多くなると時間もかかるため時間との兼ね合いで必要なテストのみを書いた可能性もありますが、不安にはなりました。
テスト自体を大丈夫か不安になるぐらいには自分がいろんなテストをしてきたんだとも感じましたね。
会社でテストしていた時は、開発とテストが1対1ぐらいの時間がかかっていたこともあり、しんどかった記憶はあります。一つエラーがでるだけで、全部やり直しとかよくやったなー。
まぁ、受託案件の場合は不具合が出た場合にすぐ修正する。等ができないし、瑕疵などを言われるため、テストをがっちりやる必要があったとも言えます。
サービスを作る側になってからは、機能リリースを優先して不具合は出たらすぐ直す方針になっていたため、お客さんに恵まれていたと思います。
どういうテストがいいかはそれぞれの会社の方針があると思いますので、個人的な経験でのテストについて考えてみた内容でした。
一応、どんな経験でも活きることがあると思えた出来事でした。