英タイトルは「The Way of the Web Test ~A beginner’s Guid to Automating Tests~」である。
テストのピラミッド
UIテスト | システム全体をE2Eで操作するテスト。 UIからプレゼン層、ビジネス層、データ層までアーキテクチャの全層を対象とする。 低速であり、遅い。壊れやすい。 |
統合テスト | フロントを除く、API全体を疎通させるテスト。 API全体が繋がって動いていることを確認する。 |
ユニットテスト | メソッド単位、クラス単位など、最小単位のテスト。 高速である。厳密に「どこ」が壊れているかわかる。 |
親指の法則
1.UIよりもユニットテストを優先すること
1翔 テストのピラミッド
2.ユニットテストで埋められない部分を統合テストでカバーすること
3.UIテストは限定的に使うこと
ユニットテストについて
ユニットテストの目的
- 設計を正しく反映しているか確認する。
- 最後の変更で何かを壊していないか確認する。
ユニットテストのメリット
ユニットテストが適切に組まれているとどんなメリットがあるか。
- 素早い変更を繰り返すことができるようになる。
- 手軽に作成できる。
- 正確な結果(原因箇所が明確であること)を出せる。
ユニットテストの組み方
クラスのpublicメソッド単位でテストケースを作成する。
次の観点で確認するためのコードを書くと良い。
- 最もシンプルな正常系が期待通りに動くか。
- 特殊な条件や境界値などが期待通りに動くか。
- 例外処理が期待通りに動くか。
- 条件分岐や繰り返し処理は適切に動くか。
- その他…このメソッドが正しく動いていることに自信を持つには、どんなテストケースが必要か?
統合テストについて
統合テストの目的
- ユニットテストではわからない、ユニットを組み合わせた時に適切に動くかを確認する。
統合テストのコードの流れ
GETメソッドのテスト
GETメソッド、主にデータ取得処理のテストコードはこうなる。
- GETメソッドを実行する。
- レスポンスに想定内容がセットされていることを確認する。(想定内容の一部で良い)
- レスポンスのステータスコードが200であることを確認する。
POSTメソッドのテスト
POSTメソッド、主にデータ登録・追加処理のテストコードはこうなる。
- DBの対象テーブルを検索し、登録内容がないことを確認する。
- POSTメソッドを実行する。
- DBの対象テーブルを検索し、レコードが作成されたことを確認する。
- レスポンスのステータスコードが200であることを確認する。
PUT/PATCHメソッドのテスト
主にデータ更新・編集処理のテストコードはこうなる。
- DBの対象テーブルを更新後の値で検索し、対象がないことを確認する。
- PUT/PATCHメソッドを実行する。
- DBの対象テーブルを更新後の値で検索し、対象が存在することを確認する。
- レスポンスのステータスコードが200であることを確認する。
DELETEメソッドのテスト
- DBの対象テーブルを検索し、削除対象が存在することを確認する。
- DELETEメソッドを実行する。
- DBの対象テーブルを検索し、削除対象が存在しないことを確認する。
- レスポンスのステータスコードが200であることを確認する。
UIテストについて
UIテストの目的
- ソフトウェアの主要な機能が常に稼働していること(システムの持続性)を保証すること。
- アプリケーションが適切にデプロイされていること。
- 環境が適切に設定されていること。
- パーツが正しく接続されていること。
UIテストのコードの流れ
ログインの手順を自動化すると、こんな流れになる。
- ログイン画面を開く
- メールアドレスを入力する
- パスワードを入力する
- ログインボタンをクリックする
- Welcomeメッセージが表示されていることを確認する
これによって、UI〜サーバサイドの全層が正常に稼働していることが確認できる。
UIテストのコード作成時のポイント
- HTMLのid属性による選択をするのが良い。
- HTML要素の存在をチェックするときは、値と完全に一致することを確認する必要はない。
- メッセージをチェックする場合、メッセージに使用するclass属性があれば、class属性の属性値が合っていれば良い。メッセージの中身まで合っているか確認しなくて良い。
- UIテストは脆弱で壊れやすいため、詳細な確認になり過ぎないよう気をつける。
現場で遭遇しそうな疑問
テストコードの中で通過するコードが重複している部分がある。無駄ではないか?
>テストの意図が重複していなければ、コードが重複していることは全く問題ない。
キャプチャーリプレイ(自動記録と再生)ソフトを使ってUIテストを組むのはどうか?
>大抵はうまくいかない。UIのほんの一部を変更下だけでテストが壊れる。ソフトが生成したテストコードは人間にとって読みにくい物になりやすく、可読性が下がる。
コードカバレッジの目安は?
>優れたチームは、たいていカバレッジ70%~80%くらいのどこかに落ち着きます。
感想
平易な文章ですらすら読み進められ、3時間ほどで読了できた。
自動テストについて体系的に俯瞰したいという点では物足りなかった。
実践的な内容になっているかという点でも物足りなかった。
テストをしない人が自動テストっておおよそこんなものって知るための読み物にはいいかなと思いましたが、実案件で使えるレベルの知識が欲しい人は他の同ジャンルの本を読む必要があると思います。