（書きかけ）DBのテスト

整理する前の乱雑なメモ。適当に書き直したりするかも。


  • 何をテストするのか
    • CRUD が行われている
    • 行われた CRUD の内容が正しい
    • SQLのロジック（？）が正しい
  • テスト用のDBを用意する（気兼ねなくあれこれ試せる砂場）
    • メインのDBと間違えないように、というのと、メインのDBとテーブル定義などが同期できている、というとこだけ大事。あとは好き勝手できる
    • setup の最初で delete all
    • テスト用DB作成（テーブル定義の同期）を手軽に
  • テスト実行後にロールバック
  • すでにあるDB内にあるデータとは別の領域を使う

（id 1〜100 のレコードが存在しているときにテストでは 1000以上の id を使って
teardown で delete ... where id >= 1000 とか…）
あまり気乗りしない。

  • DB内にあるデータを退避 → fixture投入 → テスト → 退避したデータを戻す
    • 退避するデータが多いと遅い
  • 環境（ローカルの開発用、テスティングフレームワーク用、ステージング、本番、etc）によって接続先など設定を切り替え
  • 処理が終わった後のDBの状態を見たいので teardown では何もしない
  • モック
  • LLの活用
  • パラメトリックなfixture生成
  • 動的なパラメータ … 日時など
    • 「n日前」などの日時生成を手軽に
  • SQL にコメント付加 → ログを見たときにどのSQLなのか分かりやすいように
  • カバレッジと柔軟性のトレードオフ（？）
  • リレーションの把握しやすさ
  • テストには関係ないが NOT NULL なカラムの扱い
  • ポータブル性、確実性？ … メンバー間でテスト結果が異なったりしない

「SCMには入ってないけどアレをやっとかないとこける」みたいなのがあるとめんどくさい