Elmで超高速 型安全スナップショットテストのススメ

# スナップショットテスト

スナップショットテストはご存知でしょうか？ スナップショットテストはそうなって欲しい結果を何らかの形で保存しておき、それと実際の結果のdiffを取ることでテストをする手法です。何らかの形とは、画像・HTML・JSXだったりします。詳しくは以下のリンクを参考にしてください。

- [screenshot-tests-for-android](https://facebook.github.io/screenshot-tests-for-android/)
- [Jest snapshot-testing](https://jestjs.io/docs/ja/snapshot-testing)
- [どのようにreduxのreducerのテストを書くか？
](https://qiita.com/akameco/items/31e2078c38ff2fd60213)

## なぜスナップショットテストをしたいか？

なぜスナップショットテストをしたいのでしょうか？ それはプログラム変更における影響が起きていないか、リグレッションテストを行うより早い開発段階でデグレーションを発見するためです。例えば、あるロジック対する単体テストを書いておきロジックの妥当性を担保していたとしても、そのロジックを用いて画面の描画を行う場合、その画面がどういう結果をもたらすかは単体テストは担保してくれません。そのため多くの場合、コストの高いE2Eテストや人間が手動でそれを発見しなければなりません。スナップショットテストはリグレッションテストの割合を軽減してくれます。

![](https://2.bp.blogspot.com/-bgp_dtWgc_Q/VhHgYO6S8wI/AAAAAAAAy7k/aaIZ6faHPEY/s400/computer_manual_man.png)

## Humbleオブジェクトパターン

一つの解決策としては[クリーンアーキテクチャ](https://www.amazon.co.jp/dp/B07FSBHS2V)の本にも記載されている、Humbleオブジェクトパターンなどを用いる方法です。Humbleオブジェクトパターンは、GUIにおけるViewやDBなどの出力先への境界は単体テストが難しいという前提で、なるべく単体テストに吸収出来るように寄せるというシンプルながら強力な手法です。

例えばある整数をviewでは文字列に変換したいとしましょう。ここでは正しく文字列に変換されたかどうかを調べる術は、実際にアプリケーションを起動して確かめなければなりません。

```elm
type alias Model =
    { x : Int, y : Int }

view : Model -> Html Msg
view { x, y } =
    div []
        [ h1 [] [ text <| String.fromInt x ]
        , h2 [] [ text <| String.fromInt y ]
        ]
```

それを防ぐために、ViewModelというviewに使われるだけ(表示用)のモデルを用意することで、このViewModelに変換するtoViewModel(Presenter)の妥当性を調べることができる。それによりviewにまつわるロジックの担保をおこなうと言うのがHumbleオブジェクトパターンです。

```elm
type alias Model =
    { x : Int, y : Int }

type alias ViewModel =
    { x: String, y: String }


toViewModel : Model -> ViewModel
toViewModel { x, y } = 
    { x = String.fromInt x, y = String.fromInt y }

view : Model -> Html Msg
view model =
    let
        { x, y } = toViewModel model
    in
    div []
        [ h1 [] [ text x ]
        , h2 [] [ text y ]
        ]
```

非常にシンプルで強力なパターンですが、本来作る必要がなかったViewModelやPresenterを用意しなくてはならないため、開発コストが掛かってしまい担保したいロジックに対してコストが掛かりすぎると言うのが問題として挙げられます。Elmは型に対して厳密なため、特に上のような単純過ぎるロジックの場合、行う必要がないと判断されてしまうケースがほとんどです。そのため、このパターンを利用するかどうかの選択をすること自体が、大きなコストだと言えます。

# Elmにおけるスナップショットテスト

私自身、Humbleオブジェクトパターンをコストと感じつつも品質を担保するには必要なコストだと思い活用し続けていました。しかしちょうど一ヶ月ほど前、Elmの公式テストフレームワークである、[elm-explorations/test](https://package.elm-lang.org/packages/elm-explorations/test/latest/)に、[Htmlテスト](https://package.elm-lang.org/packages/elm-explorations/test/latest/Test-Html-Query)が統合されました！これは見事にそのコストを解消してくれました！一言で言うとHtmlテストは、**単体テストレベルでスナップショットテストを高速かつ型安全**におこなってくれるものでした！

Htmlテストは、以下の３つのモジュールを組み合わせて使います。本記事では順番にサンプルを載せながら説明をしていきたいと思います。

- [Query](https://package.elm-lang.org/packages/elm-explorations/test/latest/Test-Html-Query)
    - Htmlを絞り込んだり、検証(assert)をおこなう
- [Selector](https://package.elm-lang.org/packages/elm-explorations/test/latest/Test-Html-Selector)
    - タグや属性などの絞り込みに使う要素(CSSセレクタのようなもの)
- [Event](https://package.elm-lang.org/packages/elm-explorations/test/latest/Test-Html-Event)
    - Htmlのイベントをシミュレーションして検証をおこなう

## Test.Html.Query, Selector

ここではHtmlの比較をおこなうために使うQueryとSelectorのモジュールについて説明をしていきます。Queryで一番大事な概念は、[Single](https://package.elm-lang.org/packages/elm-explorations/test/latest/Test-Html-Query#Single)と[Multiple](https://package.elm-lang.org/packages/elm-explorations/test/latest/Test-Html-Query#Multiple)になります。非常に簡単な概念で、単一のタグであればSingle, 複数のタグであればMultipleになります。

Elmのviewの型である`Html msg`型から`Query.fromHtml`関数によって`Single msg`型に変換されます。Htmlテストではかならず、単一のタグからスタートすることになります。

```elm
-- <h1>foo</h1>

h1 [] [ text "foo" ] |> Query.fromHtml
```

Multipleになるケースとして、Singleから条件に一致するすべての要素を取る[findAll](https://package.elm-lang.org/packages/elm-explorations/test/latest/Test-Html-Query#findAll)か、ある要素の子要素を取る[children](https://package.elm-lang.org/packages/elm-explorations/test/latest/Test-Html-Query#children)関数を使います。

```elm
{--|
<li>aaa</li>
<li>bbb</li>
<li>ccc</li>
--}

ul []
    [ li [] [ text "aaa" ]
    , li [] [ text "bbb" ]
    , li [] [ text "ccc" ]
    ]
    |> Query.fromHtml
    |> Query.children [ Selector.tag "ul" ]
```

逆にSingleからMultipleになるケースとして、複数の要素の先頭を取る[first](https://package.elm-lang.org/packages/elm-explorations/test/latest/Test-Html-Query#first)と任意のインデックスの要素を取る[index](https://package.elm-lang.org/packages/elm-explorations/test/latest/Test-Html-Query#index)があります。

```elm
{--|
<li>aaa</li>
--}

ul []
    [ li [] [ text "aaa" ]
    , li [] [ text "bbb" ]
    , li [] [ text "ccc" ]
    ]
    |> Query.fromHtml
    |> Query.children [ Selector.tag "ul" ]
    |> Query.first
```

```elm
{--|
<li>bbb</li>
--}

ul []
    [ li [] [ text "aaa" ]
    , li [] [ text "bbb" ]
    , li [] [ text "ccc" ]
    ]
    |> Query.fromHtml
    |> Query.children [ Selector.tag "ul" ]
    |> Query.index 1
```

### assert

実際にテストを書いてみましょう。`count`の数だけ文字列をリピートする操作をリストの数だけliにするviewのロジックがあったとしましょう。(説明がわからなくてもテストを見れば一目瞭然です！)

```elm
type alias RepeatableStr =
    { count : Int, str : String }


type alias Model =
    { repeatList : List RepeatableStr }


view : Model -> Html Msg
view { repeatList } =
    ul [] <|
        List.map
            (\{ count, str } ->
                li [] [ text <| String.repeat count str ]
            )
            repeatList
```

テストでは与えられたrepeatListが生成したviewに対して、以下のような`List (Html msg)`(liのリスト)が含まれていることをテスト出来ます。一般的な文字列を用いてHtml(やJSX)と比較するスナップショットと違い、Elmのコンパイラによって検査されているため、間違った記法はそもそもコンパイルエラーになってしまうことが特徴です。

```elm
suite : Test
suite =
    describe "The Main module"
        [ describe "view"
            [ test "repeatList" <|
                \_ ->
                    let
                        model =
                            { repeatList =
                                [ RepeatableStr 1 "a"
                                , RepeatableStr 2 "b"
                                , RepeatableStr 3 "c"
                                , RepeatableStr 4 "d"
                                ]
                            }
                    in
                    view model
                        |> Query.fromHtml
                        |> Query.contains
                            [ li [] [ text "a" ]
                            , li [] [ text "bb" ]
                            , li [] [ text "ccc" ]
                            , li [] [ text "dddd" ]
                            ]
            ]
        ]
```

`Html msg`でわざわざ全体を比較する必要が無い場合がほとんどです。そのようなときには、[has](https://package.elm-lang.org/packages/elm-explorations/test/latest/Test-Html-Query#has)や[hasNot](https://package.elm-lang.org/packages/elm-explorations/test/latest/Test-Html-Query#hasNot)を用いて検証します。

```elm
test "The list has both the classes 'items' and 'active'" <|
    \() ->
        div []
            [ ul [ class "items active" ]
                [ li [] [ text "first item" ]
                , li [] [ text "second item" ]
                , li [] [ text "third item" ]
                ]
            ]
            |> Query.fromHtml
            |> Query.find [ tag "ul" ]
            |> Query.has [ tag "ul", classes [ "items", "active" ] ]
```

```elm
test "The div element has no progress-bar class" <|
    \() ->
        div [ Attributes.class "button" ] []
            |> Query.fromHtml
            |> Query.find [ Selector.tag "div" ]
            |> Query.hasNot [ Selector.tag "div", Selector.class "progress-bar" ]
```

テストが通らなかったケースはどうなるのか見てみましょう。例えば以下の検証で、`<li>z</li>`を期待してみましょう。

```elm 
test "repeatList" <|
                \_ ->
                    let
                        model =
                            { repeatList =
                                [ RepeatableStr 1 "a"
                                , RepeatableStr 2 "b"
                                , RepeatableStr 3 "c"
                                , RepeatableStr 4 "d"
                                ]
                            }
                    in
                    view model
                        |> Query.fromHtml
                        |> Query.has
                            [ Selector.tag "li", Selector.text "z" ]
            ]
```

すると、`Query.fromHtml`の結果やどう比較使用して、どう失敗したかを教えてくれます。さらに実行時間に注目してください。非常に高速にテストが終了していることがわかります。これは実際にブラウザを立ち上げることなく、仮想DOMによる純粋なロジックをしているため単体テストと何も変わらないためです。これは非常に強力で柔軟です。ブラウザを用いたテストは不安定で低速です。本番環境に近いという点では重要ですが、ロジックのテストを担保するために不安定なテストでは、保守が難しく捨てられてしまいがちです。本番環境に近い状態でのテストはE2Eが担保するため、このような表示ロジックを行うテストでは高速で安定して回せることのほうが重要だと言えます。

```elm 
↓ Tests
↓ The Main module
↓ view
✗ repeatList

    ▼ Query.fromHtml

        <ul>
            <li>
                a
            </li>
            <li>
                bb
            </li>
            <li>
                ccc
            </li>
            <li>
                dddd
            </li>
        </ul>


    ▼ Query.has [ tag "li", text "z" ]

    ✓ has tag "li"
    ✗ has text "z"



TEST RUN FAILED

Duration: 178 ms
Passed:   0
Failed:   1
```

他にも今回は紹介しませんが、Multipleに対して数を比較したり複数の検証を掛ける関数が存在します。SingleとMultipleの違いさえ抑えておけば後は型が導いてくれます。非常に単純なのでマスターしましょう。

### Event

最後にEventの検知について簡単に紹介します。Htmlの検証について仮想DOMを用いた手法を用いて検証していることを紹介しました。Eventも例外ではありません。とても単純です。生成したSingleに対して、[simulate](https://package.elm-lang.org/packages/elm-explorations/test/latest/Test-Html-Event#simulate)でシミュレートしたイベントを記述してあげるだけです。イベントは何を発行するでしょうか？そうMsgです。expect関数は、実装モジュールで定義しているMsgが発行されているかを検証します。

```elm 
import Test.Html.Event as Event

type Msg
    = Change String


test "Input produces expected Msg" <|
    \() ->
        Html.input [ onInput Change ] [ ]
            |> Query.fromHtml
            |> Event.simulate (Event.input "cats")
            |> Event.expect (Change "cats")
```

検証はこれだけで良いのでしょうか？Msgが発行されていることが保証されているだけで、正しくviewの値が書き換えられているかどうかを確認したくなります。しかし、[The Elm Architecture](https://guide.elm-lang.jp/architecture/)により、update関数において、すべてのMsgが捌かれていることが保証されています！(なんて素晴らしいのでしょうか！) updateのMsgの分岐で複雑なロジックがあれば別途切り出して単体テストをおこなえば良いでしょうし、それによって書き換えたロジックが正しいviewが生成されているかどうかは、さきほど説明したHtmlテストをおこなえば良いでしょう。ロジックの途中で非同期APIを利用したり乱数などが生成される場合には、[Cmdという素晴らしい仕組み](https://qiita.com/ababup1192/items/2b86ade96651716fc3a8)が安全性を担保してくれます。システムとして正しく動いているかどうかを検証したくなったタイミングでE2Eなどのリグレッションテストをおこないますが、今までよりかなり比重は小さくなっていると思います。

# まとめ

Elmにおけるスナップショットテストを紹介しました。これは単なるElmにおけるスナップショット手法というわけではなく、単体テストと同じ粒度で高速かつ安全に行えるという点で非常に使い勝手の良いテスト手法を提供していることとなります。そのような仕組みを利用することで、テストそのものの敷居が低くなり、安全で安心なアプリケーションづくりが可能になります。是非Elmをお試しください！