このブログのCSSライブラリをVanillaExtractからLinariaに置き換えました。
Linariaに置き換えるにあたり全体のCSSを移行する必要がありデザイン崩れが心配だったので、Playwrightでビジュアルリグレッションテストを実施してデザイン崩れがないことを自動テストしました。
Playwrightの導入とLinariaへの移行は次のPRで確認できます。
<ul>
<li><a href="https://github.com/t-yng/blog/pull/543" target="_blank">Playwrightでのビジュアルリグレッションテストを導入 #543</a></li>
<li><a href="https://github.com/t-yng/blog/pull/544" target="_blank">vanilla-extractをlinariaに移行 #544</a></li>
</ul>
<h2 id="Playwrightのインストールと環境構築">Playwrightのインストールと環境構築</h2>
パッケージ単体としてインストールもできますが<code>create</code>コマンドを利用すれば、設定ファイルの自動生成など環境構築を自動で行ってくれます。
<pre class="language-sh"><code class="language-sh">$ yarn create playwright
</code></pre>
<h2 id="設定ファイルの修正">設定ファイルの修正</h2>
自動生成された設定ファイルを自分の好みに合わせて修正します。
<ul>
<li>VRTのスクリーンショットを管理しやすくするためにファイルパスを設定</li>
<li>テスト対象の端末を設定
<ul>
<li>Desktop ChromeとMobile Safari iPhoneSE の2つを対象とする</li>
</ul>
</li>
<li>webServerでテスト実行前にローカルサーバーを起動する設定を追加</li>
</ul>
<pre class="language-ts"><code class="language-ts">// playwright.config.ts
import { defineConfig, devices } from '@playwright/test';

/**
 * See https://playwright.dev/docs/test-configuration.
 */
export default defineConfig({
 testDir: './e2e',
 // スナップショットのファイルパスを設定
 snapshotPathTemplate:
 '{testDir}/__snapshots__/{testFilePath}/{projectName}{ext}',
 /* Run tests in files in parallel */
 fullyParallel: true,
 /* Reporter to use. See https://playwright.dev/docs/test-reporters */
 reporter: 'html',
 /* Shared settings for all the projects below. See https://playwright.dev/docs/api/class-testoptions. */
 use: {
 /* Base URL to use in actions like `await page.goto('/')`. */
 baseURL: 'http://127.0.0.1:3000',

 /* Collect trace when retrying the failed test. See https://playwright.dev/docs/trace-viewer */
 trace: 'on-first-retry',
 },

 // テスト対象のブラウザを設定
 projects: [
 {
 name: 'Desktop Chrome',
 use: { ...devices['Desktop Chrome'] },
 },
 {
 name: 'Mobile Safari iPhoneSE',
 use: { ...devices['iPhone SE'] },
 },
 ],

 /* Run your local dev server before starting the tests */
 webServer: {
 command: 'yarn dev',
 url: 'http://127.0.0.1:3000',
 reuseExistingServer: !process.env.CI,
 },
});
</code></pre>
<h2 id="ビジュアルリグレッションテストの作成">ビジュアルリグレッションテストの作成</h2>
Playwrightでは内部的に画像差分比較の仕組みが導入されているので、ページを表示して<code>toHaveScreenshot</code>を実行するだけでビジュアルリグレッションテストを実現できます。
ページごとにテストファイルを作成していビジュアルリグレッションテストだけを実行するテストケースを実装していきます。
<pre class="language-ts"><code class="language-ts">// e2e/top.spec.ts
import { test, expect } from '@playwright/test';

test('visual regression', async ({ page }) => {
 await page.goto('/');
 await expect(page).toHaveScreenshot({
 fullPage: true,
 animations: 'disabled',
 });
});
</code></pre>
<pre class="language-ts"><code class="language-ts">// e2e/post.spec.ts
import { test, expect } from '@playwright/test';

