Junit5でJetpack ViewModelのviewModelScopeを使っている関数のテストをする

viewModelScopeを使っている関数を持つViewModel

次のRecommendBookViewModelクラスは、loadRecommendBooks関数という内部でviewModelScopeを用いて非同期処理を行う関数を持っている。

import androidx.lifecycle.ViewModel
import androidx.lifecycle.viewModelScope
import kotlinx.coroutines.flow.MutableStateFlow
import kotlinx.coroutines.flow.StateFlow
import kotlinx.coroutines.launch
import hoge.fuga.recommendbook.RecommendBook
import hoge.fuga.recommendbook.RecommendBookRepository

data class ViewState(
  val loading: Boolean,
  val recommendBooks: List<RecommendBook>
)

class RecommendBookViewModel(
  private val recommendBookRepository: RecommendBookRepository
) : ViewModel() {

  private val _viewState = MutableStateFlow(ViewState(true, emptyList()))

  val viewState: StateFlow<ViewState> = _viewState

  fun loadRecommendBooks() {
    viewModelScope.launch {    
      val recommendBooks = recommendBookRepository.recommendBooks()
      _viewState.value = ViewState(false, recommendBooks)
    }
  }
}

loadRecommendBooks関数をいい感じにテストするためにはいくらかの準備が必要になる。

環境

次のような環境とする。

implementation "org.jetbrains.kotlin:kotlin-stdlib:1.4.21"
implementation 'org.jetbrains.kotlinx:kotlinx-coroutines-core:1.4.2'
implementation 'org.jetbrains.kotlinx:kotlinx-coroutines-android:1.4.2'

testImplementation "org.junit.jupiter:junit-jupiter-api:5.6.1"
testRuntimeOnly "org.junit.jupiter:junit-jupiter-engine:5.6.1"

testImplementation 'org.robolectric:robolectric:4.4' // 多分今回のテストには関係ない
testImplementation 'androidx.test:runner:1.3.0'
testImplementation 'androidx.test.ext:junit:1.1.2'
testImplementation 'org.jetbrains.kotlinx:kotlinx-coroutines-test:1.4.2'
testImplementation "io.mockk:mockk:1.10.2"
testImplementation('androidx.test.ext:truth:1.3.0') {
  exclude group: 'com.google.auto.value', module: 'auto-value-annotations'
}

TestCoroutinesExtensionを用意する

Junit5ではorg.junit.rules.TestRule は無くなった。代わりにorg.junit.jupiter.api.extensionパッケージ内の各種インタフェースを実装したクラスを、ExtendWithで指定する形になった。そこでDispatchers.setMain()などを実行するTestCoroutinesExtensionを作る。

package hoge.fuga

import kotlinx.coroutines.Dispatchers
import kotlinx.coroutines.test.TestCoroutineDispatcher
import kotlinx.coroutines.test.resetMain
import kotlinx.coroutines.test.setMain
import org.junit.jupiter.api.extension.*

// テストの前後の実行、テストのコンストラクタへのパラメータをサポートする
class TestCoroutinesExtension : AfterTestExecutionCallback, BeforeTestExecutionCallback, ParameterResolver {
  private val namespace = ExtensionContext.Namespace.create(javaClass)

  private val key: Any = TestCoroutineDispatcher::class.java

  private val dispatcher = TestCoroutineDispatcher()

  override fun afterTestExecution(context: ExtensionContext?) {
    Dispatchers.resetMain()
  }

  override fun beforeTestExecution(context: ExtensionContext?) {
    Dispatchers.setMain(dispatcher)
  }

  override fun supportsParameter(parameterContext: ParameterContext, extensionContext: ExtensionContext): Boolean {
    return parameterContext.parameter.type === TestCoroutineDispatcher::class.java
  }

  override fun resolveParameter(parameterContext: ParameterContext, extensionContext: ExtensionContext): Any {
    return extensionContext.getStore(namespace).getOrComputeIfAbsent(key, { dispatcher }, TestCoroutineDispatcher::class.java)
  }
}

ViewModelのテストを書く

TestCoroutinesExtensionを使ってRecommendBookViewModelのテストを書く。

