PHPerKaigi2025で「PHPUnit高速化テクニック」というテーマで登壇しました - テテマーチ Tech Blog
PHPerKaigi2025 こんにちは。 SINIS for X 開発チームのぴんくもひかん ( @pinkumohikan ) です。 2025年3月21日 ~ 3月23日に中野セントラルパークカンファレンスで開催された、PHPerKaigi 2025にて、「PHPUnit高速化テクニック」というテーマで登壇しました。 PHPerKaigiとは？ 登壇内容 最後に PHPerKaigiとは？ phperkaigi.jp PHPerKaigi（ペチパーカイギ）は、PHPer、つまり、現在PHPを使用している方、過去にPHPを使用していた方、これからPHPを使いたいと思っている方、そしてPHPが大好きな方たちが、技術的なノウハウとPHP愛を共有するためのイベントです。 PHPerKaigiは2018年から開催されているPHPエンジニア向けのテックカンファレンスです。PHPやWebシステム開
保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像 ～Software Design 2022年3月号「そろそろはじめるテスト駆動開発」より | gihyo.jp
保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像 ～Software Design 2022年3月号「そろそろはじめるテスト駆動開発」より 今回、Software Design 2022年3月号 第2特集「そろそろはじめるテスト駆動開発 JavaScriptでテストファーストに挑戦」の第1章「保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像」を本サイトに掲載します。第2章以降については、本誌『Software Design 2022年3月号』電子版（Gihyo Digital Publishing、Amazon Kindle）をご購読いただければ幸いです。 第1章では、混同されることの多い自動テスト関係の概念を、自動テスト、テストファースト、テスト駆動開発の3つの段階に分け、それぞれの効果や注意点を説明します。ソフ
StorybookとVitestではじめるフロントエンドのかんたん自動テスト - Mirrativ Tech Blog
こんにちは フロントエンドエンジニアの どじねこ です。 今回は Storybook 8.3 から追加された Vitest 統合機能を活用して、フロントエンドアプリの自動テストを強化した事例をご紹介します。 Storybook とは storybook.js.org Storybook は OSS として開発される UI コンポーネントワークショップです。 具体的には、フロントエンドアプリケーションの UI コンポーネントを開発する際の作業環境、ドキュメンテーションツール、テスティングフレームワークとして活用できる開発環境が提供されます。 React や Vue、Angular、Svelte、Web Component など幅広い環境に対応しており、うまく活用するとフロントエンドアプリケーションの開発をより柔軟に行えるようになります。 Storybook と Vitest の統合機能とは
テストカバレッジ100%を追求しても品質は高くならない理由と推奨されるカバレッジの目標値について - Qiita
皆さんは 「カバレッジが高ければ、ソースコードの品質が高い」という誤解 をしていませんか？少なくとも私は今までテストカバレッジ100%を追求していました。「C0/C1カバレッジ100%」がユニットテストの完了条件として含まれているプロジェクトも多いかと思います。 本稿では、「カバレッジが高ければ、ソースコードの品質が高い」という命題がなぜ誤っているのかを論理的に証明し、カバレッジを計測する本当の目的、そして推奨されるカバレッジの目標値について紹介したいと思います。 「カバレッジが高ければ、ソースコードの品質が高い」はなぜ間違っているのか？ カバレッジを計測する本当の目的 バグを潜在させてしまう恐怖のテストケース・アンチパターン カバレッジの目標値は100%にするべきではない カバレッジの目標値は何%にするべきなのか？ （テストカバレッジの種類については『ホワイトボックステストにおけるカバレ
テストを書く方針と原則の備忘録 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? こんにちは。サーバエンジニアのnsym-mです。普段はGoでバックエンドの開発などをしています。 最近テストに関する書籍や記事などを色々読み漁ったので、現時点での自分のテストについての考え方を備忘録として残しておきます。 今回の話はWebフロントエンドやiOS/Androidなどでも適用できる汎用的な考え方として記載していますが、ベースの文脈はバックエンド開発になりますのでそのつもりで読んでいただけますと幸いです なお、本記事では主にGoogle、『単体テストの考え方/使い方』、@t_wadaさんの発表されている考え方（いわゆる古典学派
単体テストの考え方/使い方を読んだ。読んでよかった。 - Mitsuyuki.Shiiba
読んでよかった book.mynavi.jp 評判通りよかった そっかーなるほどなぁ。面白いなぁ。と思うことがいろいろあった とはいえ、著者の主張全てに同意というわけではなく「著者はそう考えるんだな。自分は違う考えだな」と考えさせられる部分もいくつかあった 苦手な部分もあった 古典学派とロンドン学派に分けて話を展開しているのはあまり好きじゃないなと思いながら読んだ 定理やマトリクスに当てはめて話を展開する部分があって、いくつかは無理やりだったり話をややこしくしていたりするように自分は感じた。そういう部分は苦手だなぁと思いながら読んだ というのが全体の感想。内容はとてもよかったし、苦手な部分もそれはそれで考えさせられたので、読んでよかった。ってことでパラパラめくりながらメモを書いていこう あらためて意識したい2本 「第4章 良い単体テストを構成する4本の柱」の中の2本が、当たり前のことではあ
コードを書き始める前からテストをずっと考える ─ 継続的テストモデルとシフトレフトなテスト活動をアジャイルにどう取り入れるか - Agile Journey
読者の皆さんは、テストについてどのようなイメージをお持ちでしょうか。「開発の後に行う確認作業」といったイメージを持たれている方もいるかと思います。 しかし、開発しようとしているソフトウェアに不具合の混入を防ぐには、もっと早い段階でテストについて考えることが必要です。こういったテスト活動は、プログラムを1文字も書いていないときから始めることができるのです。 本記事では、2016年に提唱された継続的テストモデルを紹介しつつ、アジャイルとも親和性のあるシフトレフトなテスト活動について解説していきます。 DevOpsにおけるテストの考え方 DevOpsのループ図とは何か？ 継続的テストモデルとは何か 継続的テストモデルにおいてテストは「活動」である シフトレフトなテスト活動とシフトライトなテスト活動 シフトレフトなテスト活動としてのテスト駆動開発 コード実装を始める前から行うテスト活動 シフトレフ
ユニットテストってもう言わない！ CI/CD時代のテスト分類に最適なテストサイズという考え方
はじめに 以前からユニットテスト/単体テストという言葉は使いづらい、と感じており今回も旧Twitterで「テストを実行時間ベースで分類する良い言葉ないかなー」と呟いていたところ、「テストサイズのSMLって考え方があるよ」と教えて戴きました。 だいたいは教えてもらったt_wadaさんの記事にすべて書いてあるのですが、自分の整理も含めて動画にしたので、その補完記事となります。 TL;DR 単体テストのバベルの塔は既に崩壊 CI/CDでの継続的テストには時間ベースのテスト分類が重要 UT/IT/E2EではなくSMLによるテストサイズがCI/CDには合う それは単体テストか結合テストなのか？ 自動テスト、手動テストに関わらずテストの分類として単体テストと結合テストという言葉は一般的です。 ITQBではTest Levelsという言葉で定義されていますし、以下のようなV字モデルの対応表はみんな知って
テスト技法「同値分割」を信頼していいのかわからなくなった - 若くない何かの悩み
これまで同値分割を信頼できる手法だと信じてきました。最近になってどうして同値分割が信頼できる方法なのかその理由を私が説明できないことに気づきました。この原因は2つあります： 同値分割の分割の基準が不明確であること 後述するいくつかの仮定を満たさない場合、ある同値パーティションの代表値の出力が正しければその同値パーティションの他の値の出力も正しいといえる根拠に乏しいこと この2つから、不明確な基準の同値分割はその信頼性の説明ができないこと、同値テストは後述するいくつかの仮定が満たされたときのみ有効な手段でありいずれかの仮定が満たされない場合はさして信頼できないことが導かれます。 この記事ではこの結論に至るまでの過程について詳しく説明していきます。なお誤りのご指摘は大歓迎です。ぜひ皆さんで議論しましょう。 同値分割とは 後述する複数の文献の同値分割の説明に共通しているのは以下の2点です： 入力
CakePHP + MySQL アプリのテスト時間を 72% 削減した話
この記事は CakePHP Advent Calendar 2018 の23日目の記事です。 CakePHP アプリケーションのユニットテストでボトルネックになりがちなのがデータベースへのディスク I/O 時間ですが、そういったプロジェクトでは FriendsOfCake/fixturize プラグイン を導入すると大幅に高速化できる可能性があります。 GitHub – FriendsOfCake/fixturize: CakePHP3: Improve performance of your fixture based tests on MySQL. 実例として、テストに18分も掛かっていた MySQL を使ったプロジェクトありましたが、導入後なんと5分にまで短縮されました。（約 72% の高速化🎉） 結果として早いサイクルで CI を回せるようになり開発スピードも上がりました。 何が
APIテスト アーキテクチャ
テックリードとして2つのプロジェクトのテスト自動化を推進しています（本業）。 この記事では、プロジェクトでの経験を踏まえ、APIテストの位置づけ、システム上のスコープ、2つの方式について説明します。 この記事の目的 これから新規/既存WebシステムのAPIテストを自動化する人に向けて、APIテストの位置づけ・システム上のスコープ・2つの方式を紹介し、よりよいアーキテクチャを選択してもらうこと 想定読者 この記事は、テストピラミッドの考え方を採用し、以下のような方針でテスト自動化を進めることが前提です。 ユニットテスト、UIテスト、APIテストのように、粒度・観点の違うテストをバランスよく用いて、品質を効率的に担保する ユニットテストなどのより小さい粒度のテストで品質の大部分をカバーし、APIテスト、E2Eテストなどのより大きい粒度のテストをできる限り削減する 上記の前提を読んでも理解できな
yamlでテストシナリオを書いてそのまま実行までできるAPIテストツールの新星 “runn” を試してみた | DevelopersIO
yamlでテストシナリオを書いたらそのまま実行できる……そんな夢のようなシナリオテストツール"runn"の紹介とやってみた記録です これまでのシナリオテストツールに対する課題感 シナリオテストツールといえば、 Cucumber や Gauge といったツールが有名です。 ですが、これらのツールは「シナリオファイル」とは別に、シナリオを実行するためのコードも書かないといけません。しかも、そのコードではAPIを呼び出す処理を特定のプログラミング言語を使って書かなければなりません。その中には、HTTP Clientを実際に操作するような処理も含まれます。 私は「シナリオテストがしたい」のであって、「シナリオに沿ってAPI呼び出しを行う処理を書きたい」のではありません。こういった課題感を、ここ数年ずっと抱えてきました。 そんなとき、ついに見つけたツールが "runn" でした。 APIのシナリオテ
ソフトウェアテストは「バグを見つけるため」に行うものではない。実施した範囲内で、これ以上「バグが見つけられない」ことを証明するために行うもの。｜Takashi Suda / かんた
ソフトウェアテストは「バグを見つけるため」に行うものではない。実施した範囲内で、これ以上「バグが見つけられない」ことを証明するために行うもの。 この業界の方々でも、けっこー間違えて認識している人がいますよね。 まず「モノ作り」の基本大原則に触れておきましょう。それは、 「人間とは、完璧からは程遠い生き物である」 ということです。そのため、必ずバグ（不良、欠陥）は存在します。しないわけがないのです。もちろん運よく、たまたまバグが無いなんてこともありますが、少なくともその人が「今後も絶対にバグが無い」ことを100%保証するものにはなりえません。だって運よく、たまたまなんですから。再現性の欠片もありません。 そのため、JSTQB（ソフトウェアテスト技術者資格）認定の運営組織が定義している「ソフトウェアテストの原則をまとめたもの」として、 ソフトウェアの７原則 のなかでも、いの一番に取り上げられて
GPT-4にWebサイトを“自律的に”ハッキングさせる方法 AI自身が脆弱性を検出、成功率70％以上【研究紹介】
米UIUC（イリノイ大学アーバナ・シャンペーン校）に所属する研究者らが発表した論文「LLM Agents can Autonomously Hack Websites」は、大規模言語モデル（LLM）を用いたAIエージェントに、自律的にWebサイトをハッキングさせる攻撃手法を提案した研究報告である。LLMエージェントがWebサイトに存在する脆弱性を事前に知らなくても、自動検知してのハッキングが可能となる。 ▲自律型LLMエージェントを使ったWebサイトのハッキングの模式図 keyboard_arrow_down 研究内容 keyboard_arrow_down 研究結果 Webサイトを自律的にハッキングするようLLMエージェントを活用するには、エージェントのセットアップと、目標に向けてのプロンプトによる指示という2つのステップが必要である。エージェントによるハッキングでは、関数呼び出し、文書
moqを使ったGoのテスト
はじめに 本記事では matryer/moq というモックライブラリを利用したGoのテストのプラクティスについて紹介します。 moqはモック(狭義にはスパイ)・スタブの機能を持っており、その扱い方は非常にシンプルで直感的に扱えます。 その使い勝手に良さについて個人的にかなり気に入っており、実際にプロダクトのテストコードに利用しています。 一方で、moqはシンプルでユーティリティ的な側面が強いため、使い方を誤ると逆に管理しにくいテストコードになってしまいます。 本記事では『単体テストの考え方/使い方』という書籍を参考にしつつ、モック・スタブとしての役割に注意してmoqの使い方を提案してみます。 前提 いわゆるGoらしさの追求はこだわらない方針とします。具体的には、テーブル駆動は一旦忘れ、stretchr/testify を積極的に使うこととします。応用すればそうしないパターンでもいい感じに書
CakePHP Fixture Factories を導入しました - コネヒト開発者ブログ
こんにちは。プロダクト開発部の @su-kun1899 です。 今回はママリの CakePHP アプリケーションに Fixture Factories を導入した事例を紹介します。 Fixture Factories とは何か Fixture Factories は、モデルやデータベースに依存するテストコードにおいて、テーブルの作成やデータ初期化を行うためのプラグインです。 github.com CakePHP には元々 Fixture という仕組みが提供されていますが、 Fixture Factories はより柔軟に扱うことができます。 https://book.cakephp.org/4/en/development/testing.html#test-fixtures 導入したきっかけ アプリケーションの規模が大きくなり、機能が増えてくると、テーブル（モデル）ごとに一律データを管理
理想のフロントエンドテストをたずねて三千里 - カミナシ エンジニアブログ
こんにちは。カミナシにて業務委託としてフロントエンドを担当している田村(@junkboy0315)です。皆さんはフロントエンドのテスト、どのように取り組んでいますか？フロントのテストはなかなか難しいですよね。 バックエンドのテストには、「入力、出力、永続化されたデータ」の3つを検証するという基本セオリーがあります。しかし、フロントエンドのテストは、その粒度や手法が多様で、とっつきにくいと感じる方も多いのではないでしょうか。 カミナシでもフロントエンドのテストは以前は十分とは言えない状態でしたが、これまで継続的に改善を重ねてきました。今回は、その変遷についてお話ししようと思います。 夜明け前 カミナシのコードベースでは、元々ユニットテストがある程度整備されていました。これらは主に複雑な計算処理を行い結果を返す関数などに対して実施されていました。 しかし、画面全体の機能を網羅する包括的なテスト
フロントエンドの書くべきだったテスト、書かなくてよかったテスト
https://offers.connpass.com/event/299909/ 登壇資料
t_wadaさんと「単体テストの使い方/考え方」の疑問点についてディスカッションしました - DeNA Testing Blog
こんにちは、SWETグループの田熊です。 現在SWETグループでは書籍「単体テストの使い方/考え方」の輪読会を実施しています。 輪読会ではメンバー同士で活発に意見が交わされていますが、著者の主張に疑問を感じる箇所もあり、一度グループ外の方とも意見を交換したいと考えていました。 そこで、t_wadaさんをお招きし「単体テストの使い方/考え方」についてディスカッションする機会を設けました。 本記事では、SWETメンバーとt_wadaさんとのやりとりを紹介したいと思います。 ディスカッションの流れ ディスカッションは事前にSWETグループのメンバーが書籍を読んで疑問に感じたテーマを挙げてもらい、t_wadaさんの意見を聞くという流れで行いました。 今回は次のテーマについて話をしました。 「退行に対する保護」があるテストとはなにか 「リファクタリングへの耐性」のトレードオフはあるのか 統合テストの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
フロントエンドテストの育て方
