フロントエンドのテストは見るべき部分が多く、大変だと言われている。 複雑性の本質を見るとフロントエンドのプログラミングがロジックに合わせて画面UIが変化をする、に起因すると考える。 フロントエンドで行うテストの種類は <ol><li>ロジックレベルの単体テスト</li><li>UIコンポーネントテスト</li><li>結合テスト(E2Eテスト)</li><li>リグレッションテスト</li></ol> が挙げられる。(他にもあるかもだが) <h4 id="h44a6d4560e">ロジックレベルの単体テスト</h4>最も取り組みやすいものの一つ。 関数単位でそれぞれのパターンごとに期待値を書いていき、判定を行う。 エンジニアがいう「テストコード」でいうと真っ先に思い浮かぶやつ。 ReactやNextでは以下のライブラリが非常に良い。 <a href="https://testing-library.com/docs/react-testing-library/intro/" target="_blank" rel="noopener noreferrer">https://testing-library.com/docs/react-testing-library</a> 気をつけている点としては 質の悪いテストコードを書かない →結果が自明である関数のテストコードはわざわざ書かない 闇雲に書くとメンテナンスコストは高くなるし、やる範囲は絞った方が良い。 自分の場合の優先順位だと下記に絞っている。 1.ドメインロジック層 2.カスタムフック層 3.通信層の一部 <h4 id="h900897c258">UI単体コンポーネントテスト</h4>これも比較的取り組みやすいものの一つ。 先程のテストライブラリや状況によってはStorybookも代用になる。 スナップショットによるコンポーネントテストは一時期やっていたが、DOM要素が複雑になると確認がしづらくなり、途中でやめた。 <h4 id="h240642deb2">結合テスト(E2Eテスト)</h4>非常にやりづらいテスト。 最近はCypressとかが出てきて随分楽になった。 ただし、こちらは自動テストツールだと起動や実行が遅い場合があり、特にテストファイル数が多くなると顕著になる。 結合テストについてはサービスで特に重要な機能だけに自動化を絞ってCypressに回させた方が良い。 人間の介入が引き続き必要とする領域と思われる。 <h4 id="ha631e69f04">リグレッションテスト</h4>いわゆる退行テスト。 修正したコードが他の無関係な部分に影響が及んでいないかを確認するテスト。 UIのリグレッションテストについてはreg-suitとstorycapである程度自動で行うことが可能となっている。 導入自体は難しくはないが、こちらもやる範囲を決めないと無駄なケースが増えると思われる。 <a href="https://github.com/reg-viz/reg-suit" target="_blank" rel="noopener noreferrer">https://github.com/reg-viz/reg-suit</a> <a href="https://github.com/reg-viz/storycap" target="_blank" rel="noopener noreferrer">https://github.com/reg-viz/storycap</a> フロントエンドのテストは本当にやり出すとキリがない状態になる。 なので現状においては必要なタイミングで必要なツールを用いて、範囲と目的を限定させて実行するのが良さそう。

フロントエンドのテストは見るべき部分が多く、大変だと言われている。

複雑性の本質を見るとフロントエンドのプログラミングがロジックに合わせて画面UIが変化をする、に起因すると考える。

フロントエンドでできるテストの種類は



フロントエンドのテストの複雑性

ブログ記事を自分の学習のために見直す時があるのだが、記事数が10件超えると検索が欲しくなる。 なので作ってみた。 まだ未対応な機能としてページネーションとOR検索があるけど、まぁそれはそのうち必要になったら実装すれば良いやぐらいな感覚で。。 SSGだとクライアントから直接検索のAPIを叩くわけにはいかないので、そこらへんは文献を読んで、クライアントからは APIを直接叩かない方法で実装した。このあたりの実装方法も面白いので今度紹介できたらと思う。 あとは個人的にはnext/routerの使い方とか勉強になったりしたのでとても良い体験になった。 余談だがNext.jsやNuxt.jsでプロダクトを実装するとフロントエンドのフルスタック化が凄まじいと感じる。 多分将来的にフロントエンドエンジニアという肩書きはなくなりそう。 アプリエンジニアとか、もっと領域が広くなるとフルスタックエンジニアになるかも。

ブログ記事を自分の学習のために見直す時があるのだが、記事数が10件超えると検索が欲しくなる。
なので作ってみた。まだ未対応な機能としてページネーションとOR検索があるけど、まぁそれはそのうち必要になったら実装すれば良いやぐらいな感覚で。。

ブログ記事に全文検索を追加した

Cypressをご存知であろうか。 もしあなたが画面をチェックする複合テストでエクセルにテストチェックシートを作成し、画面の表示チェックをするという 退屈なことを毎日しているならその退屈さを軽減できるかもしれない。 <h4 id="ha32723984a">Cypressとは</h4>複合テスト(e2eテスト)を自動化してくれるテストツールである。 画面で例えば特定の要素が表示されているかとかはテストコード一行書くと自動実行してくれる。 これを少し応用すると例えばフォームにテスト用のユーザー情報を添付して、ログインができるかを自動実行してくれる。 テスト実行するとこんな風に自動処理してくれる <img src="https://images.microcms-assets.io/assets/f9ba4609593647fdb1caa834aab8b0d4/4f7f5cf54d6443e2b804b2585f1d2ca2/output.gif" alt=""> これをどのレベルまで実行していくかは別問題だが、単純な要素テストはこれで十分な気がする。 個人的にはログイン機能など仕様として不変の色合いが強い機能に対しては極めて有効であると考える。(認証の仕様が日々動的に変化するなど仕様上あり得ないからである) <h4 id="hf031c5e696">実装方法</h4>フロントエンド環境でTypeScriptを導入しているのであれば、TypeScript側が提案している下記のやり方に従うのがベストそうである。 <a href="https://basarat.gitbook.io/typescript/intro-1/cypress" target="_blank" rel="noopener noreferrer">公式ドキュメント</a> ポイントとしてはe2eテストコード環境は 実装コード環境とは独立させること だと思っている。なので別途e2eフォルダなんかを作成して、モジュール依存関係を切り離す状態にすると変更に強いe2eテスト構造になりそう。