import com.google.common.truth.Truth.assertThat
import io.mockk.coEvery
import io.mockk.mockk
import hoge.fuga.TestCoroutinesExtension
import hoge.fuga.recommendbook.RecommendBook
import kotlinx.coroutines.test.TestCoroutineDispatcher
import kotlinx.coroutines.test.runBlockingTest
import org.junit.jupiter.api.Nested
import org.junit.jupiter.api.Test
import org.junit.jupiter.api.extension.ExtendWith

// エクステンションを使う
@ExtendWith(TestCoroutinesExtension::class)
class RecommendBookViewModelTest(val dispatcher: TestCoroutineDispatcher) {
  // コンストラクタでTestCoroutineDispatcherを受け取る↑

  @Nested
  inner class loadRecommendBooks {
    @Test
    fun `success`() = dispatcher.runBlockingTest {
      val viewModel = RecommendBookViewModel(
        mockk {
          coEvery { recommendBooks() } returns listOf(
            RecommendBook("a"), 
            RecommendBook("b"), 
            RecommendBook("c")
          )
        }
      )
      viewModel.loadRecommendBooks()

      val viewState = viewModel.viewState.value
      assertThat(viewState.loading).isFalse()
      assertThat(viewState.recommendBooks.size).isEqualTo(3)
    }
  }
}

割とシンプルにできて良さそう。

患者さんと病院をつないでいくシステムの今とこれから

本エントリはUbie Advent Calendar 2020の22日目です。 21日目はtoCプロダクトAI受診相談ユビーのプロダクトオーナーである@shikicheeのエンジニアの僕が強みを活かして施策推進したら、異次元の角度で数字が伸びちゃった話でした。

自分は現在toBプロダクトである、医療機関向けのAI問診ユビーのソフトウェアエンジニアをしています。普段はRails/Ruby、Spring Boot/Kotlin、React/TypeScriptを使ってバックエンドからフロントエンドまでプロダクトに関連することについて全般的に開発をしています。

またこのほかに最近は全社的な技術戦略に関するロールを持っており、サービス全体のカタチをどのようにしていくかについて考えたり手を動かしたりしています。

本エントリでは、Ubieの現在のシステムの状況と、起こり始めている現象などを紹介しつつ、今後どのようなことを行っていくかについてまとめます。

Ubieの今とサービス群

Ubieは今年で創業から4年目を迎えました。現在のサービス群の基となるコードは、共同創業者の一人である久保(@quvo_ubie)が大学院時代の研究で作り始めました*1。コードベースとしてはこの研究時代の2年間を足した6年物ということになります。

現在のUbieのソフトウェアエンジニアやサービス、プロダクトの数は次の通りです。

• ソフトウェアエンジニアの数： 24人
• サービスの数(デプロイの単位)：15個
• プロダクトの数：4個

独立して動作するサービス群の関連は次のようになっています。

サービスの関連図

この図にプロダクトの境界を引くと...

プロダクトの境界線

結構こんがらがっているように見えますね。実際に結構こんがらがっています。

現在に至る変遷

Ubieでは創業から現在に至るまで、不確実性を下げるための検証にフォーカスしてきました。それぞれの局面毎に、リソースや時間の制約を鑑みて最善手と考えられるものを重ねているものの*2、やはりどうしても複雑化していっています。

創業前 疾患推測エンジン

最初のサービス

• 創業前（およそ2年）
• ソフトウェアエンジニアの数：1人
• サービスの数：1個
• プロダクトの数：0個
• 不確実性：症状群の入力による疾患推測が実現可能か

創業1年〜 toC 症状チェッカー Androidアプリ

AndroidアプリとAPI

• 創業1年~
• ソフトウェアエンジニアの数：2〜3人
• サービスの数：2個 (Androidアプリも1個と数える)
• プロダクトの数：2個
• 不確実性：症状に基づいた疾患推測にニーズがあるのか

創業2年〜 toB AI問診サービス 病院向け

病院向けのフロントエンドを追加

• 創業2年~
• ソフトウェアエンジニアの数：3〜7人
• サービスの数：3個
• プロダクトの数：2個
• 不確実性：症状チェッカーを病院につなげることがそもそもできるのか

疾患推測エンジンの実現、症状チェッカーの価値検証を経た後、出口としては 実際に患者さんが病院に受診する/しないことが重要となってきます。この時点で医療機関にとっては、症状チェッカーは患者さんの受診行動に影響を与えるかもしれませんが、業務上の課題には特に貢献しません。病院に受診した患者さんは改めて1から問診を行うからです。そこで医療機関の業務上の課題解決にフィットするプロダクトの検証が始まりました。

