「iOSアプリ テスト自動化入門」を読みました
そろそろテストをちゃんと勉強しようと思って、以前から気になっていたこの本を読んでみました。
iOSアプリのテストや自動化まわりの話をまとめた本で、テストの意義や考え方、書き方などが丁寧に書かれています。 色々と勉強になったので、心と頭に残ったポイントをまとめてみます。
読む前の状態
- テストについてちゃんと勉強したことはない
- iOSのテストは、モデル周りについて少し書いたことがある
- テスト書いておくと変更に強いな、安心して変更できるなと感じている
- イケてるエンジニアはテストを書いている
読む目的
- 具体的にテストを書いていく流れを知りたい
- テストに関する断片的な情報を整理したい
読書メモ
テストしやすい設計を心がける
テストを書く副次的な効果として、意識的にテストをしやすい設計（=関心の分離ができた良い設計）をすることがあります。本の中では「テスタビリティの高い設計」と書かれていて、今後コードを書く上でこの言葉は胸に秘めておこうと思いました。
「意図の明確なコードを書く」という意味でいうとリーダブルコードを読む（読み返す）のも効果的かと感じます。
既存コードにテストを追加する
新しく生まれるコードにはテストを書いていくとして、業務などでは既存アプリに加わる or 引き継ぐことの方が多いかと思います。その場合でもテストを追加することは有用です。
なにか不具合が発生してそれを修正する場合に、
- 1.まずはテストを書き、ちゃんと失敗することを確認する
- 2.次に実装を修正する
- 3.テストが通ることを確認する
と進めていくことで、安心感が得られますし、今後同じ実装周りに変更を加えた時の資産になるというのは良いなと思いました。
自分がある程度把握している新規アプリよりも、全容を掴めぬまま修正する必要のある既存アプリのテストの方が重要かもしれませんね。
テストが書けない状態の場合
テスタビリティが考えられてないコードに途中からテストを追加するのは困難です。この場合はリファクタリングしてテスタビリティを向上させつつテストを追加していく必要があります。
リファクタリングしつつテストを書いていくのは当然コストがかかりますので、バランスをみてリファクタリングするか諦めるかを判断するのも重要、と書かれていました。
リファクタしつつ進めていく参考として以下の書籍が紹介されていました。
振る舞い駆動開発（BDD）
本の中ではテストフレームワークのKiwiを例に、BDDについて説明がありました。
Kiwiでは、以下のようにSpec（仕様）の形でテストを書いていくことができます。
describe(@"Team", ^{ context(@"when newly created", ^{ it(@"has a name", ^{ id team = [Team team]; [[team.name should] equal:@"Black Hawks"]; }); it(@"has 11 players", ^{ id team = [Team team]; [[[team should] have:11] players]; }); }); });
記法に関する詳しい説明は省略しますが、このようにSpecを書いていくことで、まるでテストケースが仕様ドキュメントのように作られていきます。
後から入るメンバーのために仕様をドキュメント化するのは重要ですが、面白さが少なくついサボりがちになってしまいます。テストを書くことで仕様がまとめられるのはとても良いアプローチだなと思いました。
なお、Kiwiの詳細な使い方は以下が詳しいです。
Target / Configuration / Scheme
様々なケースにでテストを対応させようという文脈で説明されたXcodeに関する情報も、自分の知識の整理にとても役立ちました。
- 開発環境と本番環境をどう切り替えてテストするのか？
- スキームの"Shared"チェック
- xcconfigファイルの使い方
など、これまでWebで断片的に聞いたり試したりしていた情報を体系立てて理解することができました。
以上、読書メモでした。
試そうと思うテストフレームワークまとめ
Kiwi
BDDで書ける。モックや非同期処理にも対応。
KIF
Square社製の統合テストフレームワーク。View周りのテストなどに使いたい。
参考
感想
テストへの考え方から実際の書き方まで、コードつきで説明が掲載されていて初心者の自分でも非常に分かりやすかったです。特に前半の考え方の部分にあった「テスタビリティの高い設計を心がける」「既存アプリの不具合修正の時にまずテストを書く」というのが印象的で、早速明日からやっていこうと思います。