test('visual regression', async ({ page }) => {
 await page.goto('/post/improve-a11y');
 await expect(page).toHaveScreenshot({
 fullPage: true,
 animations: 'disabled',
 });
});
</code></pre>
<h2 id="スクリーンショットの作成">スクリーンショットの作成</h2>
初回実行時は差分となるスクリーンショットが存在しない状態なので、まずはベースとなるスクリーンショットを作成します。
<pre class="language-sh"><code class="language-sh"># 最初にスクリーンショットを作成
$ yarn playwright test --update-snapshots
</code></pre>
<h2 id="テストを実行">テストを実行</h2>
ビジュアルリグレッションの準備ができたので、実際にテストを実行してみます。
<pre class="language-sh"><code class="language-sh"># テスト実行
$ yarn playwright test

 4 failed
 [chromium] › post.spec.ts:3:5 › visual regression ──────────────────────────────────
 # 省略
</code></pre>
テストを実行したら画像の差分が発生して、テストに失敗しました。
<img src="/images/posts/playwright-vrt/failed.png" alt="ビジュアルリグレッションテストの結果" loading="lazy" width="2116" height="816">
コードを確認してみるとLinariaに移行するためにCSSの記述をJS ObjectからCSSスタイルに書き換えるにあたり、フォント指定の値が誤って文字列のままとなっていました。
ビジュアルリグレッションテストをしていなかったら、気づかずにそのままになっていました。
<pre class="language-css"><code class="language-css">/* 文字列で囲っているのでCSSの構文として正しくない */
font-family: "'Helvetica Neue', Arial, 'Hiragino Kaku Gothic ProN', 'Hiragino Sans', Meiryo, sans-serif";

/* 正しくはこう */
font-family: 'Helvetica Neue', Arial, 'Hiragino Kaku Gothic ProN', 'Hiragino Sans', Meiryo, sans-serif;
</code></pre>
<h2 id="まとめ">まとめ</h2>
ビジュアルリグレッションテストを導入することで、マージ前に事前にバグに気づけて非常に良かったです。 
プライベートで個人開発をしていると第3者のコードレビューは基本無いので、自動テストで可能な限りバグを出さない仕組みを自動化するのはとても有益だなーと改めて実感しました。😊

今回は自分のプルリクエストを自分でレビューをするメリットについて話をしたいと思います。

Playwrightでビジュアルリグレッションテストを導入して安全にCSSライブラリを置き換える

<h2 id="Google検索で見つかるサンプル実装の課題">Google検索で見つかるサンプル実装の課題</h2>
Checkboxのデザインをカスタマイズするには、従来のCheckboxでは難しく自前でCheckboxを実装する必要があります。Googleで「チェックボックス デザイン 変更」と検索して上位に出てくる記事を見ると次のサンプルのように<code>input[type=&quot;checkbox&quot;]</code>を<code>display:none</code>で非表示にしている実装が多くあります。
この実装では<code>&lt;input&gt;</code>要素にフォーカルを当てることができないため、Tabキーで選択してスペースでトグルするようなキーボード操作ができない状態になっています。 
また、スクリーンリーダーがチェックボックスを認識できないので、スクリーンリーダーユーザーはチェックボックスの存在に気づくことすらできません。
<iframe src="https://stackblitz.com/edit/react-ts-2tdsqo?embed=1&file=src/BadCheckbox/style.css&initialpath=?bad" style="width: 100%; height: 400px;"></iframe>
<h2 id="アクセシビリティを考慮してチェックボックスを実装">アクセシビリティを考慮してチェックボックスを実装</h2>
<code>display:none</code>だとフォーカスができなくなってしまうので、代わりに<code>opacity:0;</code>で<code>&lt;input&gt;</code>を非表示にします。 
<code>&lt;input&gt;</code>は非表示のままのため、フォーカスが当たっている時のデザインを追加します。
この考慮を入れて上げるだけで、キーボード操作可能になり操作性が上がりスクリーンリーダーユーザーもチェックボックスの操作が可能になります。
<pre class="language-css"><code class="language-css">/* src/GoodCheckbox/style.css */

/* 元のチェックボックス（非表示） */
input[type='checkbox'] {
 opacity: 0;
 position: absolute;
}