創業2.5年〜 toC 症状チェッカーサービス(テスト版)

チームが複数生まれてサービスも分割されていった

• 創業2.5年~
• ソフトウェアエンジニアの数：7〜12人
• サービスの数：8個 (toC, toB, 疾患推測の単位で分割開始)
• プロダクトの数：2個
• 不確実性：症状に基づいた疾患推測ニーズのスケーラビリティ

医療機関向けのプロダクトの形がある程度見えてきた頃、症状チェッカーのリプレースが始まりました。Androidアプリは廃止し、Webサービスとして作り直しています。アプリの場合、症状チェックをするために症状の発現 -> 症状で検索などをする -> アプリの認知 -> インストール -> チェック という風にかなりの数の手続きを踏まなければなりません。症状があるユーザにとってはかなりの負担です。Webサービスにすることで症状の発現 -> 症状で検索などをする -> ランディング -> チェック とスムーズに症状チェックができるようになりました。同時にその形態でスケールは可能なのかという点の検証が必要となります。

創業3年〜 toB AI問診サービス クリニック向け

病院向けにクリニック向けが乗っかる形

• 創業3年~
• ソフトウェアエンジニアの数：12~18人
• サービスの数：12個
• プロダクトの数：3個
• 不確実性：クリニックでスケールするための特有の普遍的な課題が存在するか

病院とは入院施設としてベッド数が20床以上、医師3名以上の機関を指します。それ以外は診療所となります。街に沢山あるクリニックや医院は診療所です。国内の病院はおよそ8000件で、診療所は100000件です。病院と診療所では来院患者数や医療従事者の規模が異なります。業務上の課題や関心事も大きく異なるのではないか、という仮説のもと、プロダクトを分けて検証をはじめました。

創業4年〜 toB AI問診サービス アジア向け、症状チェッカーと AI問診サービスの接続

あっという間に15個

• 創業4年~
• ソフトウェアエンジニアの数：18~24人
• サービスの数：15個
• プロダクトの数：4個
• 不確実性：
  • AI問診サービスが、海外の医療環境においても課題解決に貢献できるのか
  • 症状チェッカーをトリガーとした、受診をする/しないが起こるのか

国内の医療機関への導入が徐々に進んできたところで、医療制度が近しい国においてもAI問診サービスが役に立つのか検証をはじめました。また国内においては症状チェッカーで行った問診をAI問診サービスを導入している病院に直接送ることができるようになりました。２つのプロダクトが繋がり、サービスの関連図には現れてこない複雑さも生まれ始めています*3。

現在起こっている現象

ソフトウェアエンジニアの人数、サービスの個数、プロダクトの数が着々と増えていく中、開発において起こっている現象が沢山あるわけですが、代表的なものとしては次の通りです。

• 暗黙知の部分のキャッチアップや変更コストが増加
  • 特に文脈を知らない新メンバーは大変そうです。新メンバーはみんな荒野でも生き抜けるパワーを持っていますがとはいえ力を発揮するリードタイムはだんだん増加していっています。
• プロダクト間で共用している箇所が存在し、壊れやすい
  • 共通ではなく共用となっています。一言でいうと1ロジックに2プロダクトの知識が詰まっていたりします。即日壊れます。
• 新しいアイデアの検証をするときのインベストが大きい領域がある
  • たとえば、問診を聴取していくフローは症状チェッカーと医療機関向けプロダクトの両方の知識を有していて、さらにそれぞれが複数のパターンを持っているので、分岐が複雑になっています。特定の診療科向けに柔軟に質問を追加したり省略するといったことを気軽に試すのは難しい状態となっています。

技術的負債という視線

個別に現象に対処して行ってもいいですが、現在の人数やプロダクトの増加速度を鑑みると、もう少し中長期目線で考えたほうがよさそうだなぁということで、技術的負債の観点でそれぞれの現象を見直してみました。

ここでいう技術的負債とは、技術的負債の言葉の生みの親であるウォード・カニンガム氏の次の定義に準じます。

「もしも自分たちが書いているプログラム（WyCash）を、金融の世界に関する正しい捉え方だと自分たちが理解した姿と一致させることができなくなれば、自分たちは絶えずその不一致につまずき続けることになり、開発スピードは遅くなっていくでしょう。それはまるで借金の利子を払い続けるかのようです」

