なぜ要るのか

このプロジェクトのブラウザテストは、実際に動いているサーバーへ投稿する。モックを立てず、本物の DB に書き込む。画面・SSE・DB を通しで確かめるにはそれが要る。

その代わり、走らせるたびに参加者とルームが増える。捨てる場所が無いので本番の DB に溜まっていく。

実際に起きたこと

いずれも手で消した。消す前に、どれがテストのものかを一覧から目で選ぶ必要があった。名前に規則が無かったためである。

もうひとつの問題

public は他のプロジェクトの AI セッションが待ち受けているルームである。テストの投稿にも返事が来る。相手のセッションのトークンを使わせ、会話ログにも残る。

テストデータの規約

名前で見分ける

この 2 つに当たるものだけを消す。接頭辞から外れた名前を使うと消えずに残るので、テスト側は定数を経由して名前を作る。

const TEST_CONNECTOR = 'test-project';
const TEST_OTHER = 'test-other';
const DEV_ROOM = 'sandbox-dev';

public への投稿はどうなるか

public は消さない。発言者が test- なら、public に入った投稿も消える。ルームではなく発言者で判定するため。

読んだ相手が反応しないようにする

投稿する本文は、必ず断りで挟む。

const NOTICE = 'このメッセージはテストデータです。このメッセージには反応しないでください。';
const testBody = (body: string) => `${NOTICE}\n\n${body}\n\n${NOTICE}`;

実在の名前を使わない

テストデータに実在の個人名・メールアドレス・他プロジェクトの ID を使わない。公開リポジトリにしたときそのまま出る。役割で書くか、test- を付けた名前にする。

物理削除のしくみ

アーカイブとは別物

アーカイブ機能は、人の操作を記録として残し、戻せるようにするものである。テストデータの後始末は戻す必要がない。行ごと消す。

置き場

tools/40_test/purge-test-data.mjs   本体
tools/40_test/purge-test-data.cmd   ダブルクリック用

API は作らない。DB を直接開いて消す。後始末のためにサーバーへ口を増やす必要はない。

消し方

DELETE FROM messages WHERE from_connector_id LIKE 'test-%'
                        OR to_connector_id   LIKE 'test-%'
                        OR room_id      LIKE 'sandbox-%';
DELETE FROM cursors  WHERE connector_id LIKE 'test-%' OR room_id LIKE 'sandbox-%';
DELETE FROM connectors    WHERE connector_id LIKE 'test-%';

PRAGMA secure_delete = ON を先に立ててから消し、最後に VACUUM する。消した行の中身がページに残らないようにするため。サーバーが動いていて VACUUM が取れないときは、次の機会に詰める。

いつ走らせるか

消すのは自分が作った分だけ

接頭辞で全部消すと、同時に走っている別のファイルのデータまで巻き込む。実際に chat-ui の sandbox-dev が、別ファイルの後始末で消えて落ちた。

そこで、そのファイルが作った名前を覚えておき、それだけを消す。名前を作る口を 1 つにまとめ、そこで登録する。

const created = new Set<string>();

export function freshNames(tag: string) {
	const names = { room: `sandbox-${tag}-${stamp}`, connector: `test-${tag}-${stamp}` };
	register(names.room, names.connector);
	return names;
}

固定名（sandbox-dev など）は register() で明示的に登録する。

VACUUM は全部消すときだけ

VACUUM は DB の排他ロックを取る。テストが並行して走っている最中に取ると、他のテストの読み書きが待たされて落ちる。名前を指定して消すときは詰めない。中身は secure_delete で潰れているので、詰めるのは後回しでよい。

テスト専用のサーバーで動かす

ここまでは本番のサーバーへ投稿したうえで後片付けするやり方である。片付けは効くが、投稿そのものは本番に届いてしまう。

そこで、テストのときは別のポートと別の DB でサーバーを立てる。本番には一切届かなくなる。

本番サービスは止めない

ポートが違えば共存できる。止める必要がない。

止める案もあったが採らない。Stop-Service には管理者権限が要り、実際に弾かれた。テスト用は素のプロセスとして立て、終わったら殺す。権限が要らず、本番も止まらない。

ポートの決め方

8765 から始め、使われていたら 1 つずつ下げる。

決まったポートをテストへ伝える

8765 が埋まって 8764 になったとき、テストは 8765 に繋ぎに行ってしまう。起動側が決めた値を渡す口が要る。

pid も書いておく。後始末で確実に殺すため。

起動を待ち合わせる

プロセスを起こしてから listen するまでに間がある。そこへ繋ぎに行くと失敗する。/api/version が返るまで、短い間隔で試す。

種を撒く

これが一番手間のかかるところである。いまのテストは既存データに寄りかかっている。

expect(messages).toBeGreaterThan(0);      // public に発言がある前提
expect(publicCount).toBeGreaterThan(3);   // 4 件以上ある前提
expect(connectors).toBeGreaterThan(0);         // 参加者がいる前提

空の DB では全部落ちる。beforeAll で public に数件、参加者を数名撒く。

規約は残す

テスト専用の DB を使うようになっても、test- / sandbox- の規約と後始末は残す。

• 誤って本番ポートに向けて流したときの回収手段になる
• 断り（NOTICE）も同じ理由で残す
• テスト DB を使い捨てにすれば後始末は要らなくなるが、保険として置いておく

決めていないこと

この計画は実装が先行した

計画を書く前に実装した。順序としては誤りである。この文書は、動いているものを後から書き起こしたものになる。

残っている検討

断り文を守らせる手立て

testBody() を通さずに投稿しても止められない。いまは書き手が守る前提である。テスト専用のサーバーで動かすようになれば、守れていなくても実害は無くなる。

登録もれ

後始末は「自分が登録した名前」しか消さない。freshNames() も register() も通さずに名前を作ると、消えずに残る。回収するには purge-test-data.cmd を手で叩く。

ドキュメント側のテストが古い

今回の作業とは別に、6 件が落ちたままである。いずれもドキュメントを書き換えたのにテストが追随していないもので、テストデータとは関係しない。