フロントエンドの単体テストってなんだ・・・？

※ 個人的見解が大いに含まれる内容になります。

自分がフロントエンドの技術を触り始めたとき、「サーバーサイドのテストについてはなんとなくわかるんだけど、フロントエンドのテストって何を確認すればいいの・・・？」と感じたので自分の中でのモヤモヤの解消も含めてまとめておきます。

フロントエンドの単体テストがしっくりこない・・・

テスト自動化やテストコードを書くことが昨今当たり前になりつつあります。

私自身もテストは書いて当たり前と考えているエンジニアの一人です。

しかし、フロントエンドのテストについてはいまいち何をテストすればよいのか理解できていませんでした。

そもそも単体テストって？

まずはWikiってみました。

単体テスト

コンピュータプログラミングにおいて単体テスト（たんたいテスト）あるいはユニットテスト（英語: Unit test）とは、ソースコードの個々のユニット、すなわち、1つ以上のコンピュータプログラムモジュールが使用に適しているかどうかを決定するために、関連する制御データ、使用手順、操作手順とともにテストする手法である[1]。ユニットとはアプリケーションのテスト可能な最小の部品単位である、と直観的にとらえることができる。手続き型プログラミングでは、ユニットは、モジュール全体のこともあるが、より一般的には、個々の関数や手続きである。オブジェクト指向プログラミングでは、ユニットは、クラスなどのインタフェース全体だが、個々のメソッドであることもある[2]。単体テストは開発プロセス中にプログラマー、時にはホワイトボックステスターによって作成される。

ざっくりとテスト可能な最小単位でのテストと読み取れそうです。

個人的にはこの「テスト可能な最小単位」という認識の仕方に各開発現場ごとに差があるように感じています。

私自身、前職ではSES等で複数の開発現場を見てきました。

関数やモジュールのような単位でのテストを単体テストと呼んでいることもあれば、各機能単位でのテストを単体テストと呼んでいることもありました。

（個人的な経験としては、前者はテストコードを書いていることが多く、後者は手動テストの場合が多かったように思います。）

開発チームによって粒度も違えばルールも違うのです。

サーバサイドHTMLテンプレートを使ったWebアプリケーションにおける単体テスト

（令和の時代にこの話をするのもどうなのかという気もしますが・・・）

サーバサイドHTMLテンプレートでのWebアプリケーション（=WebサーバーがHTMLを生成してレスポンスとして返すもの）における単体テストを考えます。

構成を図にすると以下のようになるかと思います。

例えば、この構成で単体テストを書く場合、②の部分のテストを主に書いていくことになるかと思います。

①や③を含める場合は結合テストに入ってくるのかなと思っています。

（無論このあたりの粒度感もチームによる部分もあるかと思いますが、上記の想定で以降進んでいきます。）

SPAでの単体テスト

一方で同じことをSPAで考えてみます。

こちらも構成を図にすると以下のようになるかと思います。

サーバサイドHTMLテンプレートでの例をベースに考えると、⑤の単体テストは同じように書けそうです。

ですが、フロントエンドの方はどうすべきでしょうか？

個人的にフロントエンドでの単体テストのイメージが湧かなかったのはこの部分です。

自分の結論を言うと、フロントエンドの単体テストで主に確認すべきことは、データ（JSON等）を受け取ったときに想定通りの表示・挙動がされるかどうか、各種イベント発火時に想定通りの挙動をするかどうか（他にもあるかも）かと考えます。

要はサーバサイドHTMLテンプレートの方では結合テストで確認されていたことが、フロントエンドとバックエンドを分けたことによって単体のレベルが変わってくるということですね。

最後に

自分の中でモヤモヤしていたことを文章にしてみました。

なんとなくのイメージですが、アプリケーションが分かれたことで、フロントエンドがAPIのデータを引数に受け取る関数のような感じになった気がしています。

同じような悩みを抱えている方の参考になれば嬉しいです。

具体的なテストコードについての記事も近日書きたいと思っています。