Cypressをご存知であろうか。
もしあなたが画面テストでエクセルにテストチェックシートを作成し、画面を表示チェックをするという
退屈なことを毎日しているならその退屈さを軽減できるかもしれない。


Cypressでお手軽画面テスト

早くリリースしたいから雑なコードでもとっととやろうぜ、は自らの首を締める。 最近読んで本当にしっくりくる資料であった。質とスピードの関係性は最も判断を誤る材料である。 最初から質に投資することで、将来のダメージを最小限に食い止めることができる。 <a href="https://speakerdeck.com/twada/quality-and-speed-2020-autumn-edition?slide=54" target="_blank" rel="noopener noreferrer">詳細はこちらより</a>

早くリリースしたいから雑なコードでもとっととやろうぜ、は自らの首を締める。
最近読んで本当にしっくりくる資料であった。

質とスピードという資料を読んで

<h4 id="h833f40a2cb">Lighthouseでwebページの品質を測定</h4> webページの品質測定には様々な見方があるし、測定ツールも様々である。 今回はそんな中でLighthouseを紹介したい。 LighthouseはChromeの拡張ツールで導入できる、手軽なwebページの測定ツールである。 測定は多岐にわたるが、大きくは以下の五つに集約される。 <ul><li> Performance</li><li> Accessibility</li><li> Best Practices</li><li> SEO</li><li> PWA</li></ul> それぞれのスコアの見方については公式ドキュメントにあるので、読んでみると良さそう。 <a href="https://developers.google.com/web/tools/lighthouse?hl=ja" target="_blank" rel="noopener noreferrer">紹介ドキュメントはこちら</a> <a href="https://web.dev/learn/#lighthouse" target="_blank" rel="noopener noreferrer">スコアの見方</a> 当サイトも最初にテストした時はアクセシビリティに改善ポイントがあることがわかった。(ありがたいことにどうやって修正すれば改善するかも教えてくれる) 地道に修正していくと、下記の感じになり、合格点に到達していると思われる。 <img src="https://images.microcms-assets.io/protected/ap-northeast-1:658ce9f3-f881-4ea3-8c24-a60e5d6296f2/service/sirius/media/lighthouse_score.png" alt=""> 手軽な計測ツールがChromeの拡張ツールで取り入れられるので、まだ入れてないエンジニア、サービス関係者だったら、ぜひ入れて欲しいと思う。 品質を100%保証するものではないが、今よりは明らかに改善できるツールである。 あと、重要な事実としてこれらの指標が2021年5月あたりからのGoogleの検索ランキングに影響するという見解を出しているそうだ。 影響度合はわからないが、webサービス品質が良いものをなるべく上位に食い込ませて、ユーザー体験を向上させようとする狙いがうかがえる。 <a href="https://developers-jp.googleblog.com/2020/05/web-vitals.html" target="_blank" rel="noopener noreferrer">Googleのブログ内容</a>

webサービスというかwebページの品質測定には様々な見方があるし、測定ツールも様々である。
今回はそんな中でLighthouseを紹介したい。

webページの品質を測定

<h4 id="h7b0d1f391a">今年一年の技術スタックを振りかえる</h4> 今年も一年が終わった。 今年はコロナ禍ということもあり、ほぼ一年中どこにも出かけず(ジム行ったり、買い物ぐらいはしたけど)ずっとコードを書いていた。 なので一年を振り返ってもコードぐらいしか記憶がない。 でも今年は個人的には公私に渡って最も多くのプロダクトを作れた年でもあったと思う。 そしてフロントは2020年は激動の一年だった。 具体的にはNext.jsがSSRからSSGに大きくテコを入れたこと、Vue3の登場でこれからのVueのコーディングや設計が大きく変わること、 この二つが個人的に最も大きかったと思う。 人間の目に触れやすいインターフェースに近づくほど技術革新が凄まじいというのを最も実感した。 一方、AWSも今年でAmazon Linuxの基本機能におけるAMIサポート終了という流れもあり、インフラ側も一定の動きがあったようだ。 一部は3年先まで延長っぽい?→ <a href="https://aws.amazon.com/jp/blogs/news/update-on-amazon-linux-ami-end-of-life/" target="_blank" rel="noopener noreferrer">公式ドキュメント</a> 技術革新について行くには手持ちの環境やライブラリ、モジュールを常にアップデートし続けること。 これが技術負債解消にもつながる、と個人的には思っているし、これからもそうしていくだろう。 昔はアップデートは大変だったと思うが、コードに関しては今やdependabotがあったりして一部、あるいは全てを自動化できるようになった。 楽をするために、手間を惜しまないをモットーに来年も疾走する。

今年も一年が終わった。今年はコロナ禍ということもあり、ほぼ一年中どこにも出かけず(ジム行ったり、買い物ぐらいはしたけど)ずっとコードを書いていた。なので一年を振り返ってもコードぐらいしか記憶がない。




Introduction

Oss/GitHub

Articles

フロントエンドのテストの複雑性

ブログ記事に全文検索を追加した

Cypressでお手軽画面テスト

質とスピードという資料を読んで

webページの品質を測定

技術スタックを振りかえる