/* フォーカスが当たっている時のデザインを追加 */
input[type='checkbox']:focus-visible + label::before {
 border-color: blue;
}
</code></pre>
<iframe src="https://stackblitz.com/edit/react-ts-2tdsqo?embed=1&file=src/GoodCheckbox/style.css" style="width: 100%; height: 400px;"></iframe>
<h2 id="デザイン実装をリファクタする（おまけ）">デザイン実装をリファクタする（おまけ）</h2>
ここから先は好みの問題かもですが、CSSを利用したサンプル実装は疑似要素を使った実装になっており直感できないため、少し保守がしづらく感じます。疑似要素を使わずに直感的にデザイン指定できるようにリファクタをしてみます。
疑似要素を使わずにカスタムなチェックボックスを<code>&lt;span&gt;</code>タグで実装してCSSでデザインを指定することで、宣言的になり直感的に分かりやすくなりました。
チェックアイコンを<code>&lt;svg&gt;</code>タグで直接表示するように変更しています。この時の注意点としてチェックアイコンの画像は視覚的な情報なのでスクリーンリーダーユーザーにとっては唯のノイズになってしまいます。実際に<code>aria-hidden</code>を消してスクリーンリーダーに読み上げさせると、チェック済みの場合に「イメージ」という無駄な読み上げが発生します。そのため、忘れないように<code>&lt;svg aria-hidden=&quot;true&quot;&gt;</code>と設定してあげる必要があります。<code>@mui/icons-material</code>ではデフォルトで<code>aria-hidden=&quot;true&quot;</code>となるので別途指定はしていません。
<iframe src="https://stackblitz.com/edit/react-ts-2tdsqo?embed=1&file=src/Checkbox/Checkbox.tsx&initialpath=?refactor" style="width: 100%; height: 400px;"></iframe>
<pre class="language-tsx"><code class="language-tsx">// src/Checkbox/Checkbox.tsx

import * as React from 'react';
import CheckRoundedIcon from '@mui/icons-material/CheckRounded';
import './style.css';

type CheckboxProps = {
 checked: boolean;
 onChange: (event: React.ChangeEvent&lt;HTMLInputElement>) => void;
};

export const Checkbox: React.FC&lt;CheckboxProps> = ({ checked, onChange }) => {
 return (
 &lt;label className="checkbox">
 &lt;input type="checkbox" defaultChecked={checked} onChange={onChange} />
 &lt;span className="custom-checkbox">
 {checked &amp;&amp; &lt;CheckRoundedIcon fontSize="small" />}
 &lt;/span>
 &lt;span>ラベル&lt;/span>
 &lt;/label>
 );
};
</code></pre>
<pre class="language-css"><code class="language-css">/* src/Checkbox/Checkbox.tsx */

.checkbox {
 display: inline-flex;
 cursor: pointer;
 gap: 8px;
}

.checkbox input[type='checkbox'] {
 opacity: 0;
 position: absolute;
}

.checkbox .custom-checkbox {
 display: inline-block;
 width: 24px;
 height: 24px;
 border: 2px solid lightgray;
 border-radius: 4px;
 background-color: white;
 box-sizing: border-box;
}

.checkbox input[type='checkbox']:checked + .custom-checkbox {
 background-color: lightcoral;
}

.checkbox input[type='checkbox']:focus + .custom-checkbox {
 border-color: blue;
}
</code></pre>

アクセシビリティを考慮したカスタムなCheckboxを実装する方法です。

アクセシビリティを考慮してチェックボックスのデザインを変更する

mswをラップして便利なutil関数を実装します。

mswをラップした便利関数をつくる