t-wada.hatenablog.jp

それぞれ 正しい捉え方だと自分たちが理解した姿と一致していないのではないか という観点で見直すと、

• 暗黙知の部分のキャッチアップや変更コストが増加
  • システムが、正しい捉え方だと自分たちが理解した姿と一致していない形であることで、リバースエンジニアリング的なアプローチによる理解を困難にしているのではないか。本当に複雑なのか、一致していないのか見直す必要があるのではないか
• プロダクト間で共用している箇所が存在し、壊れやすい
  • 共用している部分が、利用者にとって独立した共通のものなのか、似ている別のものなのかが曖昧。あるべき姿にできていないか、あるべき姿をまだ見いだせていない可能性があるのではないか。
• 新しいアイデアの検証をするときのインベストが大きい領域がある
  • システムが、あるべき姿の解像度が低い段階の時のままになっていることで大きく結合してしまっているのではないか。そのために不確実性の高いものを部分的に足し合わせる時に必要な変更が大きくなるのではないか。

不確実性の高い部分を素早く検証するために、不一致を許容するのは重要である一方で、不確実性が下がった後もその部分を放置しておくと、やがて様々な症状が現れてくるのかなと思います。

不確実性の混在を避ける

逆にこれらを解決していけば、現象の解消や防止ができるのではないかと考えました。

ROIで考える

正しい捉え方だと自分たちが理解した姿と一致させ続けることはとても重要だと考えつつも、とはいえリソースと時間の制約があるので、どこまでなにをするかをどう決めていくかは大事です。Ubieでは皆2言目にはROIだROIだと言っています。

ポジショントーク用のポンチ絵

図はほとんど意味を持っていませんが、つまり、複雑度を上げるような追加変更は線形に増えていきますが、開発のインベストはいつの間にか指数関数的に増加していくので、インベストが爆発するまえになんとかしたい、ということです。同時にこれを予防できればある程度の負債は許容してもよさそうです。

なぜインベストの増加を予防したいのかというと、当然速度やコストに効いてくるからですが、それ以外にも意思決定の歪みを防ぐという観点があるかと思います。

issueの質が高くて低インベストの領域にフォーカスしたい

技術的負債によってインベストが増加すると、質の高いissueであっても優先度が下がったりします。重要な検証の優先度が下がるのは時にクリティカルになります。

issueの質が高いのに高インベストのために後回しになる

ということで、直近で解くべき課題は

1. 現在すでにインベストが高くなっている箇所の解消
2. 将来インベストが高くなると予見される箇所などの可視化
3. 不確実性が高い場所と低い場所が共存できるカタチを見つける（機動的な検証が可能な状態）

かなと定義しました。これによって人数やサービスやプロダクトが増えても速度を落とさない、むしろ加速するような状態を作っていきます。

マイクロサービスアーキテクチャとDDD（ドメイン駆動設計）に入門する

守破離ということで、すでにややマイクロサービスぽく分割していることもあって、マイクロサービスアーキテクチャについて改めてしっかりと入門することにしました。

マイクロサービスアーキテクチャの序盤の章では、サービス分割の観点でDDDを参照しています。

DDDの考え方は、技術的負債のあるべき姿と一致させるという考え方と似ています。エリック・エヴァンスのドメイン駆動設計 では歯を食いしばって真のモデルとシステムを一致させるといった言葉が何度も出てきます。

マイクロサービスアーキテクチャの各種ノウハウを取り入れる前に、まずは現在のシステムとあるべき姿のギャップを、DDDにおけるコンテキストとその境界を描くことで可視化していきました。

あるべき形をコンテキストマップで可視化する

境界づけられたコンテキストを考えていく

コアドメインはなんだろうというところから初めて、徐々に現在のサービス群が何を提供しているかなどを考えながら付け足していきました。

実際の作業はmiroで複数人で行っています。

実際の図。めっちゃぼかしてます。

あんまり現実のシステムを意識せず、理想状態を考えるとスムーズに行くなぁという感想です。同時にあまりにギャップありすぎてちょっと引くみたいな時もあります。

コンテキスト境界と現実の乖離が分かってくる

コンテキストマップを書いていくと、実際のコンテキストとサービスが横断している場所が見えてきました。次の画像は症状チェッカーと医療機関向けプロダクトが連携する箇所ですが、複数のサービスが1つのコンテキストに対して同時に携わっていることがわかります。実際にこの部分は壊れやすく、慎重な変更が必要になってしまっています。

