AIと進めるテスト設計・リファクタリングの実践
以前作成した冷蔵庫マネージャー、レビューとリファクタリングをしようしようと思いながら後回しになっていたのですが、つい先日参加したイベントでAIとのリファクタリングのコツを教えてもらったので、教えてもらったことをもとにやってみることにしました。 前提（例：あなたは〜です） 目的（例：これから〜を実装します） 前準備（例：まず〜を把握してください） タスク（例：調査結果をマークダウンファイルにしてください） 制約（例：コードの変更を禁止する など） これを意識してリファクタリングをしていきます。 ちなみに今回もCursorとペアプロ形式で進めています。 1. ドキュメントを作る 生成されたコードを何の情報もなく読んでいくのは根気がいります。ということで、まずは構成とかパッケージをドキュメントに起こしてもらいます。 これをすることでCursorでチャットを新しくした場合でも「これも参照してね」で
【Claude】Playwright-MCPで変わるテスト自動化の世界！初心者でも使えるE2Eテスト入門 - Qiita
はじめに 私は新米プログラマーとして、テスト自動化の複雑さに頭を悩ませていたんですが、Playwright MCPと出会って目から鱗が落ちる体験をしました。今日はその魅力を皆さんと共有したいと思います！ テスト自動化の悩みから解放されるPlaywright MCP アプリ開発をしていると、「ユーザーが実際に使うときにちゃんと動くかな？」という不安がつきまといますよね。エンドツーエンドテスト（E2Eテスト）は、UIからAPIまで全体の流れをテストできる素晴らしい方法なんですが、正直言って、従来のやり方はめちゃくちゃ大変でした。 複雑なコードを書いたり、テストシナリオを考えたり...。特に私のような新米プログラマーにとっては、高い壁だったんです。でも、Playwright MCPの登場で、この状況が劇的に変わりました！ Playwright MCPの最大の魅力は、自然な日本語のコマンドでブラウ
Playwright MCPとCursorで、E2Eテストを自動生成してみた 〜AI×ブラウザ操作の新アプローチ〜
概要 Playwright MCPとCursorを活用し、E2Eテストをゼロから自動生成してみました。 本記事ではその検証プロセスと得られた知見を紹介します。 この記事で分かること Playwright MCPでE2Eテストを自動生成する方法 Playwright MCPの活用のヒント はじめに 昨今のMCPブームは収まることを知らず、日々新しいMCP Serverが公開されています。 そんな中、自動化テストツールとして有名なPlaywrightのMCP Serverが公開されました。 Playwrightには、既にユーザーがブラウザを操作しテストを生成できる非常に便利な機能がありますが、今回はそれを超えるために、ユーザーの代わりにCursor（MCP Client）を使用し、ブラウザの自動操作とE2Eテストの自動生成を行えるのかを検証しました。 検証環境 Cursor: claude-s
Microsoft Playwright MCPが切り拓くLLMとブラウザの新たな統合
はじめに ウェブブラウザの自動操作は長い間、テスト自動化やスクレイピングの重要な分野でしたが、大規模言語モデル（LLM）の台頭により、まったく新しい可能性が開かれつつあります。マイクロソフトの最新プロジェクト「Playwright MCP（Model Context Protocol）」は、LLMとブラウザの間に革新的な橋を架け、AIがより効率的かつ確実にウェブと対話できる世界を実現しています。 本記事では、Playwright MCPの技術概要、主要機能、そして実際のビジネスにおける活用事例について探っていきます。 Playwright MCPとは？ Playwright MCPは、マイクロソフトが開発したModel Context Protocol（MCP）サーバーで、Playwrightのブラウザ自動化機能をLLMに提供します。従来の画像認識やスクリーンショットベースのアプローチとは
Wallaby.jsを使ってフロントエンド開発のテストを効率化しよう - Findy Tech Blog
Findy Team+でフロントエンドエンジニアをしている 川村(@peijun333)です。 Findy では、フロントエンドのコード品質と安定性を確保するために Jest などのテストフレームワークを積極的に活用しています。通常、Jest は CLI から実行してテスト結果をコンソールで確認しますが、コマンドを用意する手間や、テスト経過のデバッグのために都度 console.log などでその内容を確認しなければならずとても不便です。 そこで、今回はテストの自動化とリアルタイムなフィードバックを提供する JavaScript の統合テストツールである Wallaby.js を紹介します。Wallaby.js を導入することで、開発効率の向上が期待できます。 Wallaby.js とは？ 前提条件 VS Code でテストの修正 Wallaby.js はリファクタリングに強い スナップシ
E2Eテストを Playwright で作り直して開発プロセスに組み込む話 - SmartHR Tech Blog
こんにちは。SmartHR プロダクトエンジニアの sasaki (@s_sasaki_0529) です。 今回は、私が開発に携わっている届出書類機能における E2E テストを、Capybara + Selenium の構成から Playwright に移行し、開発プロセスに組み込んだお話をします。 扱う話題 E2Eテスト基盤を移行する具体的な背景と理由 移行における提案から、合意形成までの流れ 移行後の開発プロセスがどう変わったか 扱わない話題 Playwright など、記事内で扱う技術要素自体の詳細説明 移行作業自体の詳細 テストコードの設計・実装に関する具体的なテクニック なお、本記事では便宜上、移行前の E2E テストを「旧テスト基盤」移行後を「新テスト基盤」と呼称します。 届出書類機能について E2Eテストに限らず、テストというのはプロダクトの特性によって最適な手法は大きく変わ
ソフトウェアテスト読書マップ
このブラウザ バージョンのサポートは終了しました。サポートされているブラウザにアップグレードしてください。
有志と #ソフトウェアテスト読書マップ を作りました！ - ソフトウェアの品質を学びまくる
2022年9月9日にこんなツイートをしたところ、 ソフトウェアテストの書籍・資料について、こういうマップを作ってみたい。「QA関連」でできるといいんだけど、縦軸が定まらない。 一番繰り返し読んでいるドリル本をサンプルにしてみたけど、テスト分析自体がすでに初級じゃない気もするから、色付けも難しい。うーん。 誰か一緒にやりません？ｗ pic.twitter.com/R0lVJhcpkD— Kazu SUZUKI (@kz_suzuki) 2022年9月9日 「一緒にやってもいいよ～」っていう方々に声をかけていただき、1週間あまりでみるみるできあがっていきました！ みなさんの機動力高すぎて、わたしの寄与は「声をかけて最初のフォーマットを作った」くらいになってしまいましたよ。 ということで、以下に公開します！ docs.google.com 「閲覧者（コメント可）」というアクセス権を設定しています
ローコードテスト自動化ツールの mabl がすごい
というのを使っていて思ったのでレポを書いていきます。 mabl とは - 基本的な機能 ざっくり言うと E2E テストをお手軽にメンテできるツールです。 こんな感じでポチポチ画面を操作していくと、それで実行したアクション(ボタンやリンクをクリックするなど)を自動で記録してくれて、E2E のテストを作成することが出来ます。 コードを書かずに E2E テストをサクッと作れちゃうのが魅力な訳ですが、それだけではありません。そんなすごいところを紹介していこうと思います。 mabl のここがすごい Auto Healing 何やら回復魔法みたいな感じでかっこいいですが、何かというと E2E テストがコケるようになった時に自動で修復してくれる機能です。 例えばボタンの位置が変わってしまっても、同じ文脈であろうボタンを自動で探して修復したりしてくれます。 E2E での辛さといえば、やはりテストのメンテナ
テストの説明に安易に「正しく」とか書かない - Object.create(null)
みなさんテストは書いていますよね. 書いていなければふりだしに戻る. 例えば関数 add に対して, 以下のようなテストコードがあるとします. describe("add", () => { it("正しく計算できる", () => { expect(add(1, 2)).toBe(3); }); }); よさそうですね? もしよくないと思うのであればここから下は読まなくても大丈夫なくらい理解している方だと思います. 続いて関数名を変えただけのこちらをどうぞ. describe("sub", () => { it("正しく計算できる", () => { expect(sub(1, 2)).toBe(3); }); }); なんだか明らかに間違っている気がします. もしこのテストが通過してしまったとき我々はどうすればよいのでしょうか. 考えられるパターンは 2 つあります. 実装もテストも正
Excelなテスト仕様書をMarkdown/GitHub/CircleCIに移行した話 - トレタ開発者ブログ
こんにちは、QAエンジニアの井上恵一です。好きな飲み物は一番搾りと韃靼そば茶です。 初回からニッチなネタではありますが、昨年入社した直後に行った、 iPad アプリのテスト仕様書の管理方法を見直したときの話を紹介しようと思います。 見直しのきっかけ トレタは飲食店向けの予約/顧客台帳アプリです。だれでもかんたんに使いこなせるシンプルさを追求してはいますが、製品の進化に伴ってそのテストケース数はすでに数千という単位にまで膨れあがっています。 製品の品質を安定させるためには、テストの内容自体をブラッシュアップすることが重要なのは言うまでもありません。ただ、安定した製品を永続的に提供していくためには、それに加えて、膨大なテストケースを効率よくメンテナンスし続けるためのプロセス作りも欠かせません。 入社のタイミングでトレタのテスト設計を担当することになったので、テストケースの管理方法についてもいち
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
フロントエンドテストの育て方