テスト技法「同値分割」を信頼していいのかわからなくなった - 若くない何かの悩み
これまで同値分割を信頼できる手法だと信じてきました。最近になってどうして同値分割が信頼できる方法なのかその理由を私が説明できないことに気づきました。この原因は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 / かんた｜note
ソフトウェアテストは「バグを見つけるため」に行うものではない。実施した範囲内で、これ以上「バグが見つけられない」ことを証明するために行うもの。 この業界の方々でも、けっこー間違えて認識している人がいますよね。 まず「モノ作り」の基本大原則に触れておきましょう。それは、 「人間とは、完璧からは程遠い生き物である」 ということです。そのため、必ずバグ（不良、欠陥）は存在します。しないわけがないのです。もちろん運よく、たまたまバグが無いなんてこともありますが、少なくともその人が「今後も絶対にバグが無い」ことを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さんの意見を聞くという流れで行いました。 今回は次のテーマについて話をしました。 「退行に対する保護」があるテストとはなにか 「リファクタリングへの耐性」のトレードオフはあるのか 統合テストの
フロントエンドのテスト構成について考えてみた in 2023
はじめに この記事では、 フロントエンドの開発において意義のあるテストはなにか？ それらをコスパよく実現するためにはどうすればよいか？ について考えて、作った構成を紹介します。 前提 下記の技術スタックを利用していますが、これ以外のスタックでも応用可能な仕組みが多いと思います。 Next.js Storybook playwright msw msw-snapshot （拙作） 注意事項 この記事の構成は、まだまだ実験的な機能だったり怪しい技術が一部採用されています。 msw-snapshot 拙作のライブラリであって、動作が怪しい可能性がめっちゃあります。 Next.js の testmode playwright + msw を実現するために必要でした。 まだまだ全然まともに動かないかもしれません。（サンプルリポジトリの単純なテストは動いた） サンプル 下記のリポジトリにサンプルを用意
テストケースの名前には条件と結果を含めた方が良い - 感情を込める
という考えにたどり着いたので、考えのスナップショットをとっておく。 Go言語における、テスト関数名とサブテストのname引数の値を「テストケースの名前」・「テスト名」と呼ぶことにしている。 (*testing.T).Run(name string, f func(t *testing.T)) bool テスト名に近いものとして、(*testing.T).Errorや(*testing.T).Logの引数がある。これらはテスト実行時の出力に含まれるが、テストケースを分かつものではない。あくまで、特定のテストケース内の情報を増やすものだ。対するテスト名は、（通常は）テストケースを分割できる最小単位である。 テストケースがテスト名の単位で存在するということは、テスト名はそのテストケースを十分に表現できていたほうがよいということだ。さもなくば、検証・変更しようとする仕様に対応するテストケースや、実
jest で非同期関数をテストするときの注意点
不適切な書き方をすると、落ちるべき(誤った)テストが通過する場合がある。 結論 コールバック テスト関数の引数にdoneを入れる コールバック関数内の最後でdone() する Promise Promise をreturnするか、async / await で扱う 異常系のテストでは、catch 句の外側に expect.assertions(n) / expect. hasAssertions() を書くか、expect(Promise).rejectsを使う リンク Testing Asynchronous Code · Jest jest - Necessary to use expect.assertions() if you're awaiting any async function calls? - Stack Overflow 問題 適切な書き方をしなかった場合、非同期処理
DBのリストアテストを全自動化した話 - Pepabo Tech Portal
ホスティング事業部の業務信頼性向上チームでエンジニアをしているはらちゃんです。 先日STREET FIGHTER 6のオープンベータに参加し、友人にボコボコに負けました。 製品版買っていい勝負ができるように特訓を重ねたいと思います。 今回、ホスティング事業部のサービスであるロリポップ、ムームードメイン、ヘテムル、おさいぽのDBリストアテストを自動化したので紹介します。 まず業務信頼性向上チームとは？ リストアテストを継続的にやっている理由 なぜ自動化したのか 全体像 具体的な実装 実装時に困ったこと dumpのサイズが大きすぎて通常のrunnerではリストアテストができない場合 scpをするアカウントにdumpファイルを操作する権限がない場合 dumpファイルのファイル名が微妙に違ってうまく指定できない場合 終わりに まず業務信頼性向上チームとは？ 最初に、自分の所属している業務信頼性向上
AIコードジェネレーターとTDDって親和性高くない、、、？ - Qiita
目的 先日、GitHub Copilotに関するオンラインセミナーを受けていたところ 「GitHub Copilotは、エディタ上で開かれているソースの内容も考慮してソースを推論する」という特徴を聞きました。 ふと、 「テストコードさえ書いたらその要件を満たすコードを勝手に生成してくれるのでは、、、？ なんて興味が湧いたので検証してみようと思います。 もし、期待通りになったらTDDが今後さらに熱を帯びるのではないでしょうか。 使用言語: python テストフレームワーク: pytest まずは簡単なコードで試す 関数名から推論されないように無機質な名前にしています。 class Functions: def function(a ,b): return a + b class TestClass: def test_function1(self): assert Functions.fu
自動テストはなぜうまくいかないか？乗り越えるためには何が必要か？ - Qiita
リファクタリングの鶏卵問題 ソースコードがクソなので綺麗にしたい。 リファクタリングしたい。 しかし、リファクタリングが出来ない。 リファクタリングが出来ないのは、テストが無いからだ。 よし。じゃあテストを書こう。あれ、テストが書けない？ そのようなテストが無く、書き換えられないことによる矛盾や憤りは皆さん何百回と感じてきたと思います。 しかし、この「テストが出来ない」ということを言語化するのは、非常に難しいと思います。それは、「テストが出来ない」には実は2つの視点があります。 本質的にテストが困難なモジュールで、誰がやってもテストが書けない。 本質的にモジュールはテスト可能だが、自分の実力が足りず、自分ではテストが書けない。 1.のようなテスト困難なモジュールは誰がやってもテストは書けないです。しかし、問題は、「テストを書きたい」と思ったとき、「自分がそれほどテストに詳しくない」という場
リファクタリングが先か、テストが先か - E2E自動テストの理想と現実 ｜Autifyブログ
2023年5月17日から5月19日にかけて開催された Qiita Conference 2023 にて、弊社の Senior Technical Support Engineer である末村 拓也が『リファクタリングが先か、テストが先か – E2E自動テストの理想と現実』というタイトルで講演を行いました。本記事はこのセッションを元に、ブログ向けに若干アレンジを加えたものとなります。 概略 この記事では、以下のような内容について説明します。 自動テストコードはアプリケーション本体のコードと 依存関係 を作る 一般的に、 不要な依存関係 を排除するのが良い設計と言える 一方で、E2Eテストは GUIに対して強い依存関係 を作る テストの準備などで GUIとの不要な依存関係 を作らないようにするのが重要 不要な依存関係を減らすために、テストレベル を一つ落とす（ユーザーストーリーE2E） 低いテ
Webフロントエンドのための実践「テスト」手法 CodeZine Night #1
CodeZine編集部主催のウェビナー「CodeZine Night」の第一回発表資料 https://codezine.connpass.com/event/279012
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
webフロントエンドテストと自動化
