はじめに
第1章 TDDとは
第2章 書いておぼえるTDD
第3章 2018年現在のSwiftでのTDD開発
第4章 参考文献
謝辞
著者紹介
こんぬづは、筆者の田中です。
『Swiftで書いておぼえるTDD』を手に取っていただき、ありがとうございます!本書は「Swiftでテスト駆動開発に入門する」本です。より多くのSwiftプログラマが、テスト駆動開発という素晴らしい開発手法に触れる機会を持ってほしいという想いから生まれました。
本書だけでは幅広く、そして奥深いTDDやテストの話題を全てカバーしきれるわけもなく、筆者の知識にも限りがあります。もし読んでいて気になった点や、理解できない点などありましたら、お気軽に筆者のTwitterアカウント(@ktanaka117)にメンションを飛ばしてください。お答えできる疑問かもしれませんし、筆者もわからなければ、一緒に答えを見つけられるかもしれません。
テスト駆動開発は英語でTest-Driven Developmentと呼びます。一般に省略形のTDDで知られているため、以降本書ではTDDと表記します。
TDDは、言語にとらわれない開発手法です。なのでJavaで説明されようが、JavaScriptで説明されようが要となる部分は同じはずです(メロンとメロンパンの話ではありませんよ)。ですが、実際にTDDに取り掛かろうとするときは自分が得意とする言語で、解釈もその言語に読み替えて行うはずです。実際、筆者もそうでした。参考にした書籍で紹介されているコードを、自分が得意とするSwiftに読み替えて解釈するにはエネルギーを必要としました。
新しく学ぶことのハードルは低ければ低いほどよいと筆者は考えています。SwiftプログラマにとってTDDのハードルを下げるためにもこの本を書こうと決意しました。
TDDでは実装の手順をいくつかに分けて、その手順の間にかかるコストのことを「歩幅」と表現します。TDDは言語にとらわれないと述べましたが、「Javaでこの機能を実装するには、このくらいの歩幅がちょうどよい」「JavaScriptで書くときはもっと慎重に書こう、こういう点にも注意してテストを書こう」など、言語によって歩幅やスピード感は変わります。「自分が使う言語ではどのくらいの歩幅がちょうどよいのか」それを知るための記事や書籍は、Swiftでは多くありません。本書がその一助になれば幸いです。
また、「TDDってなんか難しそう……」とか「なんとなく聞きかじっているけど、いまいち手が出ない/理解できていない」と思っている方も多いかと思われます。筆者が学び、実践したところ、TDDはコードを書きながらの方が理解しやすいと思いました。そこで、本書では読者の皆様が手を動かしながらTDDを学習できる内容にしました。この本を読み終えたなら、TDDのレッド/グリーン/リファクタリングを用いた改善のサイクルを身につけ、そのメリットとデメリット、そしてプロダクトコードがテストコードと共に歩んでいく安心感(不安との付き合い方)を理解し、噛みしめ、そして楽しめるようになるでしょう。
SwiftでのTDDの実践には、課題もあります。2018年現在のSwiftを取り巻くエコシステムには、他のプログラミング言語と開発環境に、あって当たり前と思えるものがなかったりします。本書では開発環境に関する課題と、筆者がその課題とどのように付き合っているかについても解説します。
・TDDの概要を知りたい人
・普段Swiftを書いていて、TDDに興味のある人
・「TDDってなんか難しそう……」と思っている人
・「TDDはなんとなく聞きかじっているけど、いまいち手が出ない/理解できていない」という人
・TDDの概要
・TDDのメリット、デメリット
・TDDで気をつけるべきポイント
・SwiftでTDDに入門するための手ほどき
・SwiftでTDDをするときの課題と解決策
・Swiftの書き方
・Xcodeの使い方
・XCTestの使い方
本書はもともと技術書典4という技術書の同人誌即売会で同人誌として頒布したものです。即売会のあとでインプレスR&Dの山城さんからお声がけいただき、晴れて商業版の書籍となりました。
同人版はノリと勢いのある文体で書いていたましたが、商業版の発行にあたってより多くの人に受け入れてもらいやすく、かつ理解しやすくするために過剰な表現を取り除きました。また、当初書いていたときよりも筆者のTDDやテストに対する理解が進み、より適切な説明ができるようになった部分を書き換えたりもしています。より多くの初学者が適切な理解を得られるようになっていれば幸いです。
同人版ではペアの判定までの説明で終わっていましたが、フラッシュの判定も追記しました。実装内容はペアの判定とあまり変わりませんが、TDDのリズムにより馴染んでもらえるよう、地続きの内容を追加しました。
同人版では手放しに期待を込めていたモックの自動生成でしたが、筆者の設計やリファクタリングに対する理解が進むにつれてデメリットも見えてきました。高機能なモックの自動生成ツールは、テストを容易に書けるようにしてくれますが、同時に設計の改善に対する意識を低下させます。TDDの本質は、よりよい設計を得るための矯正ギブスのような役割です。ツールがその意味合いを薄めてしまうこともあり、用法用量には気をつけなければいけないことについて言及しました。
kuniwakさんには「3.2.2 モックが簡単に自動生成されることの功罪」の追記にあたってアドバイスをいただきました。この節を追記しようと思ったのも、kuniwakさんとのTwitterでのやりとりがきっかけになっています。kuniwakさんにはTDDのみならず、テストや設計に対する僕が抱える疑問をよく相談させていただいて、とても参考にさせていただいています。いつもありがとうございます。
本書に記載されている会社名、製品名などは、一般に各社の登録商標または商標、商品名です。会社名、製品名については、本文中では©、®、™マークなどは表示していません。
本書に記載された内容は、情報の提供のみを目的としています。したがって、本書を用いた開発、製作、運用は、必ずご自身の責任と判断によって行ってください。これらの情報による開発、製作、運用の結果について、著者はいかなる責任も負いません。
本書籍は、技術系同人誌即売会「技術書典4」で頒布されたものを底本としています。