PHPカンファレンス小田原2024での発表資料です https://fortee.jp/phpconodawara-2024/proposal/4d39c7ef-058c-4648-b1d7-5510497e0d81
この記事では、2023 年の WebDriver BiDi の新機能の概要を説明します。 WebDriver BiDi とは WebDriver はブラウザ自動化プロトコルで、W3C 標準として定義され、ChromeDriver、GeckoDriver、WebKitDriver に実装されています。 Chromium には、Chrome DevTools プロトコル(CDP)という独自のブラウザ自動化プロトコルもあります。 この 2 つのプロトコルには根本的な違いがいくつかあります。WebDriver は相互運用可能な標準ですが、このプロトコルは効率が悪く、CDP のような機能がありません。対照的に、CDP はより効率的で強力ですが、相互運用性は劣ります。 そのため、2020 年、W3C Browser Testing and Tools Working Group は、WebDriver
ウェブブラウザを自動操作する際には、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
Lost Pixel Lost PixelとはWeb UIのビジュアル回帰テスト(VRT)のためのツールであり、キャプチャの撮影と差分の検出を一つのプロセスで行うことができるオープンソースライブラリです。 Web UIのVRTというと、storycap + reg-suit や、Playwrightのスナップショット機能、または Chromatic のようなサービスを思い浮かべる方も多いと思いますが、まさにそれらの類似ツールにあたるものであると捉えていただいて差し支えありません。 本記事では具体的な導入手順などは省き、Lost Pixelの特徴や他の類似ツールとの比較、または筆者の用途とカスタマイズについて紹介します。 記事を読んで、実際に導入を検討される場合のインストール方法やセットアップに関しては、公式のドキュメントを参照してください。 また、Lost Pixelにはプラットフォームモ
テストを書いてないというチームには色々理由があると思いますが、「何をテストすべきかわからない」「書き方がわからない」「どのくらいメリットがあるかわからない」という意見は多いのではないでしょうか?テスティングフレームワークの選定や使い方を学ぶのは重要ですが、それ以上にテストの目的や戦略を学ぶことが重要です。チーム開発においてテストを活かすのは相応の知識とスキルが必要になりますが、活かせればテストは開発スピードを維持・促進する飛び道具になり得ます。 本稿は筆者が取り組んで実際に高いチーム満足度と速度を得られた、テスト戦略についてまとめたものです。
2023/12/20(水) https://findy.connpass.com/event/303813/
こんにちは。カミナシにて業務委託としてフロントエンドを担当している田村(@junkboy0315)です。皆さんはフロントエンドのテスト、どのように取り組んでいますか?フロントのテストはなかなか難しいですよね。 バックエンドのテストには、「入力、出力、永続化されたデータ」の3つを検証するという基本セオリーがあります。しかし、フロントエンドのテストは、その粒度や手法が多様で、とっつきにくいと感じる方も多いのではないでしょうか。 カミナシでもフロントエンドのテストは以前は十分とは言えない状態でしたが、これまで継続的に改善を重ねてきました。今回は、その変遷についてお話ししようと思います。 夜明け前 カミナシのコードベースでは、元々ユニットテストがある程度整備されていました。これらは主に複雑な計算処理を行い結果を返す関数などに対して実施されていました。 しかし、画面全体の機能を網羅する包括的なテスト
Improving Cross-Browser Testing, Part 1: Web Application Testing Today Testing web applications can be a challenge. Unlike most other kinds of software, they run across a multitude of platforms and devices. They have to be robust regardless of form factor or choice of browser. We know this is a problem developers feel: when the MDN Developer Needs Assessment asked web developers for their top pain
皆さんこんにちは。この記事では、筆者が最近業務中に経験した恐るべき罠についてシェアしたいと思います。 CIでユニットテストを実行することは、とても多くのプロジェクトで行われています。ユニットテストは特に、既存のコードの変更を自信を持って行うために必要なものです。弊社でも、CI (GitHub Actions) でユニットテストを実行しています。 あるとき、CIの挙動が不安定になったことをきっかけに、CI上でのユニットテストの実行について調べてみました。その結果、とんでもないことが判明したのです。 不安定になったCI 時折、CIにすごく時間がかかり、30分経ったあたりでタイムアウトしてしまうことがありました。そのときのログを見てみると、jestによるユニットテストが実行されている最中に、何のログも出力せずに突然止まっているようでした。そのようなときはリトライするとそこそこの確率で成功します。
この記事は、株式会社カオナビ Advent Calendar 2023 の3日目です。 はじめに 株式会社カオナビの高橋(@kunit)です。 今回は MySQL バージョンアップ(5.7 -> 8.0) で起きた問題とそれに対してどのように対処したのかを書いていこうと思います。 何が起きたのか MySQL 5.7 から 8.0 にバージョンアップをするにあたって、CI およびローカル環境でテストができるように MySQL 8.0 のイメージを作成し、それをつかって各機能の担当者にテストを開始してもらっていたのですが、以下のような事が起きました。 接続を MySQL 5.7 から 8.0 に切り替えただけでテストの時間が3倍くらいかかるようになった そこを変更するだけで3倍遅くなるってやばいぞということで報告してくれた担当者と同じテストを自分でも実施してみると再現性があり、それが以下のどの
Visual Regression Test(以下VRT)をやろうと思うと画像をどこに保存するかを検討する必要がでてくるケースがある。 (web アプリケーションのVRTを前提とすると)多くの場合、テキスト形式である*.snapとは異なり、画像取得時のOSやfont、ブラウザのversionなどにより差分がでやすくなってしまう。そのため画像はCIなど環境を極力そろえた状態で取得し、S3などに上げVRT対象の画像を管理するケースがみられる。 今回はこのフロー・管理の簡略化を目指しactionsを作成・リリースした。 成果物 repositoryは以下。yamlに後述するstepを記述すれば使用できる。 セットアップ 最小の記述は以下となる。これで./images以下の画像に対してVRTを行ってくれる。VRTに必要な画像管理はactionsが受け持ち、PRごとにレポートをコメントする。 nam
こんにちは!estieでQAエンジニアをしているかすや(macho | きんにQA💪🏾 (@ma_cho29) / X)です。 今回ブログを書くにあたり、前回書いたのはいつだったかなー?と見返すと1年が経過していたことに気がつきました。 歳を重ねると体感時間が短くなると聞いたことがありますがそれでしょうか・・・ 入社3年目になる今年もやり残しがないように過ごしたいところです。 さて、今回はQA未経験だった私が1人目のQAエンジニアとしてestieに入社し現在までおこなってきたE2Eテスト自動化の変遷について語っていきたいと思います。 私がメインで関わっているプロダクト「estie マーケット調査」は約2年間でテストフレームワーク移行を2度おこないました。 当時の意思決定やその際に個人的に感じたフレームワークごとのメリット・デメリットなど含めて話したいと思います。 (あくまで僕の所属する
この記事では、Playwright の VSCode 拡張を使って GUI 操作のみでテストの記録や実行する方法について紹介します。 Playwright の VSCode 拡張とは? Playwright の VSCode 拡張は、Playwright の作成元である Microsoft が公式に提供している拡張機能で、VSCode 内で直接ブラウザテストの記録や実行を支援するための便利なツールです。 GUI 操作を中心に、テストの記録や実行を手軽に行うことが可能となります。 VSCode 拡張のインストールは、以下のリンクから行うことができます。 VSCode 拡張を活用してテストを書く 本記事では、シンプルな ToDo アプリを例にテストの作成方法を説明します。Playwright のインストール方法は、公式ドキュメントをご参照ください。その後、VSCode に Playwright
この記事は Go Advent Calendar 2013 の 9 日目の投稿です。 今回は、 Go の testing というパッケージの使い方を解説しようと思ったのですが、 それだとつまらなすぎるので、合わせて Go が test というか assert についてどういうスタンスをとっているかを書いてみます。 Go でテスト さて、「テストのないコードはレガシーコード」などと言われて久しく、様々な言語が test (主に Unittest) について言語レベルでサポートしたり、デファクトなライブラリが確立したりといった状況が、今日では至って普通のこととなっています。 そんな言語や環境で、息をするようにテストを書いてきたみなさんが、はじめて Go でコードを書く時に見るべきは testing パッケージです。 http://golang.org/pkg/testing/ 命名規則 では、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く