ワザノバの記事で知ったのですが、iOSに特化して、特定のテーマごとに発信しているブログを覗いてみました。
その中に、Testingに話題を絞って話している回があり、面白かったのでまとめてみます。
Issue #15 Testing
Behavior-Driven Development
What Should I Test?という問いかけから始まり、BDD DLSの話、BDDフレームワークを使いながら、BDDに関して説明している記事。以下の流れで実際にBDDフレームワークを使って、Behaviourとしてテストを記述するとこうなる、という事例を提示しています。
- BDDフレームワークとその特徴を簡単に説明
- 機能に対するテストの記述
- ただし、これはユーザから見ると何もテスト対象がどのように振る舞うのか書いていない、と指摘。
- どのような要素が表示され、それをどうするとどうなる、というような記述に説明を加えながら発展
- View Controllersのテストの具体例まで表示
- 締め
記事の中で、BDDのフレームワークとして以下を紹介。KiwiとQuickしか頭に入っていなかった…
SleipnirはCedarに、QuickはSpectaに影響を受けているらしいです。個人的に、Sleipnirには興味が湧きました。というのも、XCTestを使っていないらしいです。実際に試して、どこまでできるのかを図らないとなんとも言えないのですが、XCTestに縛られず、どういう風にBDDとしてテストを実施するのかに興味があります。試してみよう。
Core principles
• Sleipnir is not dependent of NSObject, it is pure Swift BDD testing framework
• Sleipnir is not using XCTest
• Sleipnir has nice command line output and support for custom test reporters
• Other features, like seeded random tests invocation, focused and excluded examples/groups, etc.
Real-World Testing with XCTest
XCTestを使ってテストを書いていく、ということに焦点を当てた記事。
XCTestがどのように動作するかから始まり、Given/When/Thenの形式でテストを記述する、Mockingを使う、Core Dataに対するテストなどをざっと解説しています。Custom ExpectationsやCustom Macrosのようにカスタマイズすることに対しても言及していました。Xcode x Xcode Serverを使ったCI環境の構築、BDDとXCTestの関係まで話を進め、まとめています。
著者は、テストツールとしてXCTestを最終的に選択しましたが、それは彼にとってのトレードオフの中でKISSを満足していたのがXCTestをそのまま使うことだったかららしいです。
Dependency Injection
恥ずかしながら、DIという言葉を知らなかった…
ここはすべてDependency Injectionを、コードつきで説明していました。以下などに対してInjectionするというものでした。
- Constructor
- Property
- Method
- Ambient
写経したほうがよさそうだ…
Bad Testing Practices
自動化テストを進めるにあたっての、Good/Bad practiceをまとめています。
テストコードを書く理由いくつか挙げ、それらのPositive sideはざっくり言うと The only time a test will give value back is when we want to change our code. になると言っています。一方で、test falseとなる原因がテストが不安定(flakey)だからという原因のように、よくない理由が多いとテストコードの価値がありません。
その話から、Good/Bad practiceをまとめています。ここでは、良いテストの引用としてF.I.R.S.Tをあげています。こちらの記事からの引用です。
- Good
- Fast — tests should be able to be executed often.
- Isolated — tests on their own cannot depend on external factors or on the result of another test.
- Repeatable — tests should have the same result every time we run them.
- Self-verifying — tests should include assertions; no human intervention needed.
- Timely — tests should be written along with the production code.
- Bad
- Don’t Test Private Methods
- Don’t Stub Private Methods
- Don’t Stub External Libraries
- If You Stub Out a Dependency, Do It Properly
- Don’t Test Constructors
Test Doubles: Mocks, Stubs, and More
テストダブルに関して、double, stub, spy, mock, fakeのそれぞれの説明、実際のコード例を示しながら説明しています。テストダブル自体はMartin Fowler氏の記事, “Mocks Aren’t Stubs“を参考にしていました。それぞれの内容は記事を見て欲しいのですが、日本語の記事でも同様に説明されていたものがあったのでリンク。
こちらの、goyokiさんの資料もとてもわかりやすいです。
そのほかに、Mockists vs. Statistsに関しても触れていました。Mock Objectで何をテスト対象とするか、という話題に対する興味において大きく2つに分類されます。前者はオブジェクト間の相互作用をテストすることに興味を持っている人たち、後者はその時々の状態をテストすることに興味を持っている人たち。
- Don’t Mock What You Don’t Own
- 3rdパーティ製の依存関係にあるものやライブラリはstub/mockにすべきではない。Codebaseで自身が実装するところを対象にすべき。
- Mockなどを使ったテストの目的は、自身の開発した箇所で生じる問題を解決したり、明らかにすることを目的にするので、3rd partyまでこの段階まで保証するために頑張るものではない。それらはもっとhigh-levelレイヤの統合/機能テストなどで検出するような内容。
銀の弾丸となるテストはなく、時々にあった戦略を使っていくことが必要。Mockだけではなく、fakeを使うなどして。結局は、何が一番適しているかを考えて、使えってことですね。
User Interface Testing
User Interfaceをキャプチャして、デザイナと確認していくことは大事。UI Testingは難しいと言われているが、大事で、思ったより難しくはないと言いたい記事。
例えば、KIF,Frank,Calabashなんかを使えばキャプチャとりながらUI Testing可能だが、その導入コストは高い。XCTest+Specta+Expectaとヘルパー作れば、思ったより簡単に同様なキャプチャとりながらのUI Testingできるよ、という話。ちなみに、この記事はサンプルとしてGitHubに公開していました。
Snapshot Testing
Facebookが公開しているios-snapshot-test-caseに関して紹介している記事です。やろうとしていること、やっていること、Xcode Pluginとして統合までざっと書かれています。
ここでも、FBSnapShots + Specta + Expectaの組み合わせでテストが書かれていました。Specta、人気なのですね。
実行速度を求め、完全なE2Eのテストではなく、UIのざっとした描画を確認したいのであれば良さそう。開発中はこれでテストを繰り返して、リリース前試験なんかではAppium使った、ちゃんとリリース設定されたモジュールに対してテストを行うとかできれば、UIテスト系は良さそうですね。
最後に
やっぱり、UI Testing系は難しいと思われているのですね。一方で、必ずUIはユーザの目に触れるので、個人的にはある程度は機械に任せてぐるぐる回したい。
Androidもこういう情報ないかな…
~ my tech diary ~ 
1 Comment