複数のプロダクトが交差する場所

価値創出の単位と業務フロー

また、コンテキストマップを描いていく中で、1つの業務フローに対して、いくつかの独立したコンテキスト達が複数組み合わせられていることに気づきました。

一つの業務フローに対して複数のコンテキストが組み合わさっている

それぞれのコンテキストは個別に価値を生み出せそうな単位でありますが、現状はプロダクトの特定の業務フローのなかに埋まっています。これらを価値創出の単位として切り出せそうです。

それぞれのコンテキストが独立して価値を生み出す

価値創出の単位を自由に組み合わせることができるようになれば、考えてもみなかった、あるいは実現が難しいと思っていたプロダクトをどんどん作り出せるのではないか、と期待できます。

不確実性を内包するためのモジュラモノリスの考え方を取り入れる

コンテキストマップによって現在すでにインベストが高くなっている箇所の解消のためのアクションの洗い出しや、将来インベストが高くなると予見される箇所などの可視化ができました。不確実性が高い場所と低い場所が共存できるカタチを見つけるについてはまだまだこれからですが、価値創出の単位がそれぞれ確からしいかどうかを判断したり、新しい不確実性をどのように追加していくかについて、モジュラモノリスの考え方が役に立つのではないかと思っています。

www.infoq.com qiita.com

モジュラモノリスはモノリスの中でモジュールによって境界を分離していくものです。すでにUbieは複数のサービスが分かれているので、本当のモジュラモノリスにしていくぞというのは現実的ではありません。しかし複数のコンテキストを持っていそうなサービスにおいて、モジュールによる分離をまずは行うというアプローチは非常にコスパが良いのかなと思っています*4。

価値創出を掛け算可能にするシステムを作る

ここから先はまだこれからです。ということでおそらく大小様々な課題と直面していくと思いますが、一連の活動を価値創出を掛け算可能にするシステム の第1歩目と定義し、医療の領域の課題解決を加速していきたいと考えています*5。プロダクト開発もエンジニアリングも好きという方は是非一緒にやっていきませんか！？

note.com

待ってます。

*1:症状に基づいた疾患推測エンジンの研究が、現在のUbieのプロダクトの根幹となっています

*2:もちろん失敗してる場合も沢山あります！

*3:サービスの関連図に現れてないということはどこかのサービスが複数の関心事を取り扱っていることになりますが、まさにそうです！

*4:まだ何も試してないので本当に雰囲気で良さそうって思ってるだけです

*5:正直来年の今頃入社するメンバーがうらやましい！

testing-library/reactでmaterial-uiのTextFieldの値をテストする

material-uiのTextFieldをtesting-library/reactでテストしようとすると、HTMLElementを取り出すところで苦労したのでメモを残す。

TextFieldに付与したaria-labelはinputのラッパー要素に付く

次のTextFieldがどこかのコンポーネントにあるとする。

<TextField
  name="name"
  label="name"
  aria-label="name"
  variant="outlined"
  value="title"
/>

実際にDOMにレンダリングすると次の構造になる。ルートの要素にaria-labelがついていることがわかる。

<div
  aria-label="name"
  class="MuiFormControl-root MuiTextField-root"
>
  <label
  class="MuiFormLabel-root MuiInputLabel-root MuiInputLabel-formControl MuiInputLabel-animated MuiInputLabel-shrink MuiInputLabel-outlined MuiFormLabel-filled"
  data-shrink="true"
  >
  name
  </label>
  <div
  class="MuiInputBase-root MuiOutlinedInput-root MuiInputBase-formControl"
  >
  <input
    aria-invalid="false"
    class="MuiInputBase-input MuiOutlinedInput-input"
    name="name"
    type="text"
    value="title"
  />
  <fieldset
    aria-hidden="true"
    class="PrivateNotchedOutline-root-1 MuiOutlinedInput-notchedOutline"
  >
    <legend
    class="PrivateNotchedOutline-legendLabelled-3 PrivateNotchedOutline-legendNotched-4"
    >
    <span>
      name
    </span>
    </legend>
  </fieldset>
  </div>
</div>

testing-libraryのgetByLabelText関数は、ラベル名でHTMLElementを取り出すので、input要素に直接アクセスできないことがわかる。解決策として2つの方法がある。

