Vitest 4.1 is out! March 12, 2026 The next Vitest minor is here Today, we are thrilled to announce Vitest 4.1 packed with new exciting features! Quick links: DocsTranslations: 简体中文GitHub ChangelogIf you've not used Vitest before, we suggest reading the Getting Started and Features guides first. We extend our gratitude to the over 713 contributors to Vitest Core and to the maintainers and contrib
If you’ve been testing anything front-end related in the past 10 years, you’ve likely used JSDOM. In itself, JSDOM is not an environment or runtime. It’s a polyfill library, containing implementations for a bunch of WHATWG standards, like HTML and DOM, for Node.js. Why Node.js? Well, because the library’s goal is to execute browser-oriented code without paying the cost of spawning the actual brows
はじめにlink 最近DBありのテストを記述していた際に、実はvitestではbeforeEachは必要ないのではないか、という考えに至ったのでその理由と設計についてまとめてみる。 下記のリポジトリで実験する https://github.com/koh110/vitest-beforeeach テストでbeforeEachが欲しくなるシーンlink テストを記述する際にbeforeEachが欲しくなるシーンは主に以下の2点ではないかと考えている。 mockの設定/reset seedsの投入 このうち、前者mockの設定/resetはbeforeEachではなくbeforeAll or すべての個別テストごとに設定すべきなのではと考えている。 これは自分がテスト単体での移植性を重視している（テスト単体をコピペしてもなるべくそのまま動かせる）ので、beforeEachでやってしまうとあるテ
過去のテストの実行時間を利用してテストの sharding を効率化する Tenbin というツールを作りました。 この記事では Tenbin が解決する課題と内部実装の詳細について解説します。ツールの使い方などは、リポジトリの README をぜひ読んでもらえればと思います。 Tenbin が解決する課題 テストの実行時間を削減するために、CI などではテストを sharding (分割) して実行することがあると思います。フロントエンドでよく使われる Jest、Vitest、Playwright などのツールでは、実際に sharding の機能を提供しています。 確かに sharding はテストの実行時間を削減できるのですが、分割のアルゴリズムがいまいちで shard 毎の実行時間に大きく差が出てしまった経験はないでしょうか？[1]Tenbin は、この問題を過去のテストの実行時間
登壇者 TypeScriptでバックエンドのテストを書くときの課題早速なんですが、みなさんテストを書いてますでしょうか？ 昨今では、TypeScriptでバックエンドを書けるのが普通になってきました。バックエンドで利用できるORMやフレームワークも充実してきています。 バックエンドはフロントエンドに比べてデータベースを扱ったり、重要なロジックが含まれているので、しっかりとテストを書きたいというモチベーションが湧いてくると思います。 そこで課題になるのが、テストデータの準備ですね。 例えば、Prismaで「ユーザーが管理者ならtrueを返す」というシンプルな関数を作ったとします。テスト対象のコードがシンプルなので、テストもシンプルに書けると思うかもしれません。 しかし、上記のテストコードを見てもらうとわかるとおり、ユーザーデータの作成する処理で数行のコードを書く必要があります。テストと関係の
こんにちは！estieでQAエンジニアをしているかすや（https://twitter.com/ma_cho29）です。 今回ブログを書くにあたり、前回書いたのはいつだったかなー？と見返すと1年が経過していたことに気がつきました。 歳を重ねると体感時間が短くなると聞いたことがありますがそれでしょうか・・・ 入社3年目になる今年もやり残しがないように過ごしたいところです。 さて、今回はQA未経験だった私が1人目のQAエンジニアとしてestieに入社し現在までおこなってきたE2Eテスト自動化の変遷について語っていきたいと思います。 私がメインで関わっているプロダクト「estie マーケット調査」は約2年間でテストフレームワーク移行を2度おこないました。 当時の意思決定やその際に個人的に感じたフレームワークごとのメリット・デメリットなど含めて話したいと思います。 （あくまで僕の所属する開発チーム
Secretlint v7でCommonJS からES Modulesへの移行を行いました。 Secretlint v7.0.0をリリースしました。Pure ESMへの書き直し この記事では、CommonJS(CJS)からES Modules(ESM)への移行を行った経緯と、移行する方法について紹介します。 CJSからESMへの移行は、率直に言えば単調な作業で、メリットが見えにくい作業です。 しかし、将来的にCJSよりもESMが主流になることは間違いないので、移行することは必要です。 移行の作業は、移行方法が決まれば大部分は機械的な書き換えが可能です。 では、実際にどうやって移行したのかを紹介します。 ESMへの移行の影響は依存元へと連鎖する Secretlintのリポジトリはmonorepoになっていて、だいたい40コぐらいのパッケージが含まれています。 そしてパッケージ間で依存関係があ
機密情報をLintできるSecretlintのv7.0.0をリリースしました！ Release v7.0.0 · secretlint/secretlint このバージョンでは、SecretlintをESMモジュールとして書き直しました。 どのように移行したかは別の記事で紹介しているので、移行方法について記事を参照してください CommonJSからES Modulesへの移行する方法。トップダウンかボトムアップか Secretlint v7.0.0の変更点 ルールと本体のコードを含めて、全部のパッケージをESMに書き直しました。 その中で、いろいろ整理したりもしたので、変更点はいろいろあります。 ただし、secretlintコマンドや@secretlint/quick-start、Docker Imageとして使う場合は、そこまで目にみえる変化は少ないと思います。 詳細はリリースノートも参
Property Based Testing ライブラリの fast-check を試してみたのでまとめます。 Property Based Testingとは？ Property Based Testing は、Haskell のライブラリ QuickCheck からはじまったテストスタイルで、定義された条件に合わせて自動生成された膨大な値に対してテストを行う手法です。Property Based Testing のライブラリに入力値の条件を渡すと、その条件から複数のテストケースを自動生成し実行してくれます。 短いコードで膨大なテストケースを検証できる点、テストケースが開発者に依存せず意図しないエッジケースをテストできる点がメリットとしてあります。 （参考） fast-checkとは？ fast-check は JavaScript で Property Based Testing を実
はじめましての人ははじめまして。そうでないひとはお久しぶりです。猫ロキP(@deflis/id:deflis55)です。 みなさんはReactでテスト書いてますか？私は最近書き始めました。 タイトル通りなんですが Testing Library のテストは、Testing Libraryに標準で入っている fireEvent よりも、外部ライブラリの @testing-library/user-event を使おうというお話です。 user-event はシンプルに書ける上に、メリットがたくさんあるのでおすすめのライブラリです。 なぜ user-event を使うべきなのか なぜこれを使おうというになるか話かというと、 fireEvent は単純にDOMイベントを発生させるのに対し、 user-event は全ての入力に対するイベントを発生させるからです。 でも、それ以上に簡素に書けること
最近 GitHub Actions を弄くり倒すことにハマっていて、 GitHub の Checks API を利用して annotation を出すおもてなしをすることだけが生きがいだと思って生活していました。 そんな中、JavaScript (TypeScript) のコードのテストでよく使われている Jest で、どの assertion が落ちているかを annotation で分かりやすく表示したいと思っていました。自作で頑張ろうかな～と思って調べていると、 Jest 28.0.0 （2022年4月末ごろリリース）から Github Actions で annotation を出す reporter 機能が組み込まれていたという事実を知りました。 jestjs.io この便利機能が思ったより世の中で使われていない感じがしたので紹介します。 サンプル こちらをどうぞ： github
Builtin Node.js Testing As of Node.js 18, which became stable in April 2022, you can test your backend code without installing any dependencies. This works because of the new node:test package, along with the existing node:assert package—which is from the very first releases of Node. Here's the tl;dr. First, write a script like this, naming it e.g., "test.js": import test from 'node:test'; import
What's wrong with this test? // __tests__/checkout.js import * as React from 'react' import { render, screen } from '@testing-library/react' import userEvent from '@testing-library/user-event' import { client } from '#app/utils/api-client' jest.mock('#app/utils/api-client') test('clicking "confirm" submits payment', async () => { const shoppingCart = buildShoppingCart() render(<Checkout shoppingCa
(社内用ドキュメントの公開版) テストのポリシー 前提として、ユニットテストを導入するコストを、限界まで低くすることを目指す。テストが根付いていない言語環境や文化では、放っておくとテストが書かれないまま実装が進行し、結果としてテスト不可能な巨大な雪だるまが完成する。こうなるとメンテコストが高いE2Eを大量に書かないといけなくなり、テストの実行時間が膨れ上がっていく。 そうなる前に、ユニットテストを書きやすい環境を維持し、ユニットテストとして問題を切り分けられるような環境を維持する。とにかく書きやすさを重視し、一つのユニットテストを書くオーバーヘッドを限界まで下げる。 最初の一つを早い段階で書く 自分の経験的には、ユニットとテストの最初の一つを書いたらあとは自然とその周辺で増えていく。サンプルがあったら人はコピペする。逆にいうと最初の一つを書かない限り一切書かれない。まず一つ用意するのが大事
2021/09/13 Open8 で発表したフロントエンドテストプラクティスの話です。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
