try! Swift Tokyo 2017 テスト系セッションまとめ #tryswiftconf

昨年に続き、3月2〜3日に開催されたtry! Swift Tokyo 2017に行ってきました。

テスト系のセッションが3つあったので、それらについてまとめます。

今年は海外からを含め700人を越える参加者があり、会場になったベルサール新宿セントラルパークの広いホールもこんな感じ（会場の2/3あたり後方から撮影）。

クックパッドアプリのテストを味わう - Tasting tests at Cookpad

初日、クックパッドの松尾さん(@Kazu_cocoa)の講演。全て英語でのプレゼンでした。すごい。

20170302 tryswift tasting_tests from Kazuaki Matsuo

www.slideshare.net

このセッションでは、UIのテストについて、UIのテストがクックパッドの開発をどうサポートしているかについて語られました。スライドには"Tests"とだけ書かれていますが、当然ながら自動化されたテストのこと。

クックパッドアプリ（日本版）は5年間メンテナンス・アップデートを繰り返しており、UIの変更も大小あった。2014年（3年前）からUIテストの実装を進めている。

なぜUIテストを実装したか。書籍『Re-Engineering Legacy Software』には、「リファクタリングの前にユニットテストを書くことは、不可能であったり、無意味なものしか書けない」と書かれています*1。

そこで取った基本戦略は、"中から"と"外から"。まず"外から"「UIテスト」でエンハンスバグ（デグレード）を防いで「リライト/リファクタリング」を行なう。そして"中から"「ユニットテスト」を書く。また戻ってUIテスト……と回していくことで、検証可能なコードを育てていく。

テストピラミッド*2では、ユニットテストが最も多く、UIテストは少ないことが理想とされる（このピラミッドに手動テストは入っていない）。これを逆にすると、手動テストの時間がとても大きくなり、開発サイクルは遅くなる。

iOSバージョンとデバイス（iPhone/iPad/iPad Pro）の組み合わせテストも数パターン実施。実装戦略として、UI操作の80%をカバーしている。

UIテストのアーキテクチャは、ユーザシナリオにフォーカスし、シナリオをRubyで実装、これをAppium*3で実行している。シナリオ記述にはTurnip*4を用い、データ駆動テスト*5を書いている。

内部コードへの依存を減らす工夫。find_elementでUI部品を探すとき、xpathで記述してしまうとViewのヒエラルキーに強く依存してしまい、Viewヒエラルキーが変わる修正でテストが壊れてしまう。UI部品にはaccessibility_idを設定し、そのidで指定することで回避できる。

UIテストでは全ての境界値テストやバリデーションなどを実施しようとしないこと。UIテストの実行には時間がかかるので、この手のテストはユニットテストで実施すべき。

このような試みは、開発者の空き時間で実現できるものではないことを忘れないでほしい。

Q&A

Appiumを使っている理由はなにか。実行に時間がかかるが。 -> アプリの状態をクリーンにして、システムアラート（カメラの権限とか）を毎回出すことができる。XCUITestだとシステムアラートが1回出るともう出ないので。時間がかかるのは確かに問題だが*6。
時間がかかるので境界値やバリデーションを実行すべきでないとあったが、代替手段は？ -> ユニットテストで実施するべき。

所感

非常に説得力のあるセッションでした。どうしてもUIテストはUI変更によって無駄になることも多く、忌避しがちでした。またXcode 7からXCUITestが追加されたことにより、統合テスト(Integration Testing)レベルでのUIテストが実装しやすくなりましたが、やはり限界はあります。

本セッションで語られた、UIテストをAppium+TurnipによるシナリオBDDで行なう、という手段は、現時点での最適解だと思うので、自分でも前向きに考えていきたい。

参考

引用されていた『Re-Engineering Legacy Software』の翻訳本

レガシーソフトウェア改善ガイド

作者:クリス・バーチャル
翔泳社

Amazon

少し古いですが、テスト自動化研究会で書いたAppiumの記事*7 www.atmarkit.co.jp

@niwatakoさんの聞き起こし niwatako.hatenablog.jp

テスト可能なコードを書くということの２つの側面 - The Two Sides of Writing Testable Code

ここから二日目。KickstarterのBrandon Williamsさん(@mbrandonw)のセッション。日本語タイトルは「テスト可能なコードを書くための2つの視点」とかがよかったかも。テスト対象の入力と出力という2つの面にフォーカスした話。

なぜテストを書くのか。試練として、テスタブルなコードだけを書くようにしている。実装のための実装ではなく、ドキュメントとしての価値がテストにはある。

例えば、ファイルから読んだ数値を演算した結果をコンソールに出力する関数を考えてみる。実装は容易だが、テストでは以下の要因を考慮する必要がある。

ファイルの中身（実際のデータ）だけでなく、HDDの現在の状態（ファイルを読めるかどうか）、グローバル変数でファイルパスを指定など、これら隠されたインプットに依存する。
関数の戻り値として正しい演算結果を返しているかは、コンソールだけ見ていてもわからない。アウトプットの評価方法も考え直す必要がある。

まずアウトプット。アウトプットの評価を難しくしているのは、副作用(side effects)。どう副作用をハンドルするか。副作用をテストターゲットの境界に持っていく。例えば、戻り値をタプルにして、演算結果とコンソールに出力するメッセージを返すように修正する。

