2025-07-21

13年もITエンジニアやってていまだに自動テストエアプなので気付いてなかったんだけどPRの段階で行われるべき自動テストは単体テストではなく結合テストなのでは？と思った。
別のPRが同じ親にマージされた結果として単体がコケるとかのケースもありそうなので（引数変えられたとか）単体テストをCIに含めるのも悪いわけじゃなさそうなんだけど、単体テストのタイミングとして「プッシュした後、PRを作った段階」は遅い気がする。

プッシュ前

• 単体テスト
  • RSpec
  • minitest
• lint
  • rubocop

PR作成時

• 結合テスト
  • Capybara
  • Selenium
  • RSpec

別のPRが同じ親にマージされたとき

別PRの変更の影響で自分のPRがコケる可能性がある

• 単体テスト
• 結合テスト

on:
  push:
    branches:
      - develop
  pull_request:
    branches:
      - develop

DBのschema変更してrequireカラムが追加されたのにdefault値も無くseedも更新されてないからいきなり500エラーとかたまにある
レガシーコード改善ガイドに言わせればDB接続を必要とするテストは単体テストではないとのことなのでこれも結合テストの範囲かな

とはいえ

「どこまでがどの段階での誰の責任か」みたいなのって会社によって（それどころかプロジェクトによって）まちまちだったりするのでこの辺りを考えるのはアーキテクトの仕事なのかなと思う。プロジェクトの最初に「どのタイミングで、誰（人間だけではない、自動テストを含む）が、どこまでの責任を持つか」が決まっていたらいい気がする。
保守とかリファクタリングはそれはそれで悩ましい。Lintとか途中から導入するとエラーがいっぱい出たりして見づらいし、リファクタリングのチケット（工数）は無いことが多いし、バグ修正ついでに直すにも本題以外の個所に差分が出るのも嫌だし（特に下請けだと上司が嫌がることも多い
そうでなくてもバグ修正チケットで全然触ってないところのバグが出て突き返されたりするしね。今まで触ってなかっただけでずっとあったバグなのでは？