この記事は <a href="https://qiita.com/advent-calendar/2022/yamap-engineers" target="_blank">YAMAP エンジニア Advent Calendar 2022</a> 7日目の記事です。
<h2 id="mswとは？">mswとは？</h2>
ネットワークレベルでAPIリクエストをモックできるAPIモックライブラリです。 
<a href="https://mswjs.io/" target="_blank">MSW – Seamless API mocking library for browser and Node | Mock Service Worker</a>
<h2 id="Node.js18とグローバルfetch()">Node.js18とグローバルfetch()</h2>
今までは<code>fetch()</code>を利用したフロントエンドのコードをNode.js環境でユニットテストを実行するには、グローバルスコープに<code>fetch()</code>が存在しないので、モックをしたりテスト実行時に<a href="https://github.com/node-fetch/node-fetch" target="_blank">node-fetch</a>をPolyfillとして適用してグローバルスコープに<code>fetch()</code>を生やすなどの対応をしていました。
Node.js18から新たにグローバルスコープのfetch APIがデフォルトで利用可能になり、モック対応をせずともテスト実行時に<code>fetch()</code>が利用できる状態になりました。
<h2 id="Node.js18環境でmswが動かない">Node.js18環境でmswが動かない</h2>
グローバルスコープでfetch APIが利用可能になったので、何の対応もせずそのままmswでテストを実行できると思い次のサンプルコードを実行したら、mswがAPIリクエストをインターセプトしてくれずリクエスエラーが発生して盛大にハマりました。 
<code>Caused by: Error: connect ECONNREFUSED ::1:3000</code>
当たり前に使えると思っていたので、無駄に時間を溶かしました。
<pre class="language-ts"><code class="language-ts">// User.tsx
export const User = () => {
 const [user, setUser] = useState&lt;User | null>(null);

 useEffect(() => {
 fetch("/user").then(async (res) => {
 const user = await res.json();
 setUser(user);
 });
 }, []);

 if (user == null) {
 return null;
 }

 return &lt;span>{user.name}&lt;/span>;
};

// User.test.tsx
import { rest } from "msw";
import { render, screen, waitFor } from "@testing-library/react";
import { server } from "../../test/server";

describe("User", () => {
 it("show user name", async () => {
 server.use(
 rest.get("/user", (_req, res, ctx) => {
 return res(ctx.json({ name: "taro" }));
 })
 );

 render(&lt;User />);
 await waitFor(() => expect(screen.getByText("taro")).toBeInTheDocument());
 });
});
</code></pre>
<h2 id="mswのインターセプターと対象モジュール">mswのインターセプターと対象モジュール</h2>
<a href="https://github.com/mswjs/interceptors" target="_blank">mswのインターセプター</a>は
<ul>
<li><code>http.get</code>/<code>http.request</code></li>
<li><code>https.get</code>/<code>https.request</code></li>
<li><code>XMLHttpRequest</code></li>
<li><code>window.fetch</code></li>
<li>その他のAPIクライアント(i.e. axios, request, node-fetch, supertest, etc.)</li>
</ul>
により発行されたリクエストを割り込み対象としてサポートしています。
Node.jsのfetch APIは標準の<code>http</code>モジュールを利用しておらず、<a href="https://github.com/nodejs/undici" target="_blank">undici</a>という別のモジュールによって実装されています。そのため、標準のfetch APIで発生したリクエストはmswのインターセプターの対象とならず今回のエラーが発生していました。
参考: <a href="https://shisama.hatenablog.com/entry/2022/04/20/011103" target="_blank">Node.js v18 の主な変更点</a>
<h2 id="node-fetchでfetch()を置き換える">node-fetchでfetch()を置き換える</h2>
現時点でmswを利用するには今まで通り<code>fetch()</code>をnode-fetchで置き換えてあげる必要があります。
<pre class="language-ts"><code class="language-ts">// test/setup.ts
import _fetch from "node-fetch";
import { server } from "./server";

// グローバルスコープのfetch()をnode-fetchで置き換える
// @ts-ignore
global.fetch = _fetch;

beforeAll(() => server.listen());
afterEach(() => server.resetHandlers());
afterAll(() => server.close());

// jest.config.js
module.exports = {
 setupFilesAfterEnv: ['./test/setup.ts'], 
}
</code></pre>
<h2 id="mswのFetch APIへの対応">mswのFetch APIへの対応</h2>
調べてみたら<a href="https://github.com/mswjs/interceptors/pull/283" target="_blank">標準のfetch APIに対応するPR</a>が既に作成されていたので、近い将来にはモック対応をせずにそのままmswが使えるかもです。

Node.js18の環境でmswを使った時にネットワークをインターセプトできない問題にハマった話です

Node.js18の環境でmswを使ったらハマった話

