テーマ： testing

• 変更をベンチマークする: ウォームアップ、繰り返し、ばらつき、何を報告すべきか

  タイミングの比較は、ノイズに埋もれずに残ったときだけ結果と呼べる。ワークロードを固定し、ウォームアップの実行を捨て、各バリアントの実行を多数回インターリーブし、データを見る前にどの統計量を使うか決め、すべての数値のそばにばらつきと実行環境を書き添える。実行ごとのばらつきより小さな差は、発見とは呼べない。

  methodology · ja · reviewed · 知識の基準日 2026-09-15

• 検証しながら小さなステップでリファクタリングする

  リファクタリングは、動作を変えずに構造を変える。ごく小さなステップで進め、各ステップの間でテストを成功させ、動作変更とは別のコミットにすれば、安全性とレビューのしやすさを保てる。

  methodology · ja · reviewed · 知識の基準日 2026-09-15

• Einen brauchbaren Fehlerbericht schreiben

  Ein Fehlerbericht ist brauchbar, wenn eine fremde Person den Fehler ohne Rückfrage nachstellen kann: eine präzise Überschrift, Umgebung mit Versionen, nummerierte Schritte zum Nachstellen, erwartetes und tatsächliches Ergebnis getrennt, die wörtliche Fehlermeldung und ein möglichst kleines Beispiel. Vermutungen zur Ursache stehen in einem eigenen Abschnitt.

  methodology · de · reviewed · 知識の基準日 2026-09-15

• ローカルDBのシードとフィクスチャ：小さく、冪等に、スキーマとともに版管理する

  全環境に必要な参照データ、開発・デモ用のサンプル、テスト自身が作るデータを分けます。自然キーで upsert する冪等なシードを作り、サンプルを小さく名前付きに保ち、セットアップと CI の両方でマイグレーション後に実行します。未加工の本番データを開発機に投入してはいけません。

  methodology · ja · reviewed · 知識の基準日 2026-09-17

• 生成した入力によるプロパティベーステスト

  手作業で選んだ例の代わりに、不変条件をテストとして記述し、ライブラリに多数の入力を生成させる。失敗した入力は最小の反例へ縮小される。Hypothesis は Python における参照実装である。

  methodology · ja · reviewed · 知識の基準日 2026-09-15

• 生成・批評・修正：自己検証ループがコストに見合う条件

  モデルが自分の出力を批評して修正するループは、批評に外部の手掛かり（テスト、バリデーター、出典）と固定した評価基準がある場合に結果を改善する。そうした裏付けがない場合には回答を悪化させ得ることが公表研究で示されており、各ラウンドでは少なくとも二回の呼び出しが増え、その入力は草稿とともに大きくなる。

  article · ja · reviewed · 知識の基準日 2026-09-16

• JUnit 5 と xUnit.net で単体テストを書く：注釈、ライフサイクル、パラメーター化ケースの比較

  JUnit Jupiter は @Test でテストを示し、既定では新しいインスタンス上の各テストの前後に @BeforeEach と @AfterEach を実行し、@ParameterizedTest とソース注釈でデータ駆動のケースを扱う。xUnit.net は [Fact]、コンストラクター、IDisposable で新しいインスタンス上のテストごとの準備と後始末を行い、[Theory] と [InlineData] でケースを、フィクスチャで高コストの共有コンテキストを扱う。両方で同じ形のテストを書くと、多言語チームの慣習をそろえられる。

  methodology · ja · reviewed · 知識の基準日 2026-09-16

• 継続的インテグレーションのパイプラインを設計する

  CI パイプラインは速く、自己テストを行い、どの変更にも同じ処理を適用する必要がある。クリーンなチェックアウトからビルドし、リンターとテストを段階的に実行し、失敗を明確に知らせる。全体の時間は、人が結果を待てる長さに保つ。

  methodology · ja · reviewed · 知識の基準日 2026-09-15

• 統合テストでコンテナ内の使い捨てデータベースを使う

  テストの実行ごとに、使い捨てコンテナで実際のデータベースエンジンを起動し、データをメモリー上に置きます。テンプレートデータベースに一度だけマイグレーションを適用し、テストファイルごとに複製します。テストはインメモリーの代替物ではなく、本物のプランナー、制約、分離の振る舞いを検証できます。

  methodology · ja · reviewed · 知識の基準日 2026-09-15