次にインプット。インプットを難しくしているのは"Co-effects"*8だという考え方。これは、関数の外部にあって、実行結果に影響を与えるもの。それがないと実行できないもの。DI（Dependency Injection/依存性注入）と呼ぶ人もいる。

Co-effectsをハンドルするベターな手段は、これらをひとつのStructに入れてしまうこと。サービス、Cookieストレージ、ユーザ、DateProtocol.Type、Language、UserDefaultなど、20以上にのぼる。DateはProtocolを介して扱うことで、テストではテストダブル（モック）で固定の日時を与えることができる。

このようにリファクタリングすることで、簡潔にテストコードを記述できるようになる。

Q&A

テストを書くのは実装の後か、前か。 -> テスト駆動で開発している
環境について、ReaderモナドやStateモナドを使っているか。 -> Gap environmentはコモナド(Comonad)になっている。プロパティベースではやっていない。

Q&Aルーム

セッション後のQ&AルームでBrandonさんに聞いたところ、Co-effectsとは2014年にTomas Petricek氏が提唱した概念で、以下の論文で述べられたもの。（"xUnit Test Patterns"で述べられている）テストフィクスチャ(Test fixture)に近いが、コモナド、副作用を扱う考え方。

ついでに他の方の質問もメモした範囲で。

DateをJSTで扱っているが、CI as a ServiceではUTCなのでどうしたらいいか。 -> タイムゾーンは考えないでシンプルにテストすればいい。
テストが無い状態からテスタブルに変えていきたい。 -> まずSingleViewControllerをターゲットにする。UI操作ひとつひとつに分解して、操作（ボタンのタップとか）とその副作用（ボタンがグレーになるとか）を検証する。操作や副作用は個別の関数に分解しておき、その組み合わせを実装するようにする。Kickstarterのアプリがそうなっているので参考にするといい。
UIテストフレームワークは使っているか。 -> フレームワークは使っていないが、ios-snapshot-test-caseは使っている。あらゆる言語でテスト実行してスクリーンショットを撮っている。
- GitHub - facebookarchive/ios-snapshot-test-case: Snapshot view unit tests for iOS

所感

テストにおいて、入力と出力を捉えるというのは基本なのですが、それを改めてシンプルに解説されたセッションでした。

Co-effectsははじめて聞いた言葉で、有用ではあると思うけど煩雑さとのトレードオフはありそう、というのが現時点の感想。近々、上記の論文などを読んでみて改めて何か書こうと思います。

参考

KickstarterのiOSアプリはオープンソース。本セッションのサンプルコードとして読むとよさそう。 github.com

@niwatakoさんの聞き起こし niwatako.hatenablog.jp

モックオブジェクトをより便利にする - Making Mock Objects More Useful

Jon Reidさん(@qcoding)のセッション。

なぜモックを使うのか。例として、レストランにおいて、テーブルの客、ウェイター、コックがいたとき、ウェイターが正しく注文を処理したことをテストするのに、毎回本物のコックが料理していては時間や食材などのリソースが浪費される。これを避けるため、ユニットテストでは偽の(Fake)コックを使う。

Swiftでは、コックはCookProtocolとしてあらわし、RealCook、Fake(Mock)Cookがそれを実装する形。CookProtocolは、関数cookRamen(bowls: Int, soup: RamenSoup, extras: [String])を持つ。ウェイターは、イニシャライザでCookProtocolを受け取る。関数order()を持ち、この中でCookProtocol#cookRamen()を呼び出している。

テストコード（WaiterTests#testOrder_ShouldCookRamen()）では、コックのモック(MockCook)をウェイターに与え、order()を呼び、ウェイターが内部で正しくコックのcookRamen()を呼び出しているかをテストしたい。

以下、実現手順を簡潔に。

cookRamen()を呼んだことをテストする。MockCookでハンドリングし、モックのメンバ変数に保存するが、bool型で「呼ばれたこと」を表現するのでなく、int型で呼ばれた回数をカウントするべき。order()呼び出し後、XCTAssertEqual()でカウンタが1であることを確認する。
cookRamen()のパラメタをテストする。例えばbowlsに渡された値をモックのメンバ変数に保存し、order()呼び出し後に確認する。値は最後に呼び出されたときの値しか保存できないが、テストに使うにはこれで十分。ただし保存する変数名はcookRamenLastBowlsのように"最後"を表現する名前にすべき。そして同様にorder()呼び出し後、XCTAssertEqual()で値を確認する。
テストメソッド1つにAssertは1つにすべき、という原則がある。そのため、MockCookにverifyCookRamen()というヘルパーメソッドを作り、その中にAssert文を内包する。テストコードからは、verifyCookRamen()を呼ぶ。
テスト失敗時のメッセージがverifyCookRamen()から出力されるためわかりにくくなるので、#fileと#lineをAssertの引数で渡すようにする
どのAssertで失敗したかを示すため、Assertの第三引数にメッセージを渡すようにする
パラメタextrasは配列だが、格納順序が違ってもテストはパスさせたい（壊れやすいテストを避ける）。クロージャでMatcherを定義し、配列の完全一致でなく、要素が含まれていればパスするようにする。
さらにHamcrest Matchersを使うことで、配列要素の一部が異なる場合にわかりやすいメッセージを表示できるようにする