querySelector関数を使う

１つ目の方法はgetByLabelText関数でルート要素を取り出したあと、querySelector関数を使ってinput要素を探すというもの。

import { render, cleanup } from "@testing-library/react/pure";
import "@testing-library/jest-dom/extend-expect";
import { TextField } from "@material-ui/core";

describe("Material UIのTextFieldのテスト", () => {
  it("querySelectorを使ってvalueの値をチェックする", () => {
    const result = render(
      <TextField
        name="name"
        label="name"
        aria-label="name"
        variant="outlined"
        value="title"
      />
    );
    // input要素を取り出す。
    const input = result.getByLabelText("name").querySelector("input");
    expect(input?.value).toEqual("title");
  });
});

querySelector("input")の戻り値はHTMLInputElement | null なので適宜nullチェックを加える必要があるが、値を検証するだけならinput?.valueとするだけで十分。

getByDisplayValue関数を使う

2つめの方法は、getByDisplayValue関数を使ってvalue値からinput要素を取り出す。

describe("Material UIのTextFieldのテスト", () => {
  it("getByDisplayValueを使ってvalueの値をチェックする", () => {
    const result = render(
      <div>
        <div>title</div>
        <TextField
          name="name"
          label="name"
          aria-label="name"
          variant="outlined"
          value="title"
        />
      </div>
    );
    const input = result.getByDisplayValue("title");
    // elementが取り出せた時点で 'title' というvalueを持っていることがわかるので
    // このexpectは実際は不要
    expect(input.getAttribute("value")).toEqual("title");
  });
});

getByDisplayValue関数はinput要素系のための関数なので便利なのだが、値を使って取り出すので同じ値のinput要素があったりするとエラーになってしまう。

おわりに

個人的にはラベルを指定した上でquerySelector関数を使う方法が好きですが、しかしMaterial UIの内部構造を知った上で書く必要があるのでちょっとな〜という気はしますが仕方ない気もする。

bit全探索 in Kotlin

最近AtCoderなどに参加していて、すべての組み合わせを生成しつつ計算するといった機会になんどか遭遇し、毎回頑張って実装していたのだけど、bit全探索という方法があるらしいと知り、調べて、Kotlinでどう書くか考えた結果次のようになった。

import java.util.BitSet

fun bitFullSearch(n: Int): List<BitSet> = (0 until (1 shl n)).map { bit ->
    BitSet(n).apply {
        repeat(n) { i ->
            set(i, bit and (1 shl i) > 0)
        }
    }
}

たとえば bitFullSearch(4) などと呼び出すと、それぞれ次のbitが立ったBitSetのリストが手に入る。

{}
{0}
{1}
{0, 1}
{2}
{0, 2}
{1, 2}
{0, 1, 2}
{3}
{0, 3}
{1, 3}
{0, 1, 3}
{2, 3}
{0, 2, 3}
{1, 2, 3}
{0, 1, 2, 3}

bitSet.get(i) でそのインデックスのビットが有効かBooleanが手に入るほか、bitSet.stream()で有効なインデックスのストリームが手に入るので大体いい感じにできる。

Material-UIのHidden要素をテストする

個人のプロジェクトでMaterial-UIを使っているんですが、 コンポーネントがHiddenを含んでいると、テストがうまく動きません。

hoge.tsx

import * as React from 'react';
import {Hidden} from "@material-ui/core";

export const Hoge = (): JSX.Element => {
  return (
    <div>
      <Hidden mdUp>
        <div>mdUp</div>
      </Hidden>
      <Hidden smDown>
        <div>smDown</div>
      </Hidden>
    </div>
  )
};

hoge.test.tsx

import React from "react";
import {render, cleanup} from '@testing-library/react'
import {Hoge} from "../hoge";

afterEach(async () => {
  await cleanup();
});

describe('hoge', () => {
  describe('ある幅以上の時のレンダリング', () => {
    it('mdUpが表示される', () => {
      const {getByText} = render(
          <Hoge/>
      );
      expect(getByText("mdUp")).toBeVisible()
    });
  });
});

見つけられない...ていうかそもそもHidden要素がどっちもレンダリングされていない

