Rxjsにおけるテストコードについて。Rxと言えども複雑なロジックにはテストを書いて不安を払拭しよう。 Rx自体がロジックを表現していて、テストコードを減らす役割を担ってくれるほど便利ではありますが、それでも複雑なロジックを組んだときにはRxの手順自体にユニットテストを記述すべき場合も多々あります。Rxのテストを学ぶことでプロダクションコードの記述方法も変わってくるので、紹介したいと思います。 rxjsのテストには専用の記法が使われています。nextのタイミングを1文字のアルファベットや数字、 間隔をハイフン'-'、 errorをハッシュ'#'、completeをパイプ'|'で表す記法です。このテストをRxではMarble Testと呼びます。 簡単な例として、mapオペレータの挙動を確認するテストを書いてみましょう。テストにはmochaとchaiを使います。
この記事はドワンゴ Advent Calendar 2018の12日目です。 TL;DR RxJS v6.0.0 から追加された testScheduler.run(callback) を使うと様々な恩恵が得られて便利です。 非同期系オペレーターが testScheduler を自動で利用するようになる マーブルテストのフレーム最大数 750 の制限がなくなる marble diagram の記法が拡張され -a 100ms b-| のように書けるようになる はじめに berlysia といいます。Web フロントエンドを少々やっています。ブラウザの上に城を建てるのが得意です。 この記事では、RxJS のテストについて、直近のメジャーアップデートによってより簡単になった部分があるという話をします。詳細は RxJSのマーブルテストに関するドキュメント に任せ、例示につとめます。 記事中の例に
小飼です。 『The Next Great Burger』にハマっています。 RxJS、使っていますか? 弊社では現在開発しているアプリケーションから、本格的にRxJSを導入して使い込んでいっています。 イベントを配列のように操作できるという高度な抽象化の恩恵で、非常にリーダブルかつ簡潔に機能実装が出来るところが非常に良いですね。 学び始めた当初はReactive Programming的な考え方で実装を発想するということができず、非常に難解なイメージを持っていましたが、 半年くらい置いて改めて使ってみたところ、非常に使いやすいライブラリであるというイメージにガラッと変わりました。 これはRPっぽい発想の転換ができたことと併せて、TypeScriptでRxJSを用いることで、静的型解析の恩恵を受ける事ができた事も大きいと思っています。 (少なくともAPIの多さは問題にならなくなりました)
Test Description Identifier Count Notification Notification 24 should exist - should not allow convert to observable if given kind is unknown - createNext - 1 should return a Notification - createError - 1 should return a Notification - createComplete - 1 should return a Notification - toObservable - 3 should create observable from a next Notification - should create observable from a complete Not
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く