"単体テストの考え方/使い方"をReactの設計に生かす

"単体テストの考え方/使い方"という書籍の内容を、Reactの設計に活かす場合どのようなアプローチになるかを検討しました。
https://www.amazon.co.jp/%E5%8D%98%E4%BD%93%E3%83%86%E3%82%B9%E3%83%88%E3%81%AE%E8%80%83%E3%81%88%E6%96%B9-%E4%BD%BF%E3%81%84%E6%96%B9-Vladimir-Khorikov/dp/4839981728?tag=googhydr-22&source=dsa&hvcampaign=books&gad_source=1

書籍には次のようなことが説明されており、C#のサンプルコードもあります。
　- 単体テストの目的
　- 優れたテストスイートの条件
　- 単体テストと設計の関係性
　- 単体テストの記述に関するベストプラクティス etc...
書籍はバックエンドメインの説明なので、本スライドではReact（フロントエンド）の場合を検討しています。

Transcript

1. "単体テストの考え方/使い方"を Reactの設計に生かす
2. 自己紹介 • 狩野 駿 • エンジニア歴：8年（ほぼ保守/テスト要員） • フロントエンドエンジニア • 好きな技術：React / TypeScript • 趣味：バレーボール / 観劇
3. 「単体テストの考え方/使い方」 - 須田智之 • 単体テストの目的 • 良い単体テストの定義 • 単体テスト作成の手法 • 単体テストから設計を考慮 • アンチパターン
4. 流れ • 単体テストについて • 単体テストと設計の関係性 • React設計の反映例（サンプルコードあり）
5. 単体テストについて
6. 単体テストとは？ 以下3つの条件を満たしたテスト • 少量のコードを検証すること • 検証時間が短いこと。 • 他のテストケースから隔離された状態で実行されること
7. 単体テストの目的 持続的な成長ができるプロジェクトにするため • バグを検知しやすくなる • 機能追加やリファクタリングが怖くなくなる • サービスの品質が向上する
8. 価値の高い 単体テストが作りやすい プロジェクトが成長しやすい状態
9. 単体テストの作りやすさ • 条件分岐が多い（if文やswitch文） • 依存関係が多い（例:DBなどの外部処理） 単体テストが 作りにくい 成長しにくい設計 （複雑なコード） 密結合になっている
10. 単体テストの作りやすさと設計の関係 分かることは設計が悪い（密結合） かどうかだけ 成長しやすい設計（機能追加しやすい）かまではわからない 単体テストが 作りやすい 成長しやすい設 計
11. 価値の高い単体テストの定義
12. 優れたテストプロセスの条件 1. テストすることが開発サイクルの中に組み込まれている 2. テスト対象が特に重要なプロダクションコードである 3. 最小限の保守コストで最大限の価値を生み出す
13. 価値の高い単体テストとは 重要なプロダクションコード をテスト対象にしている単体テスト ビジネスロジック • 合計金額の計算 • 割引の適用判断 • 在庫の有無確認　など
14. ビジネスロジックに関する 単体テストが書きやすい 成長しやすいプロジェクトは
15. 複雑なコードを改善するためのアプローチ 処理と外部プロセスの中継役 ビジネスロジック以外の処理 複雑な コード ビジネス ロジック アルゴリズム コントローラ
16. React設計への活かし方
17. サンプルReactアプリ例 画面：ユーザ一覧テーブル 振る舞い：表示ユーザをキーワードでフィルタリングする • 全列の内いずれか1つでもキーワードを含んでいれば表示。 ▪ name / email / phone / website • 一致する文字列にハイライトをつける
18. サンプルアプリ例 https://ut-react-sample.web.app/
19. 過剰に複雑なコード（ユーザ一覧のコンポーネント） const BeforeUserTable: FC<Props> = ({ initialUsers }) => { const setHighlight = (val: string) => { return `${val.replace(keyword, `<span style="background:#FFB3BF;">${keyword}</span>`)}`; }; const filteredUsers: User[] = initialUsers.flatMap((x) => { let isHit = false; let name = x.name; let email = x.email; let phone = x.phone; let website = x.website; if (x.name.includes(keyword)) name = setHighlight(x.name); isHit = true; if (x.email.includes(keyword)) email = setHighlight(x.email); isHit = true; if (x.phone.includes(keyword)) phone = setHighlight(x.phone); isHit = true; if (x.website.includes(keyword)) website = setHighlight(x.website); isHit = true; if (!isHit) return []; return { ...x, name, email, phone, website }; }); setUsers(filteredUsers) return(<div>{/* 省略 */}</div>) }; キーワードでフィルタリングを行い、一致 する文字列にハイライトをつける処理 ユーザ一覧用のHTMLを構成し、描画す る処理
20. 現状コード フィルタリング処理 ハイライト処理 描画処理 ユーザ一覧コンポーネント（JSファイル）
21. 現状コードの問題点 （テストパターンの組み合わせが多い） フィルタリング処理 ハイライト処理 描画処理 ユーザ一覧コンポーネント ・・・ 5パターン：各列でヒット/0件ヒット ・・・ 2パターン：ハイライト成功/失敗 ・・・ 2パターン：描画成功/失敗
22. 現状のテストケース（ユーザ一覧のコンポーネント） test("フィルタリング機能テスト _name", async () => { await waitFor(() => { expect(screen.queryByText("ローディング中")).not.toBeInTheDocument(); }); const keywordField = await screen.findByLabelText("検索条件"); await user.type(keywordField, "田中"); const sut = await screen.findAllByText("田中"); const table = await screen.findByRole("table"); await waitFor(() => { // フィルタリングレコードチェック expect(table).toHaveTextContent("田中太郎"); expect(table).toHaveTextContent("田中花子"); // レコード数チェック expect(screen.getAllByRole("row").length - 1).toBe(2); // ハイライトチェック sut.forEach((x) => expect(x).toHaveAttribute("style", "background:#FFB3BF;"), ); }); }); • name列を想定 • 正しくフィルタリングされているか • 正しくハイライトがついているか • 描画されているか
23. 現状コードの改善案 フィルタリング処理 ハイライト処理 描画処理 ユーザ一覧コンポーネント ビジネスロジック アルゴリズム ビジネスロジック
24. リファクタリング（ビジネスロジック切り出し） export class Users { initialUsers: User[]; #setHighlight(val: string, keyword: string) { return `${val.replace(keyword, `<span style="background:#FFB3BF;">${keyword}</span>`)}`; } filterUsers(keyword?: string) { if (!keyword) return this.initialUsers; return this.initialUsers.filter( (x) => x.name.includes(keyword) ||x.email.includes(keyword) || x.phone.includes(keyword) || x.website.includes(keyword), ); } filterUsersWithHighlight(keyword?: string) { return this.filterUsers(keyword).map((x) => ({ ...x, name: this.#setHighlight(x.name, keyword!), email: this.#setHighlight(x.email, keyword!), phone: this.#setHighlight(x.phone, keyword!), website: this.#setHighlight(x.website, keyword!), })); } } • 表示するユーザ情報を保持するクラ ス • キーワード（引数）でフィルタリングし た結果を返すメソッド • フィルタリング結果にハイライトをつ けるメソッド
25. リファクタリング（コンポーネント修正） const AfterUserTable: FC<Props> = ({ initialUsers }) => { useEffect(() => { if (!usersRef.current) return; const filteredUsers = usersRef.current.filterUsersWithHighlight(keyword); setUsers(filteredUsers); }, [keyword]); return(<div>{/* 省略 */}</div>) }; • キーワード渡す • フィルタリングしハイライト済 みのユーザ情報を受け取る。 • 受け取ったユーザ情報を描 画するだけ
26. リファクタリング後のテストケース例（描画機能） test("描画_データあり", async () => { const keywordField = await screen.findByLabelText("検索条件"); await user.type(keywordField, "a"); const rows = screen.getAllByRole("row"); await waitFor(() => { expect(screen.queryByText("田中太郎")).toBeInTheDocument(); expect(screen.queryByText("田中花子")).toBeInTheDocument(); expect(rows.length - 1).toBe(2); }); }); test("描画_データなし", async () => { const keywordField = await screen.findByLabelText("検索条件"); await user.type(keywordField, "a"); const rows = screen.getAllByRole("row"); await waitFor(() => { expect(rows.length - 1).toBe(0); }); }); 受け取った配列データ（ユーザ 一覧データ）を描画してるかだ けを検証できる
27. リファクタリング後のテストケース例（フィルタリング） describe("ドメインロジック", () => { const users = new Users([ { id: 1, name: "田中太郎", email: "tanakataro@april.biz", phone: "123-456-789", website: "taro.org", }, { id: 2, name: "田中花子", email: "tanakahanako@april.biz", phone: "123-456-780", website: "hanako.org", }, ]); test("フィルタリング機能_name列", () => { const sut = users.filterUsers("田中"); expect(sut.length).toBe(2); }); // フィルタリング機能_email列 // etc…. }); フィルタリング機能のテストに注力で きる ドメインロジックの検証にリソースを割 り当てやすくなる。
28. リファクタリング後の想定 • 他の画面でフィルタリング機能を使いまわせる。 • ユーザ一覧に機能追加（予め保存した条件でフィルタリングする など）をしてもテストケースが煩雑になりにくい
29. まとめ 単体テスト作成の視点から 成長しやすい設計を意識する
30. ご清聴ありがとうございました。