TestingLibraryElementError: Unable to find an element with the text: mdUp. This could be because the text is broken up by multiple elements. In this case, you can provide a function for your text matcher to make your matcher more flexible.

    <body>
      <div>
        <div />
      </div>
    </body>

      13 |           <Hoge/>
      14 |       );
    > 15 |       expect(getByText("mdUp")).toBeVisible()
         |              ^
      16 |     });
      17 |   });
      18 | });

環境

"@material-ui/core": "^4.10.2",
"react": "^16.13.1",
    
"@testing-library/dom": "^7.16.3",
"@testing-library/jest-dom": "^5.10.1",
"@testing-library/react": "^10.3.0",
"@testing-library/user-event": "^12.0.7"

原因など

Unable to test React with Material-UI Hidden element · Issue #2179 · enzymejs/enzyme · GitHub によると、jest-domとmaterial-uiの双方に課題があるようです。 -> https://github.com/enzymejs/enzyme/issues/2179#issuecomment-528973289

対応

対応方法は2つほどあるぽいです、ここではかんたんな方を書きます。 テスト側でrenderするときにcreateMuiThemeを用いて初期の画面幅を指定するやりかたです。

import React from "react";
import {render, cleanup} from '@testing-library/react'
import {createMuiTheme, MuiThemeProvider} from "@material-ui/core";
import {Hoge} from "../hoge";

afterEach(async () => {
  await cleanup();
});

describe('hoge', () => {
  describe('ある幅以上の時のレンダリング', () => {
    it('mdUpが表示される', () => {
      const theme = createMuiTheme({props: {MuiWithWidth: {initialWidth: 'sm'}}})
      const {getByText} = render(
        <MuiThemeProvider theme={theme}>
          <Hoge/>
        </MuiThemeProvider>
      );
      expect(getByText("mdUp")).toBeVisible()
    });
  });
});

これで画面幅を指定して実行できます。 initialWidthをmdにするとsmDownの方の要素が表示状態になります。

おわりに

ReactでTDDでやっていくぞと思って触り始めたけどやはりUI部分はなかなか大変だなと思いつつ、Androidよりは楽かもという気持ち

Jetpack Compose 0.1.0-dev05から0.1.0-dev06にしたときに変更が必要だったところ

前回に引き続いて。

left, rightがstart, endに

レイアウトのleft, rightが start, endになりました。なるだろうなーと思ってたので想定どおり。

before

LayoutPadding(
  top = 16.dp
  left = 8.dp,
  right = 8.dp,
  bottom = 16.dp
)

after

LayoutPadding(
  top = 16.dp
  start = 8.dp,
  end = 8.dp,
  bottom = 16.dp
)

DrawImageを廃止

Imageを描画するDrawImageがなくなりました。代わりにSimpleImageを使います。このあたりは今後も色々と変わりそうですね。

before

Container(
  width = 100.dp,
  height = 200.dp
) {
  DrawImage(image)
}

after

Container(
  width = 100.dp,
  height = 200.dp
) {
  SimpleImage(image)
}

androidx.compose.Contextを廃止

ContextAmbientはandroidx.compose.Contextを返してましたが、androidx.compose.Contextになりました。

before

import androidx.compose.Context

after

import android.content.Context

AppBarIconを廃止

TopAppBarのnavigationIconに使うAppBarIconがなくなり、代わりにIconButtonを使う形になりました。

before

TopAppBar(
  title = {
    Text(context.getString(R.string.app_name))
  },
  navigationIcon = {
    AppBarIcon(
      icon = ImagePainter(BitmapImage(context.getBitmap(R.drawable.ic_baseline_arrow_back_24))),
      onClick = {
        backStack.pop()
      }
    )
  }
)

IconButtonを使う場合のほうが冗長ですが、children: @Composable() () -> Unitを受け取るのでより柔軟な表現が可能になってます(例えばTextを渡してもちゃんと動く)。

after

TopAppBar(
  title = {
    Text(context.getString(R.string.app_name))
  },
  navigationIcon = {
    IconButton(
      onClick = {
        backStack.pop()
      }
    ) {
      SimpleImage(
        BitmapImage(context.getBitmap(R.drawable.ic_baseline_arrow_back_24))
      )
    }
  }
)

ArrangementにVertical, Hotizontalの概念を追加

Column, RowともにArrangementが設定できますが、寄せる方向の設定がStart, Endという名前でした。なので次のように同じ値でもColumnかRowかで意味が異なります。

before