この記事は <a href="https://qiita.com/advent-calendar/2021/yamap-engginers" target="_blank">YAMAP エンジニア Advent Calendar 2021</a> の21日目の記事です。
<h2 id="ts-jestの課題感">ts-jestの課題感</h2>
ts-jestを使っているとコンパイル時間の問題で地味にテストに実行がかかります。
YAMAPではフロントエンドでもユニットテストを書き始めたので、約180ケースで1分ほどCIでテスト実行に時間がかかるようになりました。 
またTDDで開発を進めていると、開発中に非常に多くユニットテストを実行するので ts-jest の実行時間の遅さが開発効率に直結してきます。
そこで、ts-jest を @swc/jest に置き換えて、実行時間の改善を試みました。
<h2 id="導入効果">導入効果</h2>
@swc/jest に置き換えた結果、CIでのユニットテストの実行時間が1/2に短縮されました🎉
<table>
<thead>
<tr>
<th>変更前</th>
<th>変更後</th>
</tr>
</thead>
<tbody>
<tr>
<td>53s</td>
<td>21s</td>
</tr>
</tbody>
</table>
<h2 id="@swc/jest とは">@swc/jest とは</h2>
@sec/jest は Rust製の TypeScriptコンパイラーの swc を利用して作られた Jest の Transformer です。 
個人的に感じる @swc/jest のメリットは次の点です。
<ul>
<li>swc が Rust製のため ts-jest(tsc) と比較して、高速に動作する</li>
<li>設定を <code>jest.config.js</code> 内に書くことができるので、<code>tsconfig.test.json</code> のようにテスト用の tsconfig ファイルを持つ必要がない</li>
</ul>
<h2 id="ts-jest を @swc/jest に置き換える">ts-jest を @swc/jest に置き換える</h2>
まずはコンパイラー本体の<code>@swc/core</code>と Transformer の<code>@swc/jest</code>をインストールします。
<pre class="language-shell"><code class="language-shell">$ yarn install -D @swc/core @swc/jest
</code></pre>
変更前のJestの設定ファイルはこんな感じです。
<pre class="language-js"><code class="language-js">/** @type {import('@jest/types').Config.InitialOptions} */
module.exports = {
 preset: 'ts-jest/presets/js-with-babel',
 testEnvironment: 'jsdom',
 (省略),
 globals: {
 'ts-jest': {
 tsconfig: '&lt;rootDir>/tsconfig.test.json',
 },
 },
};
</code></pre>
これを @swc/jest を使うように変更します。 
設定ファイル内に swc の設定を追加して <code>transform</code> を @swc/jest を使うように修正しています。 
また、tsconfigは不要になったので <code>globals</code> の設定ごと削除しています。
swc の設定項目についてはコメントに記載してあります。詳細は<a href="https://swc.rs/docs/configuration/compilation" target="_blank">公式ドキュメント</a>を参照ください。
<pre class="language-js"><code class="language-js">/** @type {import('@swc/core').Config} */
const swcConfig = {
 // ソースマップの出力を有効にする
 sourceMaps: true,
 module: {
 // JestがCommonJSでモジュールを読み込むのでCommonJS形式で出力する
 type: 'commonjs',
 },
 jsc: {
 parser: {
 // TypeScriptとしてコンパイルする
 syntax: 'typescript',
 // Reactのコンポーネントをテストしたいのでtsxのコンパイルを有効化
 tsx: true,
 },
 transform: {
 react: {
 // React の JSX トランスフォームの指定
 // Reactインポートの手間を省略するために React17 から導入された 
 // _jsx(react/jsx-runtime) の形式にコンパイルする
 runtime: 'automatic',
 },
 },
 },
};

/** @type {import('@jest/types').Config.InitialOptions} */
module.exports = {
 transform: {
 '^.+\\.(t|j)sx?$': ['@swc/jest', swcConfig],
 },
 (省略),
};
</code></pre>
<h2 id="コンパイラーが異なることによる懸念">コンパイラーが異なることによる懸念</h2>
babelで設定を書いている影響でプロダクションのコンパイルは引き続き tsc を使用しており、テストとプロダクションの実行環境でコンパイラーが異なる状況になってしまっています。コンパイラー依存の問題でテストでは正常に動くみたいな事が起こる可能性はあるかもとという懸念は少し持っています。
ただ、それによるバグが起こる可能性はかなり低くテスト実行の速度向上による開発効率化の方がメリットが大きいと判断しているので、そこは許容範囲かなと考えています。
<h2 id="さいごに">さいごに</h2>
思ったよりもスムーズに導入ができて特に問題が発生することもなく、今までと変わらずにテスト実行が使い続けれているので、導入して良かったです。

