【実践技術書】初めての自動テスト

Webシステムの自動テストを初めたい人に向けた、考え方やフレームワークなどを紹介しています。

これから始めようという人にもちろんおすすめですが、ちょっとやってみたけどうまく行かなくてそれっきりという人にこそ読んでほしいです。

初めてテストを行う人向けで、システムテストの概要やWeb・ネットワークの基礎の情報が多めです。ユニットテストの章以外はプログラマの人にはちょっと物足りない内容かもしれません。品質管理の人にで、あまりシステムに詳しくない人にはとてもいい内容です。

テストの自動化には、少なからずプログラマの協力も必要になるので、プログラマの人もできれば全部読んでおきたいです。あちこちに書いてありますが、テスターと開発者の協調が必要です。

概要

テストのピラミッド

UIテスト、統合テスト、ユニットテストからなるテストのピラミッドを定義します。それぞれがどんなものなのか、どうやって進めていくのか、システムテストの概要を説明しています。
ユーザーインターフェイステストに触れる

UIテストについてです。どんなテストなのか、何をテストするのかといった概要です。
レガシーシステムにUIテストを追加する

HTMLの属性などが正しく実装されていない場合のDOMの指定についての情報です。IDEなどを用いて指定できると、テストが簡単に実装できます。
統合テストで点と点を結ぶ

統合テストについての導入です。HTTPリクエストについての情報と、RESTについての概要です。Webの仕組みに関するところなので、詳しければ飛ばしてもよいです。
RESTfulなWebサービスの統合テスト

RESTの各要求を試してみます。
ユニットテストで基礎を固める

ユニットテストについてです。開発者向けの内容になっていますが、それ以外の人にも得られる内容があるので、飛ばしながらでも目を通しておくと良いです。

ユニットテストの設計や実装というよりは、基礎の情報の紹介です。コードカバレッジとかそういった語句の説明です。
JavaScriptをつかったブラウザ上のユニットテスト

JavaScriptをつかってユニットテストを行います。結構ソースコードが多い章です。ブラウザ上で起きることをユニットテストの領域・範囲でテストします。
ピラミッドを登る

ここまでのテストを組み合わせます。ありがちな問題や、そのことへの対処方が書かれています。

UIテストが重くなり、ユニットテストが不十分になりがちです。逆ピラミッドのような上位のテストばかりが充実してしまう問題です。なんとか下の層でカバーできたほうがよいです。

ただ、それが必ず悪なのかは決めないほうがよいです。逆ピラミッドになっていても、ピラミッドそのものが存在しないよりはマシです。最初はそうなることもよく割ることですので、諦めずに改善を続けましょう。
プログラミング初級講座

コーディングスタイルや、名前の付け方などの考え方です。プログラミングの基礎的な話なので、普段ソースコードに触れないテスター向けの内容です。開発者にとってはそれほど新しい情報はありません。
テストを整理する

テストの設計についてです。ちょっと難しいですが、テストコードの構築についてもしっかり整理して設計しておくと管理が簡単になります。頑張っておいた方が後々ラクができます。
効果的なモックの活用

モックを使うことで簡単にテストができます。ただ、できれば本物のデータやオブジェクトを利用したほうがいいです。構築時には外からテストができるように実装ができると良いです。
テストファースト

テスト駆動開発についての章です。TDDの利点やプロセスを紹介しています。テストに対してより注目して、テストを先に実装する開発手法です。これによって必ずうまく行くわけではありませんが、一つの解決方法として強力なものです。開発者テスターともに参考にしていきたいです。

テストのピラミッド

基本的なことなのですが、システムのテストの概要としてピラミッドの構造を学ぶことができます。テストする上では最初に教えられるものかと思いますが、結構おろそかになっている現場も多いと思います。なんとなく初めてしまった人や、ツギハギでやってきた人などはここから勉強してみると良いです。

参考のプログラムはRubyとjavaScript

本の末尾に環境構築の応報が載っています。他の言語をつかっている方でも参考になる内容です。

この本はプログラミングをあまりやらないテスターの方向けの内容になっています。Webやシステムテストの基礎的な情報が多く、入門書といった内容です。より詳細なシステムテストの情報については、開発者が持っていると思いますので、そちらを見せてもらうのがおすすめです。

テストそのものが無いよりがマシ

特に印象に残っているのは「テストが良くない構造になってしまったとしても、テストそのものが無いよりはマシ」ということです。自動テストの導入は結構難しく、やってみたけどうまく行かないとか、運用されなくてほったらかしになるということが多いです。しかし、それでも全くのムダではなく、失敗を繰り返すことでより良いものができていきますし、無いよりはだいぶマシというのは本当です。