AIエージェント時代に、テスト駆動開発（TDD）は「ガードレール」になる【t_wada×やっとむ対談】 - Agile Journey
生成AIを巡る状況は、わずか1年ほどで劇的に変化しました。Claude Codeなど実用的なコード生成エージェントが普及し、開発現場に大きなインパクトを与えつつあります。 とはいえ、「どのような場面で活用できるのか」「実際の開発で本当に役立つのか」といった疑問を抱えるチームも少なくありません。 そこで本稿では「生成AIによるコーディングとテスト駆動開発（TDD）」をメインテーマに、TDDの第一人者・和田卓人さん（@t_wada）と、アジャイルコーチのやっとむさん、こと安井力さん（@yattom）が対談。TDDの意義や、チームでAIを活用するための現実的な視点を掘り下げます。 AIをどう導入し、どう使いこなすか──実践的なヒントが詰まった対談です。 2025年7月時点のコード生成エージェントの現場感 AIが広げるテスト導入の可能性 生成AIが自動テスト導入のハードルを下げた 「As-Is」の
フロントエンドテストにおける知見の宝庫を発見！「javascript-testing-best-practices」
はじめに JavaScriptにおけるテストのベストプラクティスをまとめた「javascript-testing-best-practices」というGitHubレポジトリが大変勉強になったため、特に参考になった内容をまとめて共有したいと思います。 （補足）本レポジトリにはfrontendのみならずbackendのテストに関する情報もありますが、今回はfrontendに焦点を当てて共有します。そのため扱うSectionは以下の4つです。 Section 0: The Golden Rule Section 1: The Test Anatomy Section 3: Frontend Section 4: Measuring Tests Effectiveness 想定読者 フロントエンドの実装はできるが、テスト経験はない方 テストに対して解像度が低い方 これからテストを学びたいと思ってい
Common mistakes with React Testing Library の和訳 - Qiita
本記事は Kent C. Dodds氏による Common mistakes with React Testing Library の和訳です。 React Testing Library のよくある間違い こんにちは👋 私がReact Testing Libraryを作ったのは、当時のテストの状況に満足していなかったからです。 それが DOM Testing Library に発展し、今ではすべての人気のある JavaScript フレームワークと DOM を対象とした(そうでないものも含めて)テストツールのための実装(ラッパー)があります。 時間の経過とともに、私たちは API にいくつかの小さな変更を加え、最適ではないパターンを発見してきました。 私たちが提供するユーティリティを使用する「より良い方法」を文書化しようと努力しているにもかかわらず、私はいまだにこのような最適ではないパ
「北欧、暮らしの道具店」のメルマガをABテストで改善した話｜Kurashicom Tech Blog
こんにちは。デザイナーの白木です。 前回はクラシコムのUXリサーチについてお話しましたが、今回は「北欧、暮らしの道具店」のメルマガをABテストの手法を使って改善した話をしたいと思います。 「北欧、暮らしの道具店」通常のメルマガは商品紹介がメインですが、それとは別に当店のアプリを紹介するメルマガも配信しています。 これまではメルマガ登録者全員に配信していたのですが、その中にはアプリをすでにご利用いただいている方も多くいらっしゃるため、アプリのダウンロードには繋がりにくいという課題がありました。 そこでアプリ紹介メルマガを配信する対象をメルマガの新規登録者に絞ることにしました。新規登録者は当店を知って間もない方が多いと思われるため、アプリについて知ってもらえる良い機会になると考えたからです。 内容も見直し、いくつかのパターンを配信して効果を検証してみました。 ※本来同じ期間に複数のパターンをテ
GitHub - rakyll/hey: HTTP load generator, ApacheBench (ab) replacement
Usage: hey [options...] <url> Options: -n Number of requests to run. Default is 200. -c Number of workers to run concurrently. Total number of requests cannot be smaller than the concurrency level. Default is 50. -q Rate limit, in queries per second (QPS) per worker. Default is no rate limit. -z Duration of application to send requests. When duration is reached, application stops and exits. If dur
リーダブルなテストのための、jest モックファクトリー関数
単体テストを書く時、モジュール間の関連を検証するため、一部のモジュールをモックする必要が出てくることがあります。モックは様々な手法がありますが、書き方によって、メンテナンス性やテストの可読性が変わります。一般的に行われるモック手法を確認しつつ、よりリーダブルなテストを書く方法を紹介します。 ログイン API を呼び出す Web API クライアント 今回紹介する、モック対象の Web API クライアントです。Native Fetch API を関数でラップした、自作の Web API クライアント（ログインするためのlogin関数）です。 export type Data = { redirectUrl: string; }; export type Input = { email: string; password: string; }; export async function l
実装例から見る React のテストの書き方 - Cybozu Inside Out | サイボウズエンジニアのブログ
2024/04/17: 更新 内容を更新した記事を書きましたので、よかったらこちらも併せて、ご覧ください。 zenn.dev こんにちは！フロントエンドエキスパートチームの@nus3_です。 kintone のフロントエンド刷新プロジェクト（フロリア）では、品質を保ったまま開発を加速させるためにフロントエンドのテストを積極的に行っています。 今回はそんなフロントエンドのテストの実装例をいくつか紹介します。この記事がフロントエンドのテストを行う上での参考になれば幸いです。 テストに使用する主なパッケージ コンポーネントのテスト 補足: Testing Library の記法をチェックしてくれるeslint-plugin-testing-library カスタムフックのテスト 補足: React v18 では @testing-library/react の renderHook を使う 参考
【初心者向け】テストコードの方針を考える（何をテストすべきか？どんなテストを書くべきか？） - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 「テストコードを書きましょう」とはよく言われるし、テストコードが大事だってことも理解できるんだけど、何をテストしたらいいの？どんなテストを書いたらいいの？と迷っている初心者プログラマさんは意外と多いのではないでしょうか？ そんな方たちに向けて、この記事では僕が普段意識しているテストコードの方針を紹介します。 おことわり 本来であれば具体的なコード例も豊富に入れたいところなのですが、かなり時間がかかってしまうので、いったん文章メインで記事を公開します。 もしかすると、そのうちコード例も一緒に盛り込んだ「リッチバージョン」を公開す
リーダブルテストコード / #vstat
「リーダブルなテストコードについて考えよう ～VeriServe Test Automation Talk No.3～」で使用したスライドです。 https://veriserve-event.connpass.com/event/243280/ 登壇動画はこちらで公開されています。 http…
モック関数 · Jest
モック関数によりコード間の繋がりをテストすることができます。 関数が持つ実際の実装を除去したり、関数の呼び出し（また、呼び出しに渡されたパラメータも含め）をキャプチャしたり、new によるコンストラクタ関数のインスタンス化をキャプチャできます。 そうすることでテスト時のみの返り値の設定をすることが可能になります。 関数をモックするには、次の2つの方法があります。 1つは、テストコードの中でモック関数を作成するという方法。 もう1つは、manual mockを作成してモジュールの依存性を上書きするという方法です。 モック関数を利用する forEach 関数の実装をテストすることを考えてみましょう。 この関数は、与えられた配列の各要素に対して、コールバック関数を呼び出します。
Tests as Documentation - たにしきんぐダム
production code の設計についてはよく議論される一方、ユニットテストをどう書くべきかについてはあまり議論されることが少なく。とにかくカバレッジが高ければヨシみたいな感じで軽く扱われていることが多い気がする。 その結果、テストを書くときやとりわけテストを追加するときに "良くない" 方法でテストを追加/拡張してしまい、メンテナンスしにくく壊れやすい・(未来の自分でも)読んでも何を検証しているのか分からない、テストが落ちても不安だけを煽り何が問題なのか分からない、技術的負債が誕生してしまう。 詳しいことは本 ( XUnit Test Patterns など? 詳しい人は僕に紹介してください)を読んだりチームメンバーと議論するのが良いと思うが、この記事を読んでテストの書き方に対する意識を啓発できたらなと思っている。 理想を述べるのは簡単だけど現実は大変、頑張ろう introduct
PlaywrightでフロントエンドのE2Eテストを自動化してみた話
TL;DR Playwrightは導入コストが高くはない ひとまずスクリーンショットを全ページ撮るだけでも、QAの工数（もしくは自分の確認する時間）を削減できた 意外とやってみると書ける playwright-cliのコード自動生成が非常に便利！ きっかけ プロジェクトでPlaywrightのフロントエンドのE2Eテストを書かせていただく機会がありました。 導入〜テストケース作成〜実装までやらせていただいて、知見がある程度溜まったので まとめてみることにしました。 至らぬ点もあるかと思いますが、その際はご指摘いただけますと幸いです。 ざっくりブラウザテストのこれまで 参考：https://blog.logrocket.com/playwright-vs-puppeteer/ Selenium ブラウザテストの自動化自体は新しい技術ではなく、2004年ごろからSeleniumがあった しかし
フロントエンドのテストのモックには msw を使うのが最近の流行りらしい
皆様フロントエンドのテストを書いていらっしゃいますでしょうか？ フロントエンドのテストを書くときには API コールする処理を全てモックする必要があります。外部の API をコールする処理をテストに含めると API サーバーが落ちているなどの外部の要因によってテストが失敗してしまう可能性がありますし、テストを実行するたびに実際に API をコールしてしまうとサーバーに負荷がかかってしまうなど外部に対しても悪影響を与えてしまいます。 さて、従来のモックする手段としては Jest のモックを利用して axios や fetch などのモジュールをモック化する手法がよく使われていたかと思います。 最近のテスト手法として API コールをモックする際に Jest ではなく Mock Service Worker (以下 msw ）を使用する手法が注目されています。実施にどのように使用されているのか
Cypress Component Test Runner を Vite & React で試す
Cypress Component Test Runner Cypress 7.0.0 より、 2021/04/10 時点ではまだ Alpha 段階ですが Cypress Component Test Runner という機能が追加されました。（@sekikazu01 さんのツイートで知りました。） E2E テストのようにブラウザ上で実際にレンダリングしつつ、コンポーネントテストのような軽快さで動くという、中間的な位置付けと捉えています。 試してみる (Vite) create-react-app や vue-cli を使ったチュートリアルが用意されているので、とりあえず確認してみたい場合はそちらが良さそうでした。 ドキュメントも存在しており、webpack-dev-server を利用する場合はそちらが参考になりそう。 ただ、そのままやってもテンションが上がらないので、紹介記事には As
Testing JavaScript with Kent C. Dodds
Learn the smart, efficient way to test any JavaScript application.YOUR ESSENTIAL GUIDE TO FLAWLESS TESTING Why bother testing your JavaScript? When a user encounters a bug they look like this: 🤬 Bugs grind work to a halt. Bugs cause financial harm. Every single time a bug is encountered, user trust erodes. Bugs are bad. And who gets blamed? You. The developer. You know you should squash bugs befo
Corner case - Wikipedia
This article needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. Find sources: "Corner case" – news · newspapers · books · scholar · JSTOR (August 2019) (Learn how and when to remove this message) In engineering, a corner case (or pathological case) involves a problem or situation t
Test pages of HTTP Status code
Test page of HTTP Status code Abstract When testing/developing a software, you may need a Web server that returns particular HTTP status code in HTTP header. This site provides any HTTP status codes for testing. How to use Just access below URL: http://ozuma.sakura.ne.jp/httpstatus/[http_status_code] fill in [http_status_code] with HTTP status code you need. For example, http://ozuma.sakura.ne.jp/
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Testing Playground
なぜテストを書くの？（または書かないの？） 〜テストコードの7つの役割〜 / #tamarubykaigi01
GitHub - testing-library/react-hooks-testing-library: 🐏 Simple and complete React hooks testing utilities that encourage good testing practices.
