本番環境を更新するたびに、ある不安がある。「前の機能が壊れていないか」——機能を追加するとき、既存の動作に影響を与えることがある。直したつもりが別の場所を壊すことがある。これを手動で全部確認していたら、更新するたびに何時間もかかる。自動テストスクリプトを作った理由は、この不安を消すためだ。
何をテストするか
テストすべき項目を整理するとき、AIとこんな対話をした。「このゲームシステムで、本番前に必ず確認すべき項目を網羅的にリストアップしてほしい」。AIが返したリストから「本番で壊れたら研修が止まるもの」に絞り込んだ。
DBスキーマ整合チェック（本番とステージングが一致しているか）とAPI契約テスト（全エンドポイントが期待通りレスポンスを返すか）——この2カテゴリで35項目を設計した。
実行は1行
これを実行するコマンドは1行だ。python run_checks.py。約30秒で全35項目が確認できる。全PASSなら「デプロイしてよい」。1項目でもFAILなら「問題を特定してから」。
テストが「デプロイへの勇気」を生む
テスト自動化の最大の価値は、速さではない。「テストをパスしたなら、デプロイできる」という確信だ。以前は「大丈夫だと思うけど、念のため確認しよう」という曖昧な状態でデプロイしていた。今は「35項目全PASS」という客観的な基準がある。研修の前日夜に変更を加えても、翌朝にテストを走らせて全PASSなら安心してデプロイできる。この確信がなければ、研修直前の改善は怖くてできない。
テスト項目の具体例と「失敗して良かった」事例
35項目のテストが何を確認しているか、代表的な項目を公開する。
DBスキーマ整合チェック（12項目）：
- 本番とステージングのテーブル一覧が一致しているか
- companiesテーブルのカラム数・データ型が一致しているか
- resultsテーブルにKPI系カラムが全て揃っているか
- インデックスが正しく設定されているか
APIエンドポイントテスト（18項目）：
/api/games/{game_id}/statusが正しいJSONを返すか/api/decisions/submitに正しいパラメータを渡したとき201を返すか/api/admin/emergency_loanが認証なしでは401を返すか- ターン計算APIが想定通りの計算結果を返すか（1社だけ決断するケース）
その他の整合性チェック（5項目）：
- 本番とステージングのPythonパッケージが一致しているか
- 設定ファイルの差異が管理された差異のみか
「失敗して良かった」事例：
デプロイ前日の夜、テストを走らせると1項目FAILが出た。「本番のcompaniesテーブルにカラムが1つ多い」。確認すると、ステージングで削除したカラムが本番にまだ残っていた。このカラムは使用していないが、残っているとコードの意図が不明瞭になる。デプロイと同時に本番でもALTER TABLEで削除した。
もしテストがなければ、このカラムは気づかれないまま残り続けた可能性が高い。「無害な差異」でも、把握できていない差異は後の問題の種になる。テストが「管理されていない差異」を可視化してくれた。
もう一つ。ターン計算APIの結果チェックで「期待値と一致しない」FAILが出たことがある。計算ロジックのバグではなく、テストデータの前提が変わっていたせいだった。テストデータを修正したが、「テストが壊れた理由を調べる」過程で、計算ロジックの微細な変更を再確認できた。テストは「問題を見つける」だけでなく「変更を意識させる」価値がある。
*次回は「ステージングと本番の同一性をどう管理するか」*
テストが実際にデプロイ前の不具合を発見した事例
自動テストの価値を証明した出来事がある。チーム編のデプロイ前夜、run_checks.pyを実行すると1項目がFAILした。
「APIエンドポイント /api/team/decisions/finalize — HTTP 422」。Unprocessable Entityが返ってきている。ステージングでは正常に動作していたのに、本番では422が出る。
原因を調べると、本番DBのteam_proposalsテーブルに不要なNOT NULL制約が残っていた。ステージングでALTER TABLEでこの制約を外したが、本番DBへの適用が漏れていた。ステージングで動いていたのは制約がなかったからだ。本番で422が出たのは、APIがNULL値を含むリクエストを送ったとき、DBレベルで拒否されていたためだ。
テストがなければ、この差異は研修当日に参加者がチーム編を使おうとした瞬間に発覚していた。「チーム編が動かない」という研修中のトラブルは、参加者の体験を大きく損なう。デプロイ前夜の発見だったため、本番DBにALTER TABLEを適用して翌朝の本番研修を正常に完了できた。
もう一つ。テスト項目の中に「DBスキーマ整合チェック」として本番とステージングのカラム数比較がある。ある週にこのチェックが「本番のcompaniesテーブルにカラムが1つ多い」を検出した。確認すると、ステージングで削除したカラムが本番にまだ残っていた。使用はしていないが、管理されていない差異は後の問題の種になる。テストが「知らない差異」を「知っている差異」に変えてくれた。
*シンプルシステム株式会社 代表 伊藤勝彦*