<h4 id="h1a2bc1336c">個人的な振り返り</h4> 今年も色んなことがあった。 面白いこともあれば、それほど面白くないこともあったけど次に続く道筋はできたと思う。 僕が仕事で費やした時間を見ると、以下に要約される。 1. プロダクトのフロントエンド実装(4割) 2. テストコード作成(3割) 3. タスク管理や割り振り(2割) 4. OSSの更新や調査(1割) 特に2のテストコードは力を入れた。 <a href="https://zenn.dev/k_n/articles/f55d8ad6a843d1" target="_blank" rel="noopener noreferrer">Zennで投稿した記事</a>にある通り、カバレッジ率を0%から最低限の70%まで持ってこれたので結構がんばった方ではないかと思う。 「テストを書く、が当たり前」がもっと世の中に浸透してくれればと思うし、自分自身も積極的に発信できればと考える。 なぜなら再現性のないもの(ここでは画面も見ないとわからない)を確認しないといけない実装は実装ではない、という自負がある。 一方で一つ後悔したことといえば、「アクセシビリティ」の観点で足りない部分が色々あったなぁというところである。 具体的には文字やボタンの色のコントラクト比でもうちょっと深い議論ができれば、とか、エラーの見せ方とか。 来年の課題は「アクセシビリティ」の知識をさらに増やし、実践していくこと。 いっぱい本も読むこと。 それから実は来年から職場が変わる。 今までで一番規模が大きい会社で、社会的インパクトも桁違いに大きいプロダクトの設計をやることになるだろう。 アクセシビリティの考え方も桁違いに求められるけど、それだけ挑戦できるのでそこはプラスに捉えておく。 あと趣味でやってるRustもう少し勉強したいなぁ。。。 <h4 id="h9224cd51c5">周辺界隈振り返り</h4> 今年も数えきれないほど技術の変化があったけど、やはり一番はNext.js 12である。 Next.js 12については<a href="https://nextjs.org/blog/next-12" target="_blank" rel="noopener noreferrer">ここ</a>にあるので読んでほしい。 その中でもEdge Function は一番わくわくする。 リクエストがオリジンに到達する前に関数を実行し、ベーシック認証とかリダイレクトとかを実装できるので、便利そう。(ぶっちゃけ Lambda Edgeでも同じことできるじゃん?とか言わない) 他にはReact 18(React Server Component)を意識したアップデートの内容になっている。 自分はまだReact Server Componentの概念が曖昧なのでもうちょっと勉強してみる予定。 あとはゲームチェンジャーとも言える<a href="https://deno.land" target="_blank" rel="noopener noreferrer">Deno</a>である。 今後どのぐらいNode.jsからDenoへの技術的置き換えが起きるのかわからないけど、このコミュニティの動きは見守りたい。

2021年を振り返る。今年も色んなことがあった。面白いこともあれば、それほど面白くないこともあったけど次に続く道筋はできたと思う。

2021年を振り返る

フロントエンドのテストは見るべき部分が多く、大変だと言われている。 複雑性の本質を見るとフロントエンドのプログラミングがロジックに合わせて画面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>

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

My Blog

2021年を振り返る

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

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

Cypressでお手軽画面テスト

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