Portable stories for Playwright Component Tests
「実装例から見る React のテストの書き方」をアップデートする
社内の人から、自分が以前書いた次の記事が「便利で助かった！書いた時から何かアップデートある？」ってメッセージがきた。 そんな便利だなんてどうもありがとうございますウフフ、と思いながら書いた日を見てみると 2022-08-09 だった。もうすぐ 2 年経とうとしてる。時の流れが早くて怖い。 この記事に書かれた実装例はリポジトリにまとめていたんだけど、当然、何かメンテをしていたわけもなく、2022 年当時の状態がそのまま残っていた。 せっかく便利に思ってくれる人がいたので、内容をアップデートする。 アップデートまとめ メジャーバージョンのリリースやビルドツールの統一の観点で Jest から Vitest に移行 useFakeTimers({ shouldAdvanceTime: true }) @testing-library/reactを v15 にバージョンアップ MSW を v2 にバ
MSW を活用した WebAPI リグレッションテスト
MSW はネットワークレベルでリクエストをインターセプトする、自動テストで便利なモックサーバーです。過去記事でも紹介したとおり、スパイ（モック関数）をネットワークレベルに忍ばせることが可能です。実際に WebAPI が呼ばれた時の Payload の検証は、Jest 組み込みのモック機能では実現できない領域です。本稿は「WebAPI リグレッションテスト」を実施するための、MSW 活用方法を解説します。記事で使用しているサンプルコードはこちら。 課題の概要 Web アプリケーションページのほとんどは「1.UI を表示し／2.入力操作し／3.WebAPI 通信し／4.通信後処理を行う」という一連処理が責務です。このようなページに書かれるテストは、WebAPI 通信前後に集中しがちです。MSW を使用すると、以下の図の様に「送信後処理」まで到達可能なため、例えば「WebAPI レスポンスが返っ
Storybook 単体でインタラクションテストを実施する
Storybook の Component Story Format 3.0 では新機能として play() 関数が追加されました。 play() 関数は Storybook 上でユーザーのクリックやフォーム入力のようなインタラクションな操作を表現できます。 以前は composeStories() 関数により Storybook 上で作成したストーリーを Jest で再利用する方法を書いたのですが、どうやら Storybook のみで完結してテストを実行できるようですのでこちらを試してみます。 Vite プロジェクトの作成 まずは以下コマンドで Vite プロジェクトを作成します。 $ npm init vite@latest my-vue-app -- --template vue-ts $ cd my-vue-app $ npm install Storybook のインストール 続
フロントエンドの"ちょうどいい"自動テストのはじめかた - Atrae Tech Blog
Wevoxのフロントエンドエンジニアをしているタガミです。最近はmonorepo構成に移行中のWevoxフロントエンドのテストやデザインシステムなどをいい感じにしようとしています。 この記事では、WevoxというSaaSプロダクトのフロントエンドにおける自動テストの話をします。Wevoxはリリースから5年以上が経過し、チームのメンバーも増え、またソースコードも巨大化しています。そんな中でフロントエンドも"式年遷宮"をして、改善を繰り返しています。中にはソースコードをガラッと変えるようなリファクタもあり、担当するエンジニアにとってはデグレの心配が付き纏います。そんな日々変化するフロントエンドを支えるのが自動テストです。 Wevoxの開発チームは決して大人数ではありません。そんなチームでも品質の改善のために一歩ずつ改善しつつある経験をもとに、フロントエンドの自動テストポイントをいくつかお伝えし
Storybookを導入する際にやるべきこと3選
Storybookがバージョン7がリリースされたため、加筆、修正しております。 またコードジェネレーターとしてhygenを推奨していましたが、追記当時2023/05時点ではPlopを推奨します。 理由は、PlopはESM対応が自然とできるからです。 はじめに フロントエンドエンジニアとして活動するとおそらく耳にするであろうStorybook。 その有用性が語られることもあれば、時に悪名も耳にすることもあるかと思います。 Takepepeさんが以下のような"あえてStorybookを使わない理由はなんですか"というアンケートを取られておりました。 結果は、「面倒・メンテナンスコストが高い」でした。 実際に私も先輩に、メンテナンスコストが想像より辛く、いいものではなかったと言われたことがありました。 ですが、私は担当したプロジェクトでStorybookの導入に踏み切りました。 それは、これから
storyshotsでのスナップショットテスト - Qiita
現在の画面のスナップショット（キャプチャみたいなもの）を保存しておいて、テストの時にそのスナップショットと今の画面と比較して変更点を出力してくれる。 変更内容を確認して意図せぬ変更に気づくことができる。 正しい変更かそうでないかは自分で確認にすること。 流れ スナップショットは導入した後の初回のテスト時に自動で生成される。 なので初回は比較対象がないので、必ずパスする。 スナップショットが生成した次回以降のテストは比較結果が出る。 変更点が問題なく、新しくスナップショットを取りたいと思ったら、スナップショットのファイルを削除して、再度テストを実施して生成させる。 導入 storybookの導入 スナップショットのテストの方法はいくつかあると思うが、今回はstorybookを利用したテストの方法を記載する。 storybookの初期化を実行する。 下を実行することで、storybookのパッ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
