どうも、最近はRabi-Libiという弾幕アクションゲームをやっているtobi462です。
というわけで、PEAKSから『iOSテスト全書』の電子版が正式リリースされました。 peaks.cc
おそらく製本版も今月中には発送されるかと思います。
（ところで一般販売はされるのでしょうか？私、気になります！）
追記：一般販売が開始されました！
そんなわけで、個人的にどういう想いを込めて執筆したのか、みたいなことを自分なりに振り返りながら書いてみたいと思います。
担当した章
私は著者陣の一人として、以下の章の執筆を担当させていただきました。
- 第2章：ユニットテスト（概要）
- 第4章：ユニットテスト（Quick / Nimble 編）
- 第5章：BDDによるアプリ開発
なお、第3章「ユニットテスト（XCTest編）」において、Xcode 11から追加された「テストプラン（Test Plans）」についても少し書かせていただいてます。
それぞれの章について、私の中では明確なコンセプトを以て執筆に臨みました。
2章：ユニットテスト（概要）
2章では『iOSに限定されないユニットテストの知識』というのがコンセプトであり狙いでした。
構成は以下のようになっています。
表面的な知識よりも本質を
一般的に言えることですが、表面的な知識よりもその本質を理解したほうが潰しが効きますし、利用している技術やテクニックが本当に有効なのか疑うこともできます。XCTestを通じたユニットテストの表面的な知識ではなく、その考えの基本となる土台を提供し、他のプラットフォームにも流用可能な知識を提供することが私のゴールでした。
そのため、あえて「テスティングフレームワークはなぜ必要か」という問いかけと回答から始まる構成にしています。テスティングフレームワークの存在そのものにも「なぜ？」というスポットライトを当てることで、より深い理解につながると考えたためです（とはいえ「簡単すぎて不要では？」という声も著者陣からあり、残すか悩んだ部分でもあります）。
他にも「テストデータを選ぶ手法」や「ブラックボックス」「グレーボックス」「ホワイトボックス」の違い、テストコードを段階的に改善していくシナリオなど、iOSに限定されない知識やテクニックを多く盛り込んでいます。
テストダブル
また、テストダブルの種類やその解説についても、シンプルに本質を分かりやすくというのを心がけました。文章やコードにするとなかなか說明が難しい部分ではあるのですが、図を利用することで直感的にも分かりやすく説明できているのではないかと思います。
ちなみにテストダブルの用語は姉妹本（という言い方であってますかね？）である『Androidテスト全書』と統一するようにしました。というのは、元々『xUnit Test Patterns』の用語定義に合わせる予定だったのですが、執筆中に『Androidテスト全書』での用語定義はそうではないと気づいたためです。
そこで『Androidテスト全書』の著者にコンタクトを取ったところ、明確な理由があって『xUnit Test Patterns』の用語を揃えていないことが分かりました。
どうするか迷いましたが、前述したとおり『Androidテスト全書』と統一することに決定しました。第１に「用語定義よりも考え方を理解する方が重要である」という私の考えと、第２に「両方の書籍を読んだときに用語定義が異なると読者に誤解を与える可能性がある」という２つの理由からです。
テスティングフレームワーク
章の最後ではテスティングフレームワークの紹介で締めています。
本書では具体的に解説していないものも多いのですが、「どういった種類や考え方があるのか」を知るだけでも強い武器になると考え、短い解説ではありますが載せるようにしました。
コラム
この章に限った話ではありませんが、出来るだけコラムで「さらなる回答」をするようにしています。
この章で言えば「ブラックボックス」「グレーボックス」「ホワイトボックス」について説明していますが、『ボックス（箱）となるものは何？』というコラムで「そもそも箱ってなんだっけ」という疑問を解消するようにしています。
こうした一歩進んだ内容ではあるものの、頭のどこかで引っかかって残りそうな疑問をコラムで回収するようにしています。コラムなのであくまでオプショナルな内容ですが、どれも一読の価値のある内容となっていると思います。
4章：ユニットテスト（Quick / Nimble 編）
4章では『日本語における最強のQuick／Nimbleリソース』をコンセプトとしました（いやはや、これは大きく出たものですね）。
構成は以下のようになっています。
体系的な知識を積み上げる
ご存知の方も多いかもしれませんが、Quick/Nimbleは公式でもドキュメントが充実しており、Quickについては日本語に翻訳されているリソースもあります。それを考えると、あえてiOSテスト全書としてそれなりのページ数を割くのにはそれ相応の理由が必要でしょう（と、少なくとも私は考えました）。
私が公式ドキュメントに抱いていた大きな不満は「体系的な知識をキレイに順に積み上げるような構成にはなっていない」という点でした。Quickのドキュメントはリファレンスを超えるレベルになっているとは感じますが、（少なくとも私は）それぞれの知識がキレイにつながるような印象が得られませんでした。
そこで、この章では１から順番に読み進めながら、少しずつ知識を積み上げながら理解できるような構成を特に心がけました（もっともこれはすべての読み物において大切なポイントであるのですが）。
Quick/Nimbleの具体的なコード例から、QuickとNimbleがそれぞれどういう立ち位置にあるのか全体像を見せてから、QuickとNimbleについてそれぞれパートを分けて解説するという構成にしています。
Quick
公式ドキュメントにも出てくる「Example Groups」と「Example」の違いやコードとの対応関係、xitやfitといったテスト実行を制御する方法、すぐに分かったつもりになるけれども意外と分かりづらいbeforeやafterを使った「前後処理」などを、出来るだけ具体的なコードや図を交えながら丁寧に解説することを心がけています。
また共通の振る舞いを定義するBehaviorといった仕組みや、コラムではありますが『Better Specs』の考え方を適用する例についても触れています。
Nimble
NimbleはマッチャーAPIによるアサーションを提供するライブラリという位置づけですが、それを利用するモチベーションから書いています。これは具体的な例を挙げてXCTestと比較することで、より深いレベルでの理解につながるだろうという狙いからです。
そこから先は公式のリファレンスと比較的似たような内容になっていますが、どれも理解するのにかかる時間が最短になるように、私なりに工夫して說明を行うように心がけています。あとから調べたいときにさっとリファレンスとして活用できる内容になっているかと、個人的には思います。
なおマッチャーの自作についても、かなり丁寧に解説するように心がけています。愚直な書き方に加え、ヘルパー関数を利用した書き方についても解説しているので、いわゆる「自作する必要がでたのでよくわからないけどコピペして必要な部分だけ改修した（でもやっぱよくわからん）」みたいな事態にならないかなと思います（あるあるですよね？）。
5章：BDDによるアプリ開発
さて、BDDやQuick/Nimbleを利用して簡単なアプリを作る流れになっている5章ですが、この章のコンセプトはずばり『私が今まで得てきた知恵や経験を、書籍を通して読者に』でした。
この章の構成は以下のようになっています。
知恵や経験を伝える
言葉などのコミュニケーション手段が利用できるのであれば、知識を伝えるのはそこまで難しいことではありません。他方、知恵や経験を伝えるのはものすごく難しいと私は感じます。
例えば料理人の見習いは何年もかけて修行しますし、伝統工芸の職人も何十年もかけて師の技を引き継ぐと聞きます。
正確な定義はさておき、ここではそうした「完全な情報」として受け渡すのが困難な何かに対して「知恵」や「経験」という言葉を当てはめています。
例えば、エンジニアリングにおいては「ペアプロ」などは「知識」というより「知恵」や「経験」が大切なものだと感じますが、それをどのように伝えたら良いのでしょうか？
BDDやQuick/Nimbleを学ぶ章ではないのか？
それに対する答えはYESであり、またNOでもあります。
2章で解説したBDD、4章で解説したQuick/Nimble について、「具体的にはどうなのよ？」という疑問に対して答えているのがこの章の内容です。ここまでで触れることのできなかった「リファクタリング」について具体例を交えて解説したいという想いも込められています。
そういった意味で答えは「YES」です。シンプルな題材ではありますが、ここまでの章で解説してきた静的な情報をつなぎ合わせる内容としています。
一方で、「これらの内容を通じて（via）、私が今まで得てきた知恵や経験を伝えたい」というもう一つの狙いもあります。誤解を恐れずに言えば『実践テスト駆動開発』や『エリック・エヴァンスのドメイン駆動設計』に似た何かをやりたかったわけです。
実践テスト駆動開発 (Object Oriented SELECTION)
- 作者:Steve Freeman,Nat Pryce
- 出版社/メーカー: 翔泳社
- 発売日: 2012/09/14
- メディア: 大型本
エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)
- 作者:エリック・エヴァンス
- 出版社/メーカー: 翔泳社
- 発売日: 2011/04/09
- メディア: 大型本
何かが伝わると嬉しい
正直なところこの試みがうまく行ったかは分かりません。
どう転んでも賛否両論の章だとは思っていますが、読了後に少なくとも「何かが得られた」という実感を得られる内容になっていれば嬉しい限りです。
『iOSアプリ開発自動テストの教科書』と何が違うのか？
さて、ご存知の方も多いと思いかもしれませんが、iOSテスト全書の前に『iOSアプリ開発自動テストの教科書』（以降、『教科書本』）という書籍が出版されており、こちらも共著者として半分程度の執筆を担当しています。
「同じテーマで2冊も書くなんて、そんなに印税が欲しいんですか？」と思われる方もいるかもしれません（「欲しくない」とは言いませんが・・・）。
コンセプトの違いは？
何が違うのか140文字以内で表現したツイートが以下です。
ちなみに『iOSアプリ開発自動テストの教科書』はこれから水を飲みたいという人に「水飲み場の地図」を与えるもので、『iOSテスト全書』はもっと水を飲みたいという人に「美味しい飲み方やグラス」を提供するものだ。
— トビ＠ほぼ通常モード (@tobi462) 2019年7月27日
と、自分のなかでは思ってる。もちろん重複する部分もありはするんだけれど。
ちなみに、教科書本の「はじめに」では以下のように書いています。
本書は「iOSアプリ開発における自動テストのための地図」のようなものを目指しました。
そういったわけで、教科書本は「全体を知るための地図」というのが大きなコンセプトでした。
iOSテスト全書ではかなりのページ数を割いた「Quick／Nimble」も基本的なことしか触れていませんし、「なんでユニットテストが必要なんだっけ？」みたいなところも省いたりしています。
教科書本にしか書かれていないトピック
一方で、『教科書本』にしか書かれていないトピックも多くあります。
- コードカバレッジ
- Mockingjay（HTTPモックサーバ）の使い方
- Cuckoo（モックコード生成）の使い方
- SwiftCheck（Property-based Testing）の使い方
- XCUITestのレコーディング機能
- fastlane
- アプリ配信サービスの使い方（TestFlight、DeployGate）
- デバイスファームの使い方（Firebase Test Lab、AWS Device Farm）
- BitriseやCircleCIの具体的な利用方法
- 各種デバッグテクニック
こう見ると結構ありますね。
特に「fastlane」や「デバッグテクニック」、「Bitrise/CircleCI」については独立した章を割いています。
2冊で完成させる
『iOSテスト全書』の企画が持ち上がったのは、『教科書本』の執筆が終盤になってからでした。
『教科書本』のページ数は当初の予定よりも大幅にオーバーしていましたが、どうしても実践的な部分が十分に書ききれていないという思いが心の中で残っていました。特にQuick／Nimbleについては基本的なことしか書けず、かといってこれ以上ページ数を増やすわけもいかず苦々しい思いをしていました。
そこに『iOSテスト全書』の企画が持ち上がり、私の中では「この2冊で完成する」という構図が浮かびました。そして現在、それは私の中では概ね達成できたのではないかと感じています。
謝辞／Special Thanks !!
『教科書本』と同様に、多くの方にレビュー・フィードバックを頂きました。アーリーアクセスでのフィードバックをしてくださった方もおり、書籍としての完成度をより高めることにつながったのは言うまでもありません（コメントはすべて読ませていただいています）。
『iOSテスト全書』という書籍を完成させるのにご協力してくださった皆様に心より御礼を申し上げます。
また、ペンギン村からは以下の3名が『教科書本』に続き私の章をレビューをしてくださりました。
彼らの容赦のない的確な（しかも大量の）フィードバックが無ければ、ここまでの品質のものに仕上がらなかったのは間違いありません。
この場を借りて特別な感謝を、という思いです。
おわりに
というわけで『iOSテスト全書』について、私が担当した章についての解説（というか個人的な振り返り？）と、『iOSアプリ開発自動テストの教科書』との立ち位置の違いについて書かせていただきました。
正直なところ著書経験が無い私が2冊の本を立て続けに書くというのは大変でしたが、私個人としては良い仕事ができたのではないかと感じています。
どちらについても、読者が読了後に「買ってよかった」という感想を抱けるような内容になっていれば、著者冥利に尽きます。