Column(
  modifier = LayoutWidth.Fill,
  arrangement = Arrangement.End // 下寄せ
) {
  Row(
    modifier = LayoutWidth.Fill,
    arrangement = Arrangement.End // 右寄せ
  ) {
    // something
  }
}

ArrangementにVertical, Hotizontalの概念を追加し、使える値を増やしつつ制限をかけています。これにより意味を理解しやすくなりました。

after

Column(
  modifier = LayoutWidth.Fill,
  arrangement = Arrangement.Bottom // Arrangement.Endは使えない
) {
  Row(
    modifier = LayoutWidth.Fill,
    arrangement = Arrangement.End
  ) {
    // something
  }
}

おわりに

今までは1ヶ月に1リリースという感じでしたが、2月は2回ありました。I/Oに向けてガガガッとスパートかけてる感じなんでしょうか。楽しみですね。

Jetpack Compose 0.1.0-dev05で追加されたAdapterListを眺める

Jetpack Compose 0.1.0-dev05がリリースされましたね。0.1.0-dev05でui-foundationにAdapterListというComposableが追加されました。

待望のAdapterList

AdapterListの説明は次のようになっています。

A vertically scrolling list that only composes and lays out the currently visible items.

今まではRecyclerViewのようなComposableが存在せず、VerticalScrollerを使ってそれっぽい動作をしていましたが、VerticalScrollerはScrollViewと同じものなので実用には限界がありました。

AdapterListはRecyclerViewと同じように、表示されている要素だけをレンダリングするので、大量の要素があってもサクサク動作します。

AdapterListの使い方

AdapterListのシグネチャは次の通りです。

@Composable
fun <T> AdapterList(
  data: List<T>,
  modifier: Modifier = Modifier.None,
  itemCallback: @Composable() (T) -> Unit
)

実際に使うには次のようになります。

import android.os.Bundle
import androidx.appcompat.app.AppCompatActivity
import androidx.ui.core.Text
import androidx.ui.core.setContent
import androidx.ui.foundation.AdapterList
import androidx.ui.layout.Container
import androidx.ui.layout.LayoutPadding
import androidx.ui.layout.LayoutWidth
import androidx.ui.material.MaterialTheme
import androidx.ui.material.surface.Card
import androidx.ui.unit.dp

class MainActivity : AppCompatActivity() {
  override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    setContent {
      MaterialTheme {
        val data = 0.until(100).toList()
        AdapterList(data = data) {
          Card(modifier = LayoutPadding(top = 8.dp, bottom = 8.dp, left = 16.dp, right = 16.dp)) {
            Container(modifier = LayoutWidth.Fill + LayoutPadding(16.dp)) {
              Text("Hello ${it}")
            }
          }
        }
      }
    }
  }
}

AdapterListはまだ実用できない

0.1.0-dev05の時点ではまだ2コミットしかないので、実用に足らないのは当然っちゃ当然かなと思います。 https://android.googlesource.com/platform/frameworks/support/+log/refs/heads/androidx-compose-release/ui/ui-foundation/src/main/java/androidx/ui/foundation/AdapterList.kt

具体的な問題としては 要素のクリックイベントが動作しない という点があります。例えば次のコードのButtonはうまく動作しません。

class MainActivity : AppCompatActivity() {
  override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    setContent {
      MaterialTheme {
        val data = 0.until(100).toList()
        AdapterList(data = data) { value ->
          Card(modifier = LayoutPadding(top = 8.dp, bottom = 8.dp, left = 16.dp, right = 16.dp)) {
            Container(modifier = LayoutWidth.Fill + LayoutPadding(16.dp)) {
              Button(onClick = {
                println("click! $value")
              }) {
                Text("button ${value}")
              }
            }
          }
        }
      }
    }
  }
}

いくらか実験してみたところ、Ripple要素があるとクリックイベントが実行されないようです。Buttonは　Ripple + Clickableで構成されているので反応しなくなっているようです。Rippleを使わずClickableのみを使えば動作はするのですが、タッチフィードバックがなくなるので厳しいです。

もちろんこうした問題は今後どんどん改善されていくと思いますが、今すぐに使うというのはちょっと難しそうです。

おわりに

ついにAdapterListが登場して実用段階への光が射してきましたね。さすがにプロダクション投入はまだまだ難しいですが、一部のViewをComposeに置き換えるのは十分できそうだなぁと思います。