Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
フロントエンドテスト導入は 「ストーリー」 を意識しよう
Search
ミカイ
November 07, 2024
0
20
フロントエンドテスト導入は 「ストーリー」 を意識しよう
akihabara.any #2【ノンジャンル技術系LTイベント】
2024/11/7
https://akihabara-any.connpass.com/event/333420/
ミカイ
November 07, 2024
Tweet
Share
More Decks by ミカイ
See All by ミカイ
tsoaはいいぞ!APIドキュメントを自動生成!
junmikai
0
10
生成AI活用はHOWが大事な理由
junmikai
0
98
2025年の抱負: フリーランスから 正社員に戻るので 組織に貢献します!
junmikai
0
53
Chakra UI v3にバージョンアップしてほぼ別物になった件
junmikai
0
220
LTのテーマ決めは「多数派」を意識しよう ~ LT年40回登壇した件~
junmikai
0
3
成長するには「重要 VS 緊急」を意識しよう
junmikai
0
9
LTのテーマ決めは「多数派」を意識しよう ~ LT年40回登壇した件~
junmikai
0
10
目標は「めいそう」が大事。漢字はどう書く?
junmikai
2
20
技術選定で迷ったら『日常』を思い出そう! 〜考え方の新発見〜
junmikai
0
61
Featured
See All Featured
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
30
2.3k
How to train your dragon (web standard)
notwaldorf
91
5.9k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
331
21k
Building Flexible Design Systems
yeseniaperezcruz
328
38k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
118
51k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
32
2.2k
Why You Should Never Use an ORM
jnunemaker
PRO
55
9.3k
Stop Working from a Prison Cell
hatefulcrawdad
268
20k
YesSQL, Process and Tooling at Scale
rocio
172
14k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
40
2k
Measuring & Analyzing Core Web Vitals
bluesmoon
6
320
Transcript
フロントエンドテスト導入は 「ストーリー」 を意識しよう 三海 純(ミカイジュン)
ミカイ ジュン • フリーランスエンジニア • 趣味: もくもく会、アニメ、ネット麻雀(雀魂)
• 好きな有名人 ◦ 後藤 ひとり ◦ 陸八魔アル ◦ 千早 愛音 ◦ 八木 唯
キャリア • 2020年 ~ 2022年 ◦ 正社員: フロントエンドエンジニア
• 2022年 ~ 2023年 ◦ 正社員: フロントエンド&バックエンドエンジニア • 現在(2024年) ◦ フリーランス: Next.js など設計&開発 • 来年(2025年 ~) ◦ 株式会社ゆめみ 正社員として入社予定
こんな話ありませんか? • フロントエンドのテストコード書く時間が あったら追加開発、改善したい • フロントエンドのテストで何を導入していい かわからない
今回は・・・ 難しい話は抜きにして ストーリー形式で 楽しくテストコードの メリットを紹介!
補足 テストを書くことが目標になっている時点で は、おそらく『今』はフロントエンドのテストを 導入するフェーズないと思う
Storybook (UIコンポーネントテスト)
export const Default: Story = { play: async ({ canvasElement,
step }) => { const canvas = within(canvasElement); const checkbox = await canvas.findByRole("checkbox"); await step("checkboxクリックでチェックがつくこと ", async () => { await userEvent.click(checkbox); await expect(checkbox).toHaveAttribute("aria-checked", "true"); }); }, }; こんなテストコード
Storybookでテスト必要なシーン 開発初期で 「このコンポーネントずっと使いそう」 と思った時
テストを書かなかった ストーリーをご覧ください
1ヶ月目:リリース準備 突然、クライアントから「チェックボックスがチェックされて いない時、ちゃんとエラーメッセージが出ない!」との報告 が。 バリデーションが発火しないバグが潜んでいた!焦りなが ら修正に取りかかるも、他のコードをいじったことで予期せ ぬ不具合がどんどん出現
2ヶ月目:追加機能の実装 今度はフォームに複数のチェックボックスを追加すること に。 「同じコンポーネントだから、簡単にいけるでしょ」と思いき や、またもや未チェック時のエラー表示が効かないどこを 直せばいいか全く分からない。
3ヶ月目:保守フェーズ 新たに加わったメンバーが「チェックボックス、どうなってま す?」と質問。 テストがないため仕様確認やバグ再現に手間取る。「あの 時、テストを書いてさえいれば…」と後悔するも、すでに遅 く、毎回リリース前に手動で大量のチェックを繰り返す羽目 に。
こうならないためにも・・・ 長期的なプロダクト開発になるのであればできるだけ早い 段階でStorybookでテストコードを導入しよう! 逆に言えば、すでにプロダクトが出来上がっていて保守運 用しない場合は他のテストの方がいいかも
Playwright
test.describe("UI操作の確認", () => { test("チェックボックスをクリックするとラベルが表示されるか確認 ", async ({ page, })
=> { await page.getByLabel("ラベル1").click(); await page.getByLabel(PREFECTURES.AOMORI).dblclick(); const label = await page.getByLabel("ラベル1"); await expect(label).toBeVisible(); }); }); こんなテストコード
Playwright でテスト必要なシーン 機能が増えて手動テストが多くなり、 開発サイクルに負担が かかり始めたタイミング
テストを書かなかった ストーリーをご覧ください
リリースして半年後 機能が増え、ユーザー認証やフォーム送信、ダッシュボー ドのリアルタイム更新などの複雑な操作が増加。手動テス トはどんどん煩雑になり、作業負荷が急増。「毎回ログイ ンして全機能を手動で確認するのは限界…」という声が漏 れ始める
機能追加リリース直前の大混乱 本番リリースを目前に、手動テストに追われる日々。新し いチェックボックス機能に不具合が発覚し、修正のたびに 他の部分が壊れる状況に。 リリース後、ユーザーから「チェックボックスが動かない」 「ダッシュボードが更新されない」などのクレームが殺到。
こうならないためにも・・・ 長期的なプロダクト開発になるとわかった段階で Playwrightでテストコードを導入しよう! 逆に言えば、1stリリース直後の機能がシンプルな状態の 時は他のテストの方がいいかも
いつ書くか? • Storybook ◦ コンポーネントの設計時にテストを書き始める のが理想 • Playwight
◦ 機能が安定し、複雑なフローが増えてきたタ イミング
具体例 • Storybook ◦ 初期のUI設計段階で、コンポーネントがデザインや要件に 合っているかを確認したい時 • Playwight
◦ 手動テストの負担が増えた時。UIの操作フローが複雑化して きた段階で、自動テストに移行することで開発効率を維持し たい時
結論 プロダクトの「課題」が生まれた時に フロントエンドのテストコードが 必要かもしれない
ご清聴ありがとうござ います!