https://roboco.io/ja/tags/testing/ Recent content in Testing on ROBOCO Hugo ja Sat, 10 Oct 2026 10:00:00 +0900 https://roboco.io/ja/posts/software-factory-evidence-before-fix/ Sat, 10 Oct 2026 10:00:00 +0900 https://roboco.io/ja/posts/software-factory-evidence-before-fix/ <blockquote> <p>「<code>USE_SYSTEM_BUN=1</code>で通るテストは有効ではない（Your test is NOT VALID if it passes with <code>USE_SYSTEM_BUN=1</code>）」 – Bun <code>CLAUDE.md</code><sup id="fnref:1"><a href="#fn:1" class="footnote-ref" role="doc-noteref">1</a></sup></p> </blockquote> <figure><img src="https://roboco.io/posts/images/Dohyun.png"><figcaption> <h4>チョン・ドヒョン - ROBOCO首席コンサルタント</h4> </figcaption> </figure> <hr> <p>この記事は、4回シリーズ「オープンソースプロジェクトから学ぶソフトウェアファクトリーのベストプラクティス」の第3回です。</p> <p><strong>シリーズの構成</strong></p> <ol> <li><a href="https://roboco.io/ja/posts/software-factory-best-practices-from-open-source/">判定基準と12のリポジトリ：何をファクトリーと呼び、どこで動いているのか</a></li> <li><a href="https://roboco.io/ja/posts/software-factory-who-merges/">誰がマージするのか：リスクに基づく委任と権限構造</a></li> <li>証拠でふるいにかけるファクトリー：「修正前には失敗する」ことの証明（本記事）</li> <li><a href="https://roboco.io/ja/posts/software-factory-failures-into-rules/">失敗をルールに：自己改善ループとその限界</a></li> </ol> <p>冒頭の引用は、Bunリポジトリのエージェント向け指示にある一文です。<code>USE_SYSTEM_BUN=1</code>は、修正する前の既存のBunリリースでテストを実行させる設定です。つまりこのルールは、「修正前のコードでも通るテストは何も証明しない」という意味です。</p> <p><a href="https://roboco.io/ja/posts/software-factory-who-merges/">第2回</a>では、マージ権限を誰に与えるかよりも、マージ前に何が確認されるよう強制するかが重要だとまとめました。<sup id="fnref:2"><a href="#fn:2" class="footnote-ref" role="doc-noteref">2</a></sup> 今回はその確認の中身を扱います。エージェントはコードを素早く書きますが、常に通る無意味なテストや、実際より誇張した作業報告も簡単に作ります。そしてBunのエージェント<code>robobun</code>が2026年9月の1か月間に作成したPRは2,313件です。<sup id="fnref:3"><a href="#fn:3" class="footnote-ref" role="doc-noteref">3</a></sup> この規模では、人がすべてのdiffを読むことはできません。そこでファクトリーは、人がコードを読む前にまず<strong>証拠</strong>を見るようにしています。数値はこれまでの回と同じく、2026年10月10日にGitHub APIで取得した値です。</p> <h2 id="tldr">TL;DR</h2> <ul> <li>観察した事例をまとめると、ファクトリーが求める証拠は三層です。問題が実際に存在することを示す再現、修正前には失敗し修正後には通るテスト、そして単体テストを超えた実際の動作の証拠です。</li> <li>そのうち3つのプロジェクトがそれぞれ異なる方法で実装した仕組みが、「修正前の失敗」の証明です。BunはPR本文に修正前の失敗ログを添付し、mastraはCIが新しいテストを修正前のコードに対して実行して失敗するかを確認し、観察したVercel AI SDKの修正PRは再現 → 失敗するテスト → 修正の順にコミットを積み上げていました。</li> <li>証拠は回避されることがあります。mastraでは修正前失敗ゲートの失敗ラベルが付いたままマージされたPRがあり、Astroでは「動作する」と確認された修正が意図と異なっていたため差し戻されました。証拠の仕組みは、マージ条件と結びついたとき、そして意図まで確認したときに効力を持つと私は考えています。</li> </ul> <hr> <h2 id="1-三層の証拠">1. 三層の証拠</h2> <p>観察したプロジェクトがエージェントに求める証拠を私の基準でまとめると、3種類になります。</p> <table> <thead> <tr> <th>証拠の種類</th> <th>問いかける質問</th> <th>代表的な仕組み</th> </tr> </thead> <tbody> <tr> <td>再現</td> <td>問題は実際に存在するか</td> <td>Vercel AI SDKの再現PR、Astroの再現ステップ</td> </tr> <tr> <td>修正前の失敗</td> <td>このテストは本当にその問題を捉えるか</td> <td>Bunの証拠ブロック、mastraの修正前コードテストゲート、Vercel AI SDKのコミット順序</td> </tr> <tr> <td>実際の動作</td> <td>単体テストの外でも動作するか</td> <td>OpenClawの動作証拠ラベル、OpenHandsのライブE2E、Astroのプレビューリリース</td> </tr> </tbody> </table> <p>私は、この三層が順番に積み重なるものだと考えています。再現がなければ何を直したのかがわからず、修正前の失敗がなければテストが何を証明しているのかがわかりません。そして、単体テストが通っても実際の環境では壊れることがある、というのが三層目が必要な理由です。</p> <hr> <h2 id="2-まず再現する">2. まず再現する</h2> <p>Vercel AI SDKのファクトリーは、バグのIssueを受け取るとまず再現を試みます。再現に成功すると、サンプルファイルと再現記録ファイル（<code>reproduction-replay.json</code>）を含むドラフトPRを作成します。観察したIssue #22412の再現PRは、確認後にクローズされました。<sup id="fnref:4"><a href="#fn:4" class="footnote-ref" role="doc-noteref">4</a></sup> 再現結果はラベルとして残ります。<code>task-bug-reproduction-success</code>、<code>-cannot-reproduce</code>、<code>-issue-invalid</code>、<code>-out-of-scope</code>といったラベルがあり、サポートしているバージョン（v5、v6）ごとに結果を個別に記録します。<sup id="fnref:5"><a href="#fn:5" class="footnote-ref" role="doc-noteref">5</a></sup> この結果によって次のステップが分岐するように見えますが、ファクトリーの内部ルールはリポジトリの外にあるため、確認できませんでした。</p> <p>Astroのファクトリーは、再現 → 診断 → 意図の検証 → 修正の順に作業します。各ステップには止まるためのルールがあります。再現用サーバーの起動に2回失敗すると、あきらめてレポートを書きます。診断の確信度が低ければ、そこで止まります。意図の検証ステップで「意図された動作」と判定すると、修正しません。<sup id="fnref:6"><a href="#fn:6" class="footnote-ref" role="doc-noteref">6</a></sup> 確信度が低いときには、コードを直す代わりに失敗するテストと<code>// TRIAGE:</code>コメントだけを残す経路もあります。人が引き継げるように、手がかりだけを残すのです。</p>