PHPにはコードの品質を担保するために、静的解析とテストがある。これらは単体で銀の弾丸になるわけでなく、それぞれに得意不得意があり組み合わせて用いる。
ざっと思いつくのが以下のツール。
php標準のlinter機能「php -l」
php -lで実行し、動作に影響するようなコードの文法部分の明確な誤りを静的解析で見つける。（$$thisなどの表現）
phpcs
コードの統一的な記述を満たしているか静的解析で見つける。動作に影響しないコードが対象。
phpstan
型の不一致や条件分岐が意味をなさないケースなど、コードロジックにおける誤りを静的解析で見つける。
phpUnit
テストケースを実行して実際の動作と期待値を検証する。
e2e
フロント側の操作に対して、期待の動作をするか検証する
静的解析は早く、動的解析は数が増えるにつれて遅くなる。本来、修正に対応して常に動的テストを行うべきだが、時間がかかると形骸化することが多い。
そのためタイミングに応じて静的解析と動的解析を組み合わせる。
以下一例。コミット前に静的解析をすませる。各コミット自体で静的解析で済む修正は直されるべきだというスタンスに基づく。pushするものはすべて動作すべきというスタンスにも基づいている。
コミット前：php -l , phpcs, phpstan
プッシュ前：phpUnit, e2eテスト
変更が頻繁に起こなわれる場合だと、こっちのほうが良いかも。コミットは最低限の検出で、プッシュ前に静的解析を行う。動的なテストは時間がかかるため、ローカルで行うと、PC負荷がかかる。そのため、テストは外部に任せ、結果を見て必要に応じて再修正するスタンス。pushした結果を検知するようにしておかないと形骸化しがち。
コミット前：php -l
プッシュ前：phpcs, phpstan
プッシュ後：phpUnit, e2eテスト