この記事で書くこと
機能開発をしたときに、テスト仕様書をもとにCodexでRSpecを作る方法を試しました。
結論としては、以下の3点で効果がありました。
- 仕様書と同じ順序でテストが並ぶため、レビューしやすい
- 開発者の観点に偏りにくく、抜け漏れを見つけやすい
- テストのたたき台作成が速く、実装に集中しやすい
背景
実務では、テスト仕様書を作る人とRSpecを書く人が分かれることがあります。
このとき、RSpecが「実装者の頭の中の想定」中心になり、仕様書との対応が見えづらくなることがありました。
もちろんそれ自体が悪いわけではありませんが、レビュー時に次が難しくなります。
- 仕様書のどの項目をカバーしているか
- 抜けている観点がないか
- テストの実行順が仕様書と対応しているか
そこで今回は、仕様書をそのまま入力にして、CodexにRSpecの骨組みを作らせる方式を試しました。
準備: 仕様書はMarkdownで置く
通常はExcelで管理することが多いですが、AIに渡す前提ならMarkdownのほうが扱いやすいです。
今回はリポジトリ内に、影響範囲とテスト項目をまとめたMarkdownを作成しました。
# 影響範囲
## admin管理画面
### 基本設定
#### コメントグループ設定
##### 一覧
- レビュー要約の有無をテーブル表示
##### 新規・編集
- レビュー要約の有無を設定可能
〜省略〜
## バッチ
### コメント要約依頼・実行: Job名A.関数名
- ProductCode毎に要約を行う
〜省略〜
# テスト項目
## バッチ
#### コメント要約依頼・実行: Job名A.関数
- ロック制御
- 前提条件: lockディレクトリが存在
- 確認事項
- [ ] TTL内はジョブがスキップされる
- [ ] TTL超過の場合はロック削除後に再実行される
- 対象なし
- 前提条件: Tableが存在しない
- 確認事項
- [ ] 何も処理されず終了する
- 要約対象処理(batch正常系)
- 前提条件: TableA/TableB/TableC/TableDが存在している
- 確認事項
- [ ] updated_comments?がtrueの場合のみ要約が実行される
- [ ] payloadに公開状態(publish)のコメントのみ含まれる
- [ ] summary.statusがpending→processingに更新される
- [ ] 処理完了後にTable名が削除される実際にCodexへ渡した指示
以下のように、シンプルに依頼しました。
- この仕様書の「影響範囲」と「テスト項目」を元にRSpecを作成してください
- テストケースの順序は仕様書と同じにしてください
- 仕様書との対応が分かるよう、見出しコメントは日本語で付けてください
生成されたRSpecのイメージ
describe '#perform' do
# ロック制御: lock取得失敗 > ロック(TTL内)
it 'lockのTTL内なら処理をスキップする' do
# 省略
end
# ロック制御: lock取得失敗 > ロック(TTL超過)
it 'lockのTTL超過ならロックを削除して続行する' do
# 省略
end
# 対象なし: SummaryTargetが存在しない
it 'SummaryTargetが無ければ何もせず終了する' do
# 省略
end
# 要約対象処理: バッチ正常系
it 'payloadを生成してLambdaを呼び、Targetを削除する' do
# 省略
end
end使ってみて感じた注意点
- 生成物はそのまま採用せず、内容をしっかり確認し、必要に応じて修正する
- 1回で完璧を狙わず、仕様書→生成→差分修正の2〜3往復で仕上げる
まとめ
大量機能を一気に作る場面では運用設計が必要ですが、機能単位であればかなり実用的でした。
特に、仕様書とテストコードの対応が明確になるため、レビュー効率と安心感が上がります。
「仕様書はあるが、RSpec化の時間が重い」という場面では、まず小さい機能から試す価値があると思います。
榎本 力也（エノモト リキヤ）
デジタルマーケティング・オファリング学部 SaaS グループ
AdvantageSearch、VoiceLog、PushTracker、BranchPop、コンパス・キューエー等、SaaSグループ全ての開発を取りまとめています。
最近はAI関係の開発などを中心に行っています。
connpass
Peatix
Wantedly
デザインチームnote