Announcing Vitest 4.1
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
Post by @eranki · 1 image
I was in charge of scaling Dropbox for a while, from roughly 4,000 to 40,000,000 users. For most of that time we had one to three people working on the backend. Here are some suggestions on scaling, particularly in a resource-constrained, fast-growing environment that can't always afford to do things "the right way" (i.e., any real-world engineering project ;-). If people find this useful, I'll tr
Why I Won’t Use JSDOM
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
vitestではbeforeEachを使わない
はじめにlink 最近DBありのテストを記述していた際に、実はvitestではbeforeEachは必要ないのではないか、という考えに至ったのでその理由と設計についてまとめてみる。 下記のリポジトリで実験する https://github.com/koh110/vitest-beforeeach テストでbeforeEachが欲しくなるシーンlink テストを記述する際にbeforeEachが欲しくなるシーンは主に以下の2点ではないかと考えている。 mockの設定/reset seedsの投入 このうち、前者mockの設定/resetはbeforeEachではなくbeforeAll or すべての個別テストごとに設定すべきなのではと考えている。 これは自分がテスト単体での移植性を重視している（テスト単体をコピペしてもなるべくそのまま動かせる）ので、beforeEachでやってしまうとあるテ
モダンなフロントエンドにおけるテストについて ［Modern Featured Test］ | gihyo.jp
本連載について はじめまして！ サイボウズ フロントエンドエキスパートチームのnus3です。 本連載では、Webフロントエンドに関してもう一歩踏み込んだ知識について、サイボウズフロントエンドエキスパートチームのメンバーによって不定期で解説記事を掲載しています。 本記事では、モダンフロントエンドにおけるテストについて、その種類や導入方法などを紹介します[1]。 モダンフロントエンドでのテスト ここ数年のWebフロントエンドでは次のように、さまざまな変化がありました。 ReactやVue.jsといった宣言的UIを採用したライブラリの普及 TypeScript中心としたエコシステムの発展 ES Modulesの採用の広がり ViteやSWC、RspackやTurbopackなどの新しいビルドツールの登場 この変化に合わせて、Webフロントエンドを対象にしたテストのツールや手法も増えてきました。
Storybook Test ruuner で安定した Visual Regression Testing を行う
はじめに 株式会社ナレッジワーク Engineering Division のわだまる（@wadackel）です。 ナレッジワークの Web フロントエンド開発では、Storybook を活用したコンポーネント開発を行っています。そして、昨年末により良いコンポーネント開発の基盤整備を進めるべく @storybook/test-runner（以降 Storybook Test ruuner）を導入しました。導入目的としては主に、各 Story に対するスモークテスト、play 関数を活用したコンポーネントテストを行うことです。 さらに、ナレッジワークでは前述した通常のコンポーネントテストに加えて、reg-suit と storycap を利用した Visual Regression Testing（以降 VRT）を行っています。 これまでは Storybook を活用したテストは VRT の
テストの sharding を効率化する Tenbin というツールを作った
過去のテストの実行時間を利用してテストの sharding を効率化する Tenbin というツールを作りました。 この記事では Tenbin が解決する課題と内部実装の詳細について解説します。ツールの使い方などは、リポジトリの README をぜひ読んでもらえればと思います。 Tenbin が解決する課題 テストの実行時間を削減するために、CI などではテストを sharding (分割) して実行することがあると思います。フロントエンドでよく使われる Jest、Vitest、Playwright などのツールでは、実際に sharding の機能を提供しています。 確かに sharding はテストの実行時間を削減できるのですが、分割のアルゴリズムがいまいちで shard 毎の実行時間に大きく差が出てしまった経験はないでしょうか？[1]Tenbin は、この問題を過去のテストの実行時間
Download old Headless Chrome as chrome-headless-shell | Blog | Chrome for Developers
Earlier this year, we announced the availability of Chrome's new Headless mode (--headless=new) in Chrome 112. This mode enables developers to run Chrome in an unattended environment without any visible UI—useful for testing and automation use cases. As part of this announcement, we mentioned our plans to remove the old Headless mode from the Chrome binary. This removal makes sense, as the old Hea
The cover story - The Go Programming Language
Introduction From the beginning of the project, Go was designed with tools in mind. Those tools include some of the most iconic pieces of Go technology such as the documentation presentation tool godoc, the code formatting tool gofmt, and the API rewriter gofix. Perhaps most important of all is the go command, the program that automatically installs, builds, and tests Go programs using nothing mor
ロケールにサンパウロを指定しているテストが突然失敗 - はてなブログ
数日前の退勤間際、１つ機能を実装してPull Requestを作って満足した気持ちで退勤しようとしていた。しかし作ったPRを見るとCIのテストが失敗している。どうやら失敗しているユニットテストがあるらしい。テストの結果を覗くと心当たりのない日付に関係するテストが失敗している……。月末だったら閏年の関係とか、そういうことも考えられるがまだ月末ではない。おかしいな、と思いつつ、明日に再実行したら成功するかも知れないし、ひとまず忘れて退勤した。 翌日、出社すると他のブランチでも漏れなくCIのユニットテストが失敗していることがわかった。これではリリースもできないので、ちゃんと調べて修正することにした。失敗しているテストを見るとタイムゾーンがUTC-3の場合のテストをしているようだった。指定されているロケールは America/Sao_Paulo サンパウロ、ブラジルの都市だ。 最初に思いついたのは
BDD は Given, When, Then のことだと勘違いされているんじゃないか
たまたま社内で自分が主催しているアジャイルに関する勉強会で BDD (Behaviour-Driven Development) の話をすることがあった。 個人的には、「Given, When, Then でテスト書くやつでしょ？」といった形で Gherkin記法 だけが一人歩きしている印象があるためその誤解を解くことを目的にその勉強会では話題に挙げたのでその熱が冷めないうちに自分の認識のメモを残しておきたい。 とはいえ、 https://cucumber.io/docs/bdd/ を読めば全てが書いてあるので気になった人はそちらを参照して欲しい。 前置きはそれくらいにしつつ、上記のドキュメントの中から抜粋してきた以下の画像が BDD の全体を示している。 この図が言わんとすることは、 BDD というのは Discover Formulation Automation の3つのステップで構
CloudBees Acquires Launchable to Enable Development Teams to Iterate Faster By Slashing the QA Cycle
Today we’re thrilled to announce that Launchable is joining the CloudBees family. Launchable’s innovative AI-augmented approach to QA aligns perfectly with CloudBees’ mission to deliver better, more secure and compliant software faster than ever. By acquiring Launchable, we can quickly integrate the company’s robust test suite intelligence and optimization capabilities to remove friction from the
テスト用のオブジェクトを簡単に作れるFactoryJSというライブラリを作った｜noteエンジニアチームの技術記事
登壇者 TypeScriptでバックエンドのテストを書くときの課題早速なんですが、みなさんテストを書いてますでしょうか？ 昨今では、TypeScriptでバックエンドを書けるのが普通になってきました。バックエンドで利用できるORMやフレームワークも充実してきています。 バックエンドはフロントエンドに比べてデータベースを扱ったり、重要なロジックが含まれているので、しっかりとテストを書きたいというモチベーションが湧いてくると思います。 そこで課題になるのが、テストデータの準備ですね。 例えば、Prismaで「ユーザーが管理者ならtrueを返す」というシンプルな関数を作ったとします。テスト対象のコードがシンプルなので、テストもシンプルに書けると思うかもしれません。 しかし、上記のテストコードを見てもらうとわかるとおり、ユーザーデータの作成する処理で数行のコードを書く必要があります。テストと関係の
Improving Web Accessibility with Web Platform Tests
Last year, a colleague introduced me to the Interop Accessibility project. I immediately resonated with its charge to “improve the state of accessibility across the entire web, regardless of which platform, browser, or assistive technology.” The project’s mission was compelling but it also represented, from my perspective, a transformative example of shifting accessibility to the level of web plat
localtest.me
Save this URL, memorize it, write it on a sticky note, tweet it, tell your colleagues about it! localtest.me (http://localtest.me) and *.localtest.me (http://something.localtest.me) If you do any testing on your local system you’ve probably created hosts file entries (c:\windows\system32\drivers\etc\hosts) for different testing domains and had them point back to 127.0.0.1. This works great but it
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Incredible Vitest Defaults
約9000個の自動テストの 時間を50分->10分に短縮 Flakyテストを1%以下に抑えた話
Enter WebSockets
上手に付き合うコンポーネントテスト
IME Test
