はじめに 株式会社ナレッジワーク Engineering Division のわだまる（@wadackel）です。 ナレッジワークの Web フロントエンド開発では、Storybook を活用したコンポーネント開発を行っています。そして、昨年末により良いコンポーネント開発の基盤整備を進めるべく @storybook/test-runner（以降 Storybook Test ruuner）を導入しました。導入目的としては主に、各 Story に対するスモークテスト、play 関数を活用したコンポーネントテストを行うことです。 さらに、ナレッジワークでは前述した通常のコンポーネントテストに加えて、reg-suit と storycap を利用した Visual Regression Testing（以降 VRT）を行っています。 これまでは Storybook を活用したテストは VRT の
過去のテストの実行時間を利用してテストの sharding を効率化する Tenbin というツールを作りました。 この記事では Tenbin が解決する課題と内部実装の詳細について解説します。ツールの使い方などは、リポジトリの README をぜひ読んでもらえればと思います。 Tenbin が解決する課題 テストの実行時間を削減するために、CI などではテストを sharding (分割) して実行することがあると思います。フロントエンドでよく使われる Jest、Vitest、Playwright などのツールでは、実際に sharding の機能を提供しています。 確かに sharding はテストの実行時間を削減できるのですが、分割のアルゴリズムがいまいちで shard 毎の実行時間に大きく差が出てしまった経験はないでしょうか？[1]Tenbin は、この問題を過去のテストの実行時間
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
Rob Pike 2 December 2013 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 p
数日前の退勤間際、１つ機能を実装してPull Requestを作って満足した気持ちで退勤しようとしていた。しかし作ったPRを見るとCIのテストが失敗している。どうやら失敗しているユニットテストがあるらしい。テストの結果を覗くと心当たりのない日付に関係するテストが失敗している……。月末だったら閏年の関係とか、そういうことも考えられるがまだ月末ではない。おかしいな、と思いつつ、明日に再実行したら成功するかも知れないし、ひとまず忘れて退勤した。 翌日、出社すると他のブランチでも漏れなくCIのユニットテストが失敗していることがわかった。これではリリースもできないので、ちゃんと調べて修正することにした。失敗しているテストを見るとタイムゾーンがUTC-3の場合のテストをしているようだった。指定されているロケールは America/Sao_Paulo サンパウロ、ブラジルの都市だ。 最初に思いついたのは
たまたま社内で自分が主催しているアジャイルに関する勉強会で BDD (Behaviour-Driven Development) の話をすることがあった。 個人的には、「Given, When, Then でテスト書くやつでしょ？」といった形で Gherkin記法 だけが一人歩きしている印象があるためその誤解を解くことを目的にその勉強会では話題に挙げたのでその熱が冷めないうちに自分の認識のメモを残しておきたい。 とはいえ、 https://cucumber.io/docs/bdd/ を読めば全てが書いてあるので気になった人はそちらを参照して欲しい。 前置きはそれくらいにしつつ、上記のドキュメントの中から抜粋してきた以下の画像が BDD の全体を示している。 この図が言わんとすることは、 BDD というのは Discover Formulation Automation の3つのステップで構
Efficiency Redefined: CloudBees Acquires Launchable to Enable Development Teams to Iterate Faster 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 c
登壇者 TypeScriptでバックエンドのテストを書くときの課題早速なんですが、みなさんテストを書いてますでしょうか？ 昨今では、TypeScriptでバックエンドを書けるのが普通になってきました。バックエンドで利用できるORMやフレームワークも充実してきています。 バックエンドはフロントエンドに比べてデータベースを扱ったり、重要なロジックが含まれているので、しっかりとテストを書きたいというモチベーションが湧いてくると思います。 そこで課題になるのが、テストデータの準備ですね。 例えば、Prismaで「ユーザーが管理者ならtrueを返す」というシンプルな関数を作ったとします。テスト対象のコードがシンプルなので、テストもシンプルに書けると思うかもしれません。 しかし、上記のテストコードを見てもらうとわかるとおり、ユーザーデータの作成する処理で数行のコードを書く必要があります。テストと関係の
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
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
When we introduced a default setup for system tests in Rails 5.1 back in 2016, I had high hopes. In theory, system tests, which drive a headless browser through your actual interface, offer greater confidence that the entire machine is working as it ought. And because it runs in a black-box fashion, it should be more resilient to implementation changes. But I'm sad to report that I have not found
この記事では、2023 年の WebDriver BiDi の新機能の概要について説明します。 WebDriver BiDi とは WebDriver は、W3C 標準として定義されたブラウザ自動化プロトコルであり、ChromeDriver、GeckoDriver、WebKitDriver で実装されています。 Chromium には、独自のブラウザ自動化プロトコルである Chrome DevTools プロトコル（CDP）もあります。 この 2 つのプロトコルには根本的な違いがあります。WebDriver は相互運用可能な標準ですが、プロトコルの効率が低く、CDP にはない機能があります。一方、CDP はより効率的で強力ですが、相互運用性は低くなります。 そのため、2020 年に W3C ブラウザ テストとツールのワーキング グループは、WebDriver Classic プロトコルと
ウェブブラウザを自動操作する際には、WebDriverやChrome DevTools Protocol (CDP) などのAPIが広く利用されています。 これらのAPIを基盤に構築された様々なブラウザ自動操作フレームワークが、テスト自動化の分野で重要な役割を果たしています。 例えば、SeleniumやPlaywrightといったフレームワークを利用して、テストの自動化に取り組まれている方もいらっしゃると思います。 私もテスト自動化フレームワークの便利さを享受する一方で、フレームワークを介さずにブラウザを自動操作する方法についての興味がわいてきました。 そこで、この記事ではWebDriverやCDPが提供するAPIを直接利用してブラウザを操作する方法を基礎から探求してみることにしました。 これにより、私たちが普段利用しているフレームワークの背後にある原理を理解し、より深い知見を得ることを目
Unit testing is often talked about in software development, and is a term that I've been familiar with during my whole time writing programs. Like most software development terminology, however, it's very ill-defined, and I see confusion can often occur when people think that it's more tightly defined than it actually is. 1 Although I'd done plenty of unit testing before, my definitive exposure wa
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
