now in androidのcoreモジュールのテスト調査
network
モジュールのテストはFakeNiaNetworkDataSourceTest
クラスのみ
FakeNiaNetworkDataSource
はNiaNetworkDataSourceのフェイク。テストダブルの手法の一つ。
APIを叩いてニュースやトピックのjsonを取得しているのではなくcore/network/src/main/assets
にあるnews.jsonとtopics.jsonをデシリアライズしている
ここでCoroutine Dispatcherをインジェクションしている理由は公式ドキュメントのコルーチンのベストプラクティスに書いてある
- 新しくコルーチンを作ったりwithContextを使うときにDispatcherをハードコードしない
理由はだいたいこの記事に書いてある通り
ハードコードしないことが好ましいとされている理由としては、
CoroutineDispatcherは環境によっては動作しないことがあり、
Android環境では問題なく動作しても、単体テストの環境ではうまく動作しないということがあります。
そのためテストの時はテスト用のDispatcherを指定することがあるのですが、
ハードコードしてしまうとDispatcherをテスト用のものに置き換えることができず、
Unitテストでテストすることができないという問題が発生してしまいます。
テストの不確実さをなくすためにも重要っぽい
たしかに、こうしないとテストのときはStandardTestDispatcher、それ以外の時はIODispatcherと使い分けることができず、どちらの場合もIODispatcherを使うことになってしまうので、理にかなっている
assetの読み込みはJvmUnitTestFakeAssetManagerでしているっぽい
ちなみに
@Dispatcher(IO) ...
これはアノテーションで必要なCoroutineDispatcherを指定してDIしているだけ。
こうしないとどのDispatcherがDIされているかわからないので。Now in AndroidではIODispatcherとDefaultDispatcherをDIしている。
networkモジュールのテストは、レスポンスの処理(返ってくるjsonのデシリアライズ)がうまくいくかテストしているように見える
datastore周辺はProtocol Buffersの知識がないのでいったん飛ばす
dataモジュールのテストコードを調査する
NetworkEntityKtTest
いたってシンプルなテスト。
○○Resourceをまず作成し、それをEntityに変換した後も適切な値が格納されているかテストしている
次は OfflineFirstTopicsRepositoryTest を調査する
最初の大量にあるlateinitは何
- subjectはOfflineFirstTopicsRepository自身
- topicDaoとnetworkはsubjectに注入する用
- niaPreferencesはTestSynchronizerに注入する用
synchronizer: Synchronizer が何なのかわからん