テストの学習へようこそ！ コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 このコースでは、ウェブ用のテストの概要と探索について説明します。 このコースで学習する内容は次のとおりです。 テストの基礎 自動テストと手動テスト テストを実施する場所と方法 ベスト プラクティス 何をテストすべきか、誰に責任があるのか、目的そのものとしてではなく、目的を達成するために手段をテストすることを検討する方法など、テストの理念。 このコースには、学習に役立つ簡潔で実用的なサンプルコードも含まれています。 コースのスコープには、Node.js などの環境で実行される、フロントエンドの JavaScript とドキュメント モデル、バックエンドでのライブラリ テストが含まれます。テストの経験はありませんが、JavaScript の基礎知識と Node.js などに関する経験が必
(社内用ドキュメントの公開版) テストのポリシー 前提として、ユニットテストを導入するコストを、限界まで低くすることを目指す。テストが根付いていない言語環境や文化では、放っておくとテストが書かれないまま実装が進行し、結果としてテスト不可能な巨大な雪だるまが完成する。こうなるとメンテコストが高いE2Eを大量に書かないといけなくなり、テストの実行時間が膨れ上がっていく。 そうなる前に、ユニットテストを書きやすい環境を維持し、ユニットテストとして問題を切り分けられるような環境を維持する。とにかく書きやすさを重視し、一つのユニットテストを書くオーバーヘッドを限界まで下げる。 最初の一つを早い段階で書く 自分の経験的には、ユニットとテストの最初の一つを書いたらあとは自然とその周辺で増えていく。サンプルがあったら人はコピペする。逆にいうと最初の一つを書かない限り一切書かれない。まず一つ用意するのが大事
本稿における「単体テスト」とは自動テストにおける単体テストを指します。手動テストのことではないので、ご了承ください。 単体テストの考え方/使い方という本を読みました。筆者自身、「単体テストはプロダクションコードの付属」という意識がどこかにありました。この本を読んで、単体テストについてあまりに何もわかってなかったことに気付かされ、単体テストの設計はプロダクションコードの設計と同じくらい重要という意識に変わりました。何のために単体テストをやるのか、いいテストとは、「単体」とは、など多くの点で学びを得られ、また、多くのプラクティスとアンチパターンを知ることができました。 本稿はこの本を読んで得られた学びを、フロントエンド開発、特にコンポーネント開発に適用することを試みた際のまとめです。より詳細な解説を求む方には本を手に取ってもらう前提で、できるだけポイントを抑えられるようにまとめることを目指しま
こんにちは、テストが好きなsilverbirderと申します。Webフロントエンドのテストは実施していますか？ユニットテストやビジュアルリグレッションテストは広く知られていると思います。しかし、パフォーマンステストのためのテストコードはありますか？また、カオスエンジニアリングテストやアクセシビリティテストはありますか？ 今回、私はWebフロントエンドにおける網羅的なテストパターンを調査し、その結果をここで紹介したいと思います。これらを理解することで、読者の皆さんが適切なテスト戦略を策定する際の参考になれば幸いです。 前提 今回、テスト対象として取り上げる題材は、TodoMVCというTODOアプリです。フレームワークとしてReactを使用しますが、紹介するテストパターンはフレームワークに依存しないものです。ただし、使用するライブラリはReactに関連しているため、その点についてはご了承くださ
Findy Team+でフロントエンドエンジニアをしている 川村(@peijun333)です。 Findy では、フロントエンドのコード品質と安定性を確保するために Jest などのテストフレームワークを積極的に活用しています。通常、Jest は CLI から実行してテスト結果をコンソールで確認しますが、コマンドを用意する手間や、テスト経過のデバッグのために都度 console.log などでその内容を確認しなければならずとても不便です。 そこで、今回はテストの自動化とリアルタイムなフィードバックを提供する JavaScript の統合テストツールである Wallaby.js を紹介します。Wallaby.js を導入することで、開発効率の向上が期待できます。 Wallaby.js とは？ 前提条件 VS Code でテストの修正 Wallaby.js はリファクタリングに強い スナップシ
こんにちは フロントエンドエンジニアの どじねこ です。 今回は Storybook 8.3 から追加された Vitest 統合機能を活用して、フロントエンドアプリの自動テストを強化した事例をご紹介します。 Storybook とは storybook.js.org Storybook は OSS として開発される UI コンポーネントワークショップです。 具体的には、フロントエンドアプリケーションの UI コンポーネントを開発する際の作業環境、ドキュメンテーションツール、テスティングフレームワークとして活用できる開発環境が提供されます。 React や Vue、Angular、Svelte、Web Component など幅広い環境に対応しており、うまく活用するとフロントエンドアプリケーションの開発をより柔軟に行えるようになります。 Storybook と Vitest の統合機能とは
はじめに こんにちは、CX事業本部MAD事業部の森茂です。 今回まだ開発版ではありますが、昨年末に公開されたVue.jsやViteの作者Anthony Fu氏@antfu7、Patak氏@patak_devが開発しているJestに代わるあたらしい高速テストフレームワークVitestをReactで試してみました。 VitestはVite環境で動作する高速なテストフレームワークで、VueやReact、Svelte、litなどなどさまざまなフレームワークで動作します。ChaiやJestのアサーション、スナップショットが互換的に動作するので既存のテストコードをほぼ同じ書き方で利用することができます。またc8を利用したcoverageの作成にも対応しています。 Jestでは環境の構築にそれなりの手間がかかりますが、Vitestはライブラリのインストールと簡単な設定を追記するだけで利用することが可能で
はじめにlink 最近DBありのテストを記述していた際に、実はvitestではbeforeEachは必要ないのではないか、という考えに至ったのでその理由と設計についてまとめてみる。 下記のリポジトリで実験する https://github.com/koh110/vitest-beforeeach テストでbeforeEachが欲しくなるシーンlink テストを記述する際にbeforeEachが欲しくなるシーンは主に以下の2点ではないかと考えている。 mockの設定/reset seedsの投入 このうち、前者mockの設定/resetはbeforeEachではなくbeforeAll or すべての個別テストごとに設定すべきなのではと考えている。 これは自分がテスト単体での移植性を重視している（テスト単体をコピペしてもなるべくそのまま動かせる）ので、beforeEachでやってしまうとあるテ
社内の人から、自分が以前書いた次の記事が「便利で助かった！書いた時から何かアップデートある？」ってメッセージがきた。 そんな便利だなんてどうもありがとうございますウフフ、と思いながら書いた日を見てみると 2022-08-09 だった。もうすぐ 2 年経とうとしてる。時の流れが早くて怖い。 この記事に書かれた実装例はリポジトリにまとめていたんだけど、当然、何かメンテをしていたわけもなく、2022 年当時の状態がそのまま残っていた。 せっかく便利に思ってくれる人がいたので、内容をアップデートする。 アップデートまとめ メジャーバージョンのリリースやビルドツールの統一の観点で Jest から Vitest に移行 useFakeTimers({ shouldAdvanceTime: true }) @testing-library/reactを v15 にバージョンアップ MSW を v2 にバ
本連載について はじめまして！ サイボウズ フロントエンドエキスパートチームのnus3です。 本連載では、Webフロントエンドに関してもう一歩踏み込んだ知識について、サイボウズフロントエンドエキスパートチームのメンバーによって不定期で解説記事を掲載しています。 本記事では、モダンフロントエンドにおけるテストについて、その種類や導入方法などを紹介します[1]。 モダンフロントエンドでのテスト ここ数年のWebフロントエンドでは次のように、さまざまな変化がありました。 ReactやVue.jsといった宣言的UIを採用したライブラリの普及 TypeScript中心としたエコシステムの発展 ES Modulesの採用の広がり ViteやSWC、RspackやTurbopackなどの新しいビルドツールの登場 この変化に合わせて、Webフロントエンドを対象にしたテストのツールや手法も増えてきました。
この記事は一休.com Advent Calendar 2024の23日目の記事です。 一休レストランのフロントエンドアーキテクトを担当してる恩田(@takashi_onda)です。 はじめに 先日の JSConf JP 2024 で「React への依存を最小にするフロントエンドの設計」という内容で登壇しました。 speakerdeck.com 発表では駆け足になってしまった、React への依存をしていない Vanilla JS 部分をどのように構成しているのかを、Dependency 管理とテストの文脈でご紹介したいと思います。 Dependency とは Dependency Injection の Dependency です。 タイトルも「Jotai を使った DI とテスト技法」とした方が伝わりやすいとは思います。 ですが、厳密には injection していないので、あえて
こんにちは、Web チームの井手です。 この度 NIKKEI Professional Media（通称 Promedia）という新媒体をリリースしました。各トピックに特化したメディアで、現在は 日経モビリティ、日経GX、日経テックフォーサイトが展開されています。 これまで日経 Web チームでは特定の FW を利用せず、長年 JSX をテンプレートエンジンとした独自 FW を開発して、モノレポとして運用していました。これはチューニングの余地を自分で確保することや、自分たちのチームにあった規約を作りやすくするための選択です。しかし Promedia の開発は電子版本体のリリースサイクルと外れるためにモノレポの中に入れたくないことや、長年の開発の負債を引き継ぎたくないこと、なにより NextJS エコシステムの発達によって僕たちの要求をカバーできつつあることから、試験的に NextJS を採
Background これまでVitestでコンポーネントのテストを行う時は、jsdom や happy-dom を使ってブラウザ環境を偽装していました。しかし、偽のブラウザ環境を使うことは多くの問題があり、また開発者はテスト以外でどこにも存在しない環境を作り上げるという不毛な作業が必要でした。 この問題を解決するために、Playwright や Cypress などのテストフレームワークは Component Test をサポートしています。しかし、UnitテストでPlaywrightやCypressを使うのは少々Fatであり、Reactのhooksなどのテストをすることができません。 Vitest Browser Modeを使用することで、Vitest上でComponent Testが可能となり、これらの問題を解決できます。 Installation Browser ModeのSetu
Vitest was created to make testing just work for Vite apps. By building on top of Vite, Vitest natively understands your Vite config and is able to reuse the same resolve and transform pipelines. You can also use Vitest even if you are not using Vite. It is Jest-compatible and works for backend code too. Learn more
TL;DR: We are excited to announce that VoidZero is joining Cloudflare. Vite, Vitest, Rolldown, Oxc, and Vite+ will remain open-source and MIT-licensed. Evan and the rest of the VoidZero team will continue to lead these projects, with Cloudflare fully committed to supporting our mission. I have been working on open source developer tools for over a decade. From 2016 to 2023, I worked as an independ
import vitest from "@vitest/eslint-plugin"; export default [ { files: ["tests/**"], // or any other pattern plugins: { vitest }, rules: { ...vitest.configs.recommended.rules, // you can also use vitest.configs.all.rules to enable all rules + // e.g. 'vitest/no-test-return-statement': 'error', + "vitest/max-nested-describe": ["error", { "max": 1 }] // you can also modify rules' behavior using optio
先日VitestにこちらのPull Requestがマージされ、Vitest Browser ModeでVisual Regression Test（VRT）ができるようになりました（まだ正式リリースはされていません）。 おそらくVitest v4のリリースで正式に使えるようになりますが、beta versionで実際に試すことができるので試してみました。 デモ デモ用のコードはこちらのRepositoryにあります（ProviderはPlaywrightを使用しています）。vitest.configなどの設定は従来のbrowser modeの設定と全く同じで問題ないです。Vitestのバージョンは4.0.0-beta.7を使用しています。 expectの引数にElementを渡し、toMatchScreenshotを実行することでVRTができます。以下は実際のコードと生成された画像です。
上記以外で特筆すべき点として、他の開発者(≒チームメンバー)にとっては、変更の影響をほとんど受けずに、ノーコストで上記恩恵を受けられる点があります。 これは Vitest の Jest に対する高い互換性のおかげでテストコードの書き方に大きな変更がなかったことと、テスト実行コマンドを npm-scripts によって隠蔽していたことによるもので、移行したことに気づきさえしない可能性もあります。 Vite を使ってないのに Vitest 使ってええんか？ 今回 Jest から Vitest への移行を行ったプロジェクトは、開発サーバーやプロダクションビルドには Webpack を使用しており、Vite は一切使用していませんでした。 そういったプロジェクトにおいても、Vite をベースとしたテストフレームワークである Vitest は使用して良いものでしょうか？ これについては Vitest
Mita.ts #5 https://mitats.connpass.com/event/340678/ での登壇資料です。
はじめに Vitest はデフォルトの設定では、テストファイルごとに分離された環境を使用してテストを並列実行します。 この設定はグローバルな状態や副作用に依存した実装やライブラリなどを含むテストを並列実行するために有効です。 しかし、この設定は各テストファイルごとにテスト環境の起動や破棄を行うためテスト実行時間が長くなります。 この記事では React アプリケーションのテストコードを、環境の分離設定をやめて同一環境で実行することにより、実行速度を向上させた方法とそれに伴って発生した問題の修正方法についてご紹介いたします。 背景 弊社は microCMS というヘッドレス CMS を開発しており、その管理画面は React で開発されています。 大まかな構成としては、Vite を使用した SPA で、テストコードは testing-library/react を使用したコンポーネントテスト
Vitest 4.1 で aroundEach と aroundAll という新しいライフサイクルフックが追加されました。 github.com これらは文字通り、テストを 前後からwrapする フックです。aroundEach は各テストを、aroundAll はスイート全体をwrapします。runTest() や runSuite() の呼び出しを自分のコードで囲む構造になっており、名前のとおり"around"に処理を置けます。 しかしここで疑問が浮かびます。既存の beforeEach / afterEach で書けていたことが多い中で、なぜ新しいフックが必要だったのか説明できますか？ このエントリでは実際にコードを動かしながら、aroundEach / aroundAll / beforeEach / afterEachのユースケースについて確認していきます。 beforeEach
Vitest 3.0 is out! January 17, 2025 We released Vitest 2 half a year ago. We have seen huge adoption, from 4,8M to 7,7M weekly npm downloads. Our ecosystem is growing rapidly too. Among others, Storybook new testing capabilities powered by our vscode extension and browser mode and Matt Pocock is building Evalite, a tool for evaluating AI-powered apps, on top of Vitest. The next Vitest major is he
経緯 CSSを書いていて「あれ、なんで効かないんだっけ」ってなることないでしょうか。 私はしょっちゅうあります。 DevToolsを開いてもプロパティはちゃんと適用されてる。打ち消し線もない。でも見た目は変わらない。 しばらくして「ああ、インライン要素だから width 効かないんだった...」と気づくやつです。 他にも z-index を position: static のまま書いてたり、gap を flex でも grid でもない <div> に書いてたり。 CSSって構文的に正しければブラウザは何も言ってくれないので、こういう「効いてないCSS」が放置されがちです。 これを検出するChrome DevTools拡張を作りました。CSS Noop Checker です。 https://github.com/purupurupu/css-noop-checker なんで作ったのか
Vitest は Vite ベースのテスティングフレームワークです。 Vue/Vite チームの antfu 氏と、Vite チームの patak 氏が中心となって作っています。 発表されてからしばらく早期アクセスのためリポジトリ等が非公開でしたが、昨日公開されたので触ってみました。 （現在、鋭意開発中のため、まだプロダクション環境では使わないよう注意書きがあります）
どうもこんにちは、たくびーです。 最近、CIにかかる時間が気になり、その手始めとしてテストの高速化に挑戦していました。 今回はそこで得たボトルネックの特定方法と意外なボトルネックについて紹介したいと思います。 推測するな、計測せよ かの有名なロブ・パイク氏の「Notes on Programming in C」の言葉を意訳したものです。 Rule 2. Measure. Don't tune for speed until you've measured, and even then don't unless one part of the code overwhelms the rest. ルール2：計測する。計測するまでは速度のために調整せず、さらに、コードの一部が他の部分を圧倒しない限り、調整しないこと。 テストのパフォーマンスを向上させたいと思っても絶対に適当なところから始めないで
Claude Code /batch コマンドの使い方を実例で解説。Vitest テスト生成の並列実行、rules/skills でのルール適用、実案件で学んだ注意点をまとめました。 こんにちは！製造ビジネステクノロジー部の石井です。 Claude Code に /batch というコマンドがあるのをご存知でしょうか。 2026年2月28日の v2.1.63 でGAになった機能で、同じような作業を複数のワーカーに分解して並列実行してくれます。 実案件でも使ってみたんですが（その話は後半で）、今回はデモ用のプロジェクトを使ってシンプルに紹介してみます。 /batch コマンドとは Claude Code の /batch は、1つのプロンプトを複数のワーカーに分解して並列実行してくれるコマンドです。 ざっくりした流れはこんな感じです。 /batch を実行すると、まず Plan モードに入っ
手を動かしながら、Vitestの使い方を学ぼう！
Vitest allows you to write tests for your types, using expectTypeOf or assertType syntaxes. By default all tests inside *.test-d.ts files are considered type tests, but you can change it with typecheck.include config option. Under the hood Vitest calls tsc or vue-tsc, depending on your config, and parses results. Vitest will also print out type errors in your source code, if it finds any. You can
どうもみゅーとんです. 最近パフォーマンス周りで問題をおこしかけてしまったので, パフォーマンスの劣化を抑制する方法を調べてみました. 概要 3 行でまとめ public repository であれば, CodSpeed を無料で利用できる main ブランチでのパフォーマンスを計測しておき, Pull Request で劣化したら警告してくれる CodSpeed から, 内部処理を詳細に追うことができる 前提知識 vitest でパフォーマンステストを行う構成ができていることが条件になります. 導入方法についてはこの記事を確認してください. techblog.hacomono.jp CodSpeed とは docs.codspeed.io なんて読むんでしょうか・・？私はコードスピードと呼んでいますが, コッドスピードのほうが正しそう・・？ GitHub Actions で実行した P
Nuxt 3 × Vitest で既存のユニットテストを全て通すための調査レポート こんにちは、ANDPADでフロントエンドエンジニアをしている小泉（@ykoizumi0903）です。 昨年末に Nuxt 3 が正式リリースされて以降、アップデートに向けた移行作業を粛々と進めています！ 今回はその中でも、ユニットテストを Nuxt 3 に対応させる際に苦労したポイントや対処法についてご紹介したいと思います。 私達のチームでは昨年秋以降、コンポーネントユニットテストの拡充に力を入れてきていて、その一環として元々 Jest から Vitest にテストツールを移行していました。 しかし、Nuxt 3 への移行作業を行ったことで、これらのテストのうちの約半分が失敗するようになりました。 この記事では、このテストのエラーをどのように解消したかの流れをまとめて説明したいと思います。 （Nuxt 2
Claude, v0, etc are incredible- but you can't install packages, run backends or edit code. That’s where Bolt.new stands out: Full-Stack in the Browser: Bolt.new integrates cutting-edge AI models with an in-browser development environment powered by StackBlitz’s WebContainers. This allows you to: Install and run npm tools and libraries (like Vite, Next.js, and more) Run Node.js servers Interact wit
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
現在JavaScriptのスタンダードなテスティングフレームワークと言えば、Jestかと思います。 Jestはそれ単体でテストランナー、マッチャーからモックまでテストに関する一通りの機能を網羅する万能なフレームワークです。 とはいえ、プロダクトがある程度の規模になってくるとテスト実行時間に不満を持っている方もいるかもしれません。 今回はJestに代わる新しいテスティングフレームワークのVitestを試してみたいと思います。 VitestはWebpackに代わる高速ビルドツールのViteを基盤としています[1]。 Viteのパイプラインとして実行されますので、テストも高速になるはずです。 Vitestの公式サイトでも、Blazing Fast Unit Test Frameworkと宣伝してるところからも期待できそうです。 また、API自体もJestと互換性を保つように設計されていますので、
Newly uncovered flaws expose millions of development setups to a dangerous Vitest remote code execution hazard. This framework commands an immense user base with over 53 million weekly downloads globally. Consequently, threat actors can hijack active local programming environments via web-based workflows. Therefore, enterprise engineering teams must evaluate their server setups immediately to prev
こんにちは。フロントエンドエンジニアの相澤 ( @ttt3pu ) です。 みなさま、Nuxt 2 から Nuxt 3 へのアップグレードは順調でしょうか。 メドピアでは、2023年末のVue 2のEOLへ向けて、 各プロダクトで積極的にNuxt 3へのアップグレードを進めています。 現在私の担当しているプロダクトでは、マイグレーション作業自体はほぼ完了しており、 残すはQAテストなどを行うのみと言う段階で、本番リリースまであと一歩というところまで進んでおります！ 🎉 マイグレーションの事例も徐々に増え始めてきて、Nuxt 3のリリース当初よりも段々と移行はしやすくなってきましたが、 個人的に結構大変だったのがユニットテストのマイグレーション作業でした。 当記事では、マイグレーションに当たっての Tips と、ついでに Vitest を導入したことにより、 実行速度が 約 10分 ->
Vitest 4.0 is out! October 22, 2025 The next Vitest major is here Today, we are thrilled to announce Vitest 4! Quick links: DocsTranslations: 简体中文Migration GuideGitHub ChangelogIf you've not used Vitest before, we suggest reading the Getting Started and Features guides first. We extend our gratitude to the over 640 contributors to Vitest Core and to the maintainers and contributors of Vitest int
はじめに Viteのバージョン4.0の公開をアナウンスするブログでVitestについて言及されていました。 Vitest adoption is exploding, it will soon represent half of Vite's npm downloads. Nx is also investing in the ecosystem, and officially supports Vite. Vitestの採用は爆発的に増えており、まもなくViteのnpmダウンロードの半分を占めるようになるでしょう。Nxもエコシステムに投資しており、Viteを公式にサポートしています。(DeepLによる翻訳) これまではJavaScript、TypeScriptにおけるテストツールとしてはJestという成熟したツールがあるので、Vitestを利用するのは趣味だったり少し先の未来だろうと考え
zod などで作成した schema に対して Vitest で Unit テストを記述する際に以下のような if 文を書くことがあります。 import { z } from 'zod'; export const userSchema = z.object({ name: z.string().min(1, "Name is required"), }); import { z } from 'zod'; import { test, expect } from 'vitest'; test('parseに失敗すること', () => { const result = userSchema.safeParse({ name: "" }); expect(result.success).toBe(false); // expect.toBeでは型の絞り込みがされないため、if文でresu
今回は以下のライブラリを中心にVueにおけるテスト駆動開発(TDD)の進め方を説明します。 Vue3 Vitest Testing Library Mock Service Worker Options APIで書きますが、テストコードはComposition APIでも動くので、 Composition APIの実装に多少慣れてる人はぜひとも挑戦してください。 今回の記事の中で作ったコードは以下のリポジトリに収めました。 テスト駆動開発(TDD)ってなに？ TDDとはTest Driven Development（テスト駆動開発）の略であり、その文字通り、 テストを先に書いてその後にそのテストを満たすコードを書くことを繰り返しながら進める開発手法です。 XP(Extreme Programming)のアプローチの1つとしてとても有名です。 実施においては以下の図のRedから順番に開発をサ
本文書はJestとVue Test Utilを利用したVue.jsでのテストに関する2回目の記事で2回目となる今回はテスト入門者にとって少しわかりずらいStub(スタブ)やMock(モック)、Shallow Mountに注目して説明を行っています。 Stub, ShallowMountとMountの違いを説明した後にVue.jsのHTTPリクエストで頻繁に利用されるaxiosのMock(モック)の方法についても説明を行っています。コンポーネントの単体テストでは、axiosライブラリやfetch関数を利用した外部へのアクセスを伴う機能を実装している場合モックを利用することで外部へのアクセスを行うことなくコンポーネントのテストを実施することができます。 Vueでのテストを実施したまたは学習した経験がない人であれば先に前回公開した”【基本編】Jestを利用してVue コンポーネントをテストする方
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く