• Use property tests for parsers

  Express parser invariants over generated inputs and keep minimized failures as focused regression examples.

  methodology · en · reviewed · 知識の基準日 2026-09-21

• pass^k over repeated trials predicts production agent incidents better than pass@k

  Hypothesis: for agents deployed on repetitive tasks, the all-trials-pass rate (pass^k) on an evaluation set correlates more strongly with the rate of failed or escalated runs in production than the any-trial-pass rate (pass@k), because production gives each task one attempt.

  hypothesis · en · reviewed · 知識の基準日 2026-09-15

• 機械学習実験の再現性：シード、環境、データ、決定性の限界

  実験を再実行して同じ数値を得るには、固定した乱数状態を明示的に渡すこと、ライブラリのバージョンを固定すること、データセットと分割を特定することが必要になる。それでも GPU カーネルやライブラリのリリースにより結果が変わり得ると理解する必要がある。この手順は、可能な範囲で実行を繰り返せるようにし、不可能な部分を記録する。

  methodology · ja · reviewed · 知識の基準日 2026-09-17

• Red-teaming an agent workflow before it gets real permissions

  Attack the agent the way content and users will: indirect prompt injection through every input it reads, tool-argument manipulation, exfiltration through tool calls and budget exhaustion; run scripted probes plus manual attempts, record what the agent did, and fix the boundary, not only the prompt.

  methodology · en · reviewed · 知識の基準日 2026-09-15

• 本番の個人データを使わないテストデータ

  データを生成して、開発、CI、ステージングに現実的なデータを用意する。列を分類し、アプリケーションの検証を通るシード付き生成器を書き、generate_series で量を作り、本番からは分布だけを写す。生成レコードに見分けられる印を付け、本番ダンプという近道をなくす。

  methodology · ja · reviewed · 知識の基準日 2026-09-17

• How much test coverage is enough for a small service?

  Open question: for a service of a few thousand lines with a database and an HTTP API, what coverage level and test mix has been observed to keep defect rates acceptable without slowing change?

  question · en · reviewed · 知識の基準日 2026-09-15

• JSON Schema、検証、回数制限付き再試行による文書からの構造化抽出

  additionalProperties false の JSON Schema で対象レコードを定義し、モデルにその形だけを要求する。各応答を実際のバリデーターで検証し、エラーをプロンプトへ戻して上限付きで再試行する。それでも失敗するものは推測せず、人に回す。

  methodology · ja · reviewed · 知識の基準日 2026-09-15

• Reviewing code written by an AI agent

  A proposed review protocol for generated changes: compare the diff with the request, confirm every API and dependency exists, verify test claims by running and breaking the tests, read tests before implementation, hunt for swallowed errors, and record what was checked.

  methodology · en · reviewed · 知識の基準日 2026-09-15

• The test-driven development loop

  Write a failing test, make it pass with the simplest change, then refactor with the tests green; the loop keeps design decisions small and gives every line a reason to exist.

  methodology · en · reviewed · 知識の基準日 2026-09-15

• ブラウザーの E2E テストで安定したセレクターと自動待機を使う

  不安定なブラウザーテストの主因は、壊れたり別の要素を選んだりするセレクターと、タイミングを決め付ける固定待機です。ロール、ラベル、テスト ID で探し、各ロケーターを一つの要素に一致させ、時間ではなく再試行するアサーションと操作可能性の確認で同期します。

  methodology · ja · reviewed · 知識の基準日 2026-09-15

• 生存ミュータントに埋もれずにミューテーションテストを運用する

  一つのモジュールでツールを実行し、生き残ったミュータントを、アサーション不足、ケース不足、等価な変異に分類します。前の二つを直し、三つ目は除外します。差分や増分実行で時間を抑え、スコアは全体目標ではなく、モジュールごとに前回を下回らない基準として使います。

  methodology · ja · reviewed · 知識の基準日 2026-09-15

次のページ

機械可読： JSON