この記事は YAMAP エンジニア Advent Calendar 2021 の21日目の記事です。ts-jestを使っているとコンパイル時間の問題で地味にテストに実行がかかります。YAMAPではフロントエンドでもユニットテストを書き始めたので、約180ケースで1分ほどCIでテスト実行に時間がかかるようになりました。またTDDで開発を進めていると、開発中に非常に多くユニットテストを実行するので ts-jest の実行時間の遅さが、開発効率に直結してきます。そこで、ts-jest を @swc/jest に置き換えて、実行時間の改善を試みました。

実務でts-jestを@swc/jestに置き換えてCIの実行時間を1/2に短縮した

この記事は <a href="https://qiita.com/advent-calendar/2021/yamap-engginers" target="_blank">YAMAP エンジニア Advent Calendar 2021</a> の22日目の記事です。
<h2 id="はじめに">はじめに</h2>
現在、輪読会で <a href="https://www.amazon.co.jp/dp/B077D2L69C/ref=dp-kindle-redirect?_encoding=UTF8&amp;btkr=1" target="_blank">テスト駆動開発</a>（TDD）を読み進めています。 
本を読んで色々と知識が入ってきているので、業務でアウトプットしてみたいなと思い、バグ修正からTDDを初めてみたら良かったので紹介します。
<h2 id="なぜバグ修正から始めるのか？">なぜバグ修正から始めるのか？</h2>
TDDをする上で一番難しいなと感じるのが、実装前に何のテストを書けば良いか分からないという部分です。 
今までテストを書いた経験が少ないと、対象となるコードが無い状態からテストを書き始めるのはイメージがしづらく中々テストを書くことができません。
その点、バグ修正の場合は既にコードが存在しており、バグを再現するテストを書けば良く何をテストするかも明確になっているので、非常にテストコードが書きやすいという利点があります。
そのため、バグ修正は比較的スムーズにTDDのフローを回しやすく手軽にTDDを体験することができます。
<h2 id="TDDでバグ修正に挑戦する">TDDでバグ修正に挑戦する</h2>
<h3 id="概要">概要</h3>
ユーザーのアバター画像とユーザー名を表示する <code>UserBio</code> コンポーネントについて考えてみます。
このコンポーネントはアバター画像について考慮が漏れておりリンク切れのバグが発生する可能性があります。
<ul>
<li>バグ: アバター画像が未設定の場合にリンク切れで画像が表示される</li>
<li>期待する動作: アバター画像が未設定の場合はサムネイル画像を表示する</li>
</ul>
<pre class="language-tsx"><code class="language-tsx">// src/components/UserBio.tsx
import { FC } from 'react';

type Props = {
 user: {
 name: string;
 avatar?: string;
 }
}

export const UserBio: FC&lt;Props> = ({ user }) => {
 return (
 &lt;div>
 &lt;img src={user.avatar} />
 &lt;span>{user.name}&lt;/span>
 &lt;/div>
 )
}
</code></pre>
<h3 id="バグを再現するテストコードを書く">バグを再現するテストコードを書く</h3>
コードのバグを修正したい気持ちをぐっ！と抑えて、先にテストコードを書いていきます。
どんなテストコードを書けば良いでしょうか？ 
今回の目的はバグ修正のためバグを再現するテストコードを書けば良いので、何をテストするかは非常に明確です。
本来であれば、テストが全く書かれいない場合はアバター画像を表示するテストも先に書いておいた方が良いですが説明の都合で割愛しています。
<pre class="language-typescript"><code class="language-typescript">// src/components/UserBio.spec.tsx
import "@testing-library/jest-dom";
import { render, screen } from "@testing-library/react";
import { UserBio } from "./UserBio";

