ReactorKitの生みの親も登壇した「ReactorKit Meetup Japan」レポート

「Test-Driven-Development with ReactorKit in StyleShare」Wooseong Kim, StyleShare

• 登壇資料（Wooseong Kim氏）

　Wooseong Kim氏で「Test-Driven-Development with ReactorKit in StyleShare」というタイトルでの発表です。Wooseong氏は、Jeon氏と同じStyleShareという会社でiOSエンジニアをしています。

　この発表は、StyleShare社で実践しているReactorKitでのTDD（Test-Driven Development）がテーマです。また、Wooseong氏は日本語で発表しており、会場では驚きの声が上がりました。

Quick look：Quick／Nimble／Stubber

　はじめに、QuickとNimble、そしてStubberの紹介です。Quickは、BDD（Behavior-Drive Development）フレームワークで、RSpecなどからインスパイアされています。Nimbleはexpect構文や各種matcherを提供しています。

　最後にStubberについてです。Stubberは、Jeon氏が作られたOSSライブラリで、メソッドスタブを簡単に実現することができます。例えば、UserServiceのfollowメソッドをスタブしたい場合、Fig. 6.1のように実現することができます。

Fig. 6.1 StubberでServiceのメソッドスタブをする例（登壇資料：page 10より引用）

StyleShareでの実例

　さて、本題に入りましょう。StyleShare社で実践しているTDDでどのようにテストを書いているのか、ステップバイステップで説明がありました。

　StyleShareは、韓国ファッション＆ビューティー情報を見ることのできるiOS Appを提供しています。Fig. 6.2の通り、Beautyのタブでは美容情報が一覧で表示されています。このタブを実装することを例に説明しています。

Fig. 6.2 StyleShareのBeautyタブ（登壇資料：page 13より引用）

　TDDなので、まずはテストを作成します。BeautyFeedEventsViewReactorSpecクラスを作成します。次に空のReactorであるBeautyFeedEventsViewReactorを作成します。もう一度Specに戻ります。そして「ページがリフレッシュ中かどうか」という状態を持ち、それが初期状態でfalseであることを期待するコードを書きます。ここでテストを実行してみると、isRefreshingは未定義なので、Fig. 6.3の通り、コンパイルエラーとなり「has no member ‘isRefreshing’」と表示されます。

Fig. 6.3 初期状態でisRefreshingがfalseであることを期待するテストコード（登壇資料：page 17より引用）

　それでは、isRefreshingを定義しましょう。Fig. 6.4の通りに変更すると、今度はグリーンになっていることが確認できます。

Fig. 6.4 StateにisRefreshingを定義し、initialStateとしてfalseを設定（登壇資料：page 18より引用）

　次に、「fetchアクションが呼ばれた後はisRefreshingになっていること」を期待するコードを書きます。そして、プロダクトコードを書きます。ActionとMutationの定義を追加し、mutateとreduce関数を実装します。もちろん、fetchが終わったらisRefreshingはfalseになってほしいですが、今はいったん空のexampleを書いておきます。

Fig. 6.5 空のexampleを作成（登壇資料：page 22より引用）

　次は、「初期状態でコンテンツが空であること」を期待します。つまりbeautyFeedEventsが空であることを検証するコードを追記します。さらにプロダクトコードでstateとinitialStateを定義することにより、このコードをパスすることができます。

Fig. 6.6 初期状態でコンテンツが空であることを期待するテスト（登壇資料：page 25より引用）

Fig. 6.7 初期状態を設定し、Fig 6.6 のテストを満たす（登壇資料：page 26より引用）

　次に、fetchのアクションを呼ぶことで適切なコレクションがセットされることを期待します。ここでServiceクラスを作成し、そのモックを作成します。モックは先ほど紹介したStubberを利用します。最後にmutate関数とreduce関数を実装すると、テストをパスすることができます。

Fig. 6.8 Serviceのプロトコルとクラスを作成（登壇資料：page 29より引用）

Fig. 6.9 スタブクラスを作成（登壇資料：page 30より引用）

Fig. 6.10 モックデータを使って結果の状態を検証（登壇資料：page 33より引用）

　さて、先ほどいったん空で作成したexampleに戻りましょう。同様にfetchアクションを呼び、「isRefreshがfalseに戻ること」を期待します。プロダクトコードでは、mutate関数を実装すればテストが通ります。最後に、Serviceクラスを実装すれば完成です。

　このように、非常に簡単にTDDができることがわかります。

Fig. 6.11 取得が成功した後にisRefreshingがfalseになっていることを期待するテストコード（登壇資料：page 38より引用）

まとめ

• Quick／Nimble／StubberでTDD環境を実現できる
• Reactorも高速にTDDできる

おわりに

　発表内容の解説は以上です。もうすでにReactorKitを利用されている方は、より踏み込んだ現場の知見を知ることができたでしょうか？ また、初めての方はReactorKitの魅力を感じ、導入してみたいと思ってもらえたでしょうか？ 本記事を通してReactorKitの理解の一助となれば幸いです。

　最後になりましたが、お読みいただきありがとうございます。そして、一緒にコミュニティを盛り上げていきましょう！