基本
Rx自体がロジックを表現していて、テストコードを減らす役割を担ってくれるほど便利ではありますが、それでも複雑なロジックを組んだときにはRxの手順自体にユニットテストを記述すべき場合も多々あります。Rxのテストを学ぶことでプロダクションコードの記述方法も変わってくるので、紹介したいと思います。
視覚的にも、mapオペレータがどんなことをしているかがよくわかると思います。marble testingによって、オペレータの挙動などをこのように簡単にテストできます。逆に、オペレータがどんなことをしているかも、このmarble testingで書かれていればわかるようになります。
throttleTimeオペレータとdebounceTimeオペレータのテストコードを書きましたので両者の違いをみてみましょう。
throttleでは、値が流れた時に一定時間値が流れるのを防ぐような挙動に対して、debounceは一定時間間が開いたら最後の値を流す、というような挙動になっているのがわかります。
プロダクションコードでoperatorを独立させる
Rxを使って複雑なロジックを書いた場合に、そのロジックはpipe関数に渡したoperator処理群に集約されていると思います。プロダクションコードでは意識的にpipeの中身を一つのoperatorとして独立して宣言しておくと、上で紹介したテストコードを書きやすくなるのではないでしょうか。
最後に簡単な例でpipeの中身をoperatorとして記述する方法を紹介します。
まとめ
Rxjsを使ったアプリケーションにユニットテストを書くための導入を紹介しました。さらに詳しくは、公式ドキュメントのライブラリのMarble Testのドキュメントを参照ください。
https://github.com/ReactiveX/rxjs/blob/master/docs_app/content/guide/testing/marble-testing.md
アカリのウェブサイトでは今後も我々の大好きなRxjsの様々な使い方を紹介していきたいと思いますので、よろしくお願いします。また、アカリではRxを使ってフロントエンド・バックエンドを開発したい方からの採用ご応募も常時お待ちしています。