describe("UserBio", () => {
 it("アバター画像が未設定のときにサムネイル画像を表示する", () => {
 render(&lt;UserBio user={{ name: "テスト太郎" }} />);

 const expected = "https://example.com/images/avatar";
 expect(screen.getByRole("img")).toHaveAttribute("src", expected);
 });
});
</code></pre>
テストを実行してみます。 
正常にテストが失敗してくれたので、これでバグを再現するテストコードが実装できました。
<pre class="language-shell"><code class="language-shell">$ yarn jest src/components/UserBio.spec.tsx

 FAIL src/components/UserBio.spec.tsx
 UserBio
 ✕ アバター画像が未設定のときにサムネイル画像を表示する (85 ms)

 ● UserBio › アバター画像が未設定のときにサムネイル画像を表示する

 expect(element).toHaveAttribute("src", "https://example.com/images/avatar") // element.getAttribute("src") === "https://example.com/images/avatar"

 Expected the element to have attribute:
 src="https://example.com/images/avatar"
 Received:
 null
</code></pre>
<h3 id="バグ修正対応">バグ修正対応</h3>
バグを再現するテストができたので、後は楽しくバグ修正のコードを書くだけです。
<pre class="language-tsx"><code class="language-tsx">const AVATAR_THUMBNAIL = 'https://example.com/images/avatar';

export const UserBio: FC&lt;Props> = ({ user }) => {
 return (
 &lt;div>
 &lt;img src={user.avatar ?? AVATAR_THUMBNAIL} />
 &lt;span>{user.name}&lt;/span>
 &lt;/div>
 );
}
</code></pre>
バグ修正ができたので、改めてテストを実行してみます。 
無事にテストが通りバグが修正されたのを確認できました！ ⸜(｡˃ ᵕ ˂ )⸝
<pre class="language-shell"><code class="language-shell">$ yarn jest src/components/UserBio.spec.tsx

 PASS src/components/UserBio.spec.tsx
 UserBio
 ✓ アバター画像が未設定のときにサムネイル画像を表示する (61 ms)
</code></pre>
<h3 id="ブラウザ不要の検証">ブラウザ不要の検証</h3>
今回のバグ修正ではコードを変更してバグが修正されたことを確認する過程全くブラウザを利用しませんでした。 
PR作成前に念の為のブラウザ確認はしますが、検証でブラウザ操作をするのはその1度だけに抑えることができます。
フロントエンドをTDDで開発するメリットの一つとしてこの検証の簡略化があります。 
フロントエンドで検証を進めるために何度もコードとブラウザを行き来してブラウザ操作をする事が多いですが、この実装途中におけるブラウザ操作が地味に面倒で開発コストとして発生します。
TDDでテストを先に書いて検証を自動化することで、この検証コストを減らして開発効率を上げられるメリットがあります。
<h2 id="さいごに">さいごに</h2>
今回は非常に簡単なバグ修正を例にフロントエンドでのTDDについて紹介しました。
TDDやテストを書くには、どんな簡単なモノでも良いのでたくさんテストを書いて経験を得ることが何より大事だと思います。
TDDで開発をしてみたいけどなかなか初めの一歩が踏み出せない場合は、今回のケースのようなすごく簡単な修正からテストを書き始めてみましょう。

この記事は YAMAP エンジニア Advent Calendar 2021 の22日目の記事です。現在、輪読会で「テスト駆動開発」（TDD）を読み進めています。本を読んで色々と知識が入ってきているので、業務でアウトプットしてみたいなと思い、バグ修正からTDDを初めてみたら良かったので紹介します。

バグ修正から始めるフロントエンドのTDD入門

初めてフロントエンドでコンポーネントのユニットテストを書く時に「何をテストするのか」が分からず、上手くテストが書けないという事があります。この記事ではコンポーネントの入力と出力を意識することでユニットテストで「何をテストするか」について、まとめています。

コンポーネントの入力と出力を意識してユニットテストを書いてみよう

この記事はタイムリープTypeScript 〜TypeScript始めたてのあの頃に知っておきたかったこと〜の5日目の記事です。自分がTypeScriptを書き始めた頃に苦労したのが、Jestでテストを書くときのモックの型をどう書けば良いか分からないことでした。

TypeScript+Jestでテストを書くときに型安全にモックする方法を教えてほしかった

とあるフロントエンドエンジニアのブログ

テストの記事一覧