■ 1. 概要と背景
- EndBASICのコアを書き直すにあたり、テストをRustのユニットテストからMarkdownで記述する方式に移行
- AIコーディングエージェントの実験がEndBASIC開発の再開を動機付け
- AIエージェントがEndBASIC公式ドキュメントをもとにゲームを生成することに成功
- これを受けてEndBASICの「自己文書化」強化、高速化、機能拡張の三方針を立案
- テストをMarkdownで書くことで、LLMがテストから言語仕様・動作ルールを自律的に学習できると判断
■ 2. Markdownテストスイートの構成
- テストスイートの実体:
core/tests/ディレクトリ以下の.mdファイル群（現在448テストケース、13,000行超）- 各ファイルが複数のテストケースを含むコンテナとして機能
- テストケースの構造:
■ Source— コンパイラへの入力（BASICソースコード）■ Compilation errors— コンパイル失敗時のエラーメッセージ（失敗時のみ）■ Disassembly— コンパイル後のバイトコード（成功時）■ Exit code— ゼロ以外の終了コード（任意）■ Output— プログラムのコンソール出力（成功時）■ Runtime errors— 実行時エラー（成功時）■ 3. テストの実行方法
- ドライバの動作:
tests/ディレクトリ内の全Markdownファイルを列挙して順次処理- 各ファイルからテストケースのタイトルと
Sourceセクションを抽出- 各テストケースをコンパイラ・VMに投入し、副作用をキャプチャ
- 実行結果を新規Markdownファイルとして出力（actual）
- ゴールデンファイルとの比較:
- ドライバが出力したファイル（actual）をリポジトリにチェックインされた既存ファイル（golden）と差分比較
- 差異があればテスト失敗とし、
diffで差分を表示- ゴールデンファイルの再生成:
REGEN=true環境変数を設定することで、ドライバがゴールデンファイルをその場で上書き再生成- 再生成後はGitで差分を確認し、コード変更と合わせてコミット
■ 4. 評価
- メリット:
- 以前のRustベースのテストと比較して格段に修正・確認が容易
- 主要なテキストエディタのMarkdownサポートを活用でき、フェンスコードブロックの整形も機能
- LLMが言語仕様のルールをMarkdownテストから自律的に抽出・学習できる
- デメリット:
REGEN=trueによる再生成が容易すぎるため、ソース位置や逆アセンブルコードの細かいミスを見逃しやすい- 逆アセンブルの差分が命令アドレスを含むため、命令の追加・削除で全アドレスがシフトしノイズが多い
- Rustの
cargo testによるテストフィルタリングが機能せず、Markdownファイル内の個別テストケースは実行単位として扱えない- エンドツーエンドテストが安価なコンポーネントに限定的で汎用性に乏しい