数を増やしても一貫性を保つ、runn の API テスト構成設計 - カミナシ エンジニアブログ

こんにちは、ソフトウェアエンジニアの渡邉（匠）です。 「カミナシ 設備保全」の開発に携わっています。 以前、「40,000行のAPIテスト作成で学んだClaude Code Skillsの育て方」という記事を書きました。 AI を使って大量の API テストを生成した話です。 今回はその土台になっている、テストそのものの構成を紹介します。 私たちのバックエンドの API テストは、数十のAPIを対象に、200 本を超えるファイル、1,000 件を超えるテストケースまで育ちました。 本記事の主題は、テストフレームワーク runn で書いた runbook の設計、なかでも「何を確かめるか」と「どう呼ぶか」を分ける部品化です。 まず土台となる、runn を go test に埋め込む実行基盤を紹介した上で、本題の runbook 設計に入ります。 runn を go test に組み込む ru

[mkusaka]

runnをgo testに統合し、RunMatchやRUNN_RUNで絞り込み実行。req/db/mockを部品化して一貫性を保つAPIテスト設計。

[nguyen-oi]

YAMLでの疑似型チェックや役割別の徹底したファイル分割が凄く実践的。AI自動生成の土台としても規約の重要性が伝わる

[k1LoW]

使い倒しありがとうございます！綺麗に構成されていてrunnの機能を最大限（120%）使っていただいているケースだ。

[toricls]

runn、いつもお世話になっております🙏