【読書記録】Compete Guide to Test Automation (3)

person reading and praying

前回の投稿はこちら。ようやっと読了したので、9章以降の概要と感想をまとめる。9章以降は第2部となっており、テスト自動化の「How」について各章にて説明されている。

9章 Preparing for the Tutorial

この章以降、チュートリアル形式での説明となるため、チュートリアルの概要と、テスト自動化プロセスの概要が述べられている。チュートリアルは、MVCForumというOSSのプロジェクトを対象として、実際に.NETでテストコードを書いていく形式。

自動化プロセスにはボトムアップ戦略とトップダウン戦略がある。テストケースを実装するにあたって必要な足回りのコード(インフラストラクチャ・コード)を先に一通り実装してからテストケース実装に入るのがボトムアップ。それに対し、テストケースを1つずつ書きながら、必要なだけのインフラストラクチャ・コードを作っていくのがボトムアップ。

アジャイルなチーム、プロセスなら後者で進めるのがよい。

10章 Designing the First Test Case

ここからはチュートリアル形式でテストコードを書いていく流れ。手元に.NET環境ないし長らく.NETは触ってないので、手は動かさずに読み進めることにした。

自動化したい数多のテストケースから、何を最初に選べばよいか?
サニティ・テストから始めるのが一般的だが、著者は「アプリケーションが行っていることの中で最も重要なものは何か?」を考えよと言っている。

具体的なテストコードの実装は、Page Objectパターンなどを使って抽象化して記述せぇよ〜といったことが書かれている。

11章 Start Coding the First Test
12章 Completing the First Test

テストケースの実装は、Page Objectやらヘルパークラスやらが存在しない状態でテストケースの流れを先に書いて(もちろんコンパイルは通らない)、コンパイルが通るようにダミー実装を行う。テストが失敗することを確認したら、ダミー実装をリアルなコードに置き換えていく。というやり方を著者は勧めている。

13章 Investing Failures

テストが失敗するとき、デバッグというその場限りの手段よりも、エラーレポートやロギングによって診断できるようにした方が、後で役立つのでいいよ、とのこと。

14章 Adding More Tests

最初のテストケースの実装を終えたら、次はどのケースを選ぶべきか。似たようなビジネス価値をもたらすテストケースの中で、テストのインフラストラクチャを拡充させるようなものを選ぶと、その先の自動テスト追加が容易になるのでよいらしい。

15章 Continuous Integration

当然ながら、自動テストはCIの一部に組み込みましょうね、という話。

16章 Acceptance Test Driven Development

この章では、ATDD/BDDの概要が紹介されている。

POや開発者、QA担当者など関係者が協力してユーザーストーリーを作成し、ストーリーの受け入れ条件を定めて合意する。受け入れ条件は、CucumberのようなBDDツールを使って自動テストコードで実装する。開発者にとって、この受け入れテストをパスするプロダクトコードを書くことがゴールである。というのがATDD/BDD。

個人的にはいつかプロジェクトでやってみたいなーと思ってる。(過去に、Cucumber/Serenityを検証したことはあり)。Gaugeあたりも触ってみたいかも。

17章 Unit Tests and TDD

本書はどちらかというとQAエンジニア向け(ただしテストコードも書ける)に書かれた印象であるが、この章ではユニットテストやテスト駆動開発(TDD)について説明されている。AAAとかRed-Green-Refactorとか。

個人的に結構同意できることがいろいろ書かれていたが、その中でもTDDの難しさについての記述は的を得ていると思った。

  • コードより先にテストを書くという大きなマインドシフトが必要
  • TDDを最初から適用できるようなグリーンフィールドのプロジェクトは少ない
  • テクニカルな難しさも多い。神クラス、I/O、シングルトン、SUTが内部でDOC(依存オブジェクト)をnewしてる

テクニカルな難しさを克服するには、CLEANコードやSOLID原則、リファクタリングなどをマスターする必要があると。うんうん。

そして、最大の困難は、何をテスト対象とすべきかだとしている。単一のクラスをテストすることが必ずしも効果的とは限らない。いくつかのクラス群に対してテストを書こう。
この辺りの主張を見ると、書籍『レガシーコードからの脱却』の影響を受けてるのかなーと思った。ふるまいの集合体ってやつね。

僕も『レガシーコードからの脱却』を読んで、ユニットテストのユニットとはふるまいの集合体、つまりふるまいを提供するクラス群と考えるんだよ、と知ってユニットテストの考え方がそれまでと一変したし、テスト駆動開発によって設計をするということが理解できたように思う。本当に名著。ありがたし。

18章 Other Types of Automated Tests

機能テスト以外のテスト自動化についてまとめられている。パフォーマンステスト、負荷テスト、アクセシビリティテストなど。

19章 Where to Go from Here

まとめの章。

全体を通しての感想

電子媒体で読んだが、ペーパーブックだと560ページだということで、結構なボリュームだった。読了までにそこそこ時間がかかった。
個人的に新たな発見は多くはなかったが、幅広いテーマでよくまとまっているのではないかと感じた。テスト自動化に関する知識を整理するにはよいんじゃないかと思う。