はじめに
BASE株式会社でシニアエンジニアを務めているプログラミングをするパンダ（@Panda_Program）と申します。本連載はPHPカンファレンス2022での発表「実践！ユニットテスト入門」を再構成して記事としたものです。
対象読者
本連載の対象読者は、自動テストの必要性をわかっているもののまだテストコードを書いたことがない開発者の方です。さらに本記事では、テストコードを書く習慣が身についている中級者の方にとっても、自動テストに対する理解を深める助けになるでしょう。
ソフトウェア開発における自動テストの位置付け──DevOpsを手がかりに
本記事では、ソフトウェア開発における自動テストの位置付けを考察します。ソフトウェア開発と一言でいってもその内容は多岐に渡ります。ソフトウェア開発の中におけるテストの位置付けを探るのであれば、なおさら込み入ったものになることは想像に難くありません。
そこで、今回はDevOpsが考えるソフトウェア開発の全体像を参照しつつ、自動テストの位置付けを探っていきます。
DevOpsはソフトウェアの開発と運用を統合した考え方である
DevOpsとは、ソフトウェアの開発と運用を統合した考え方です。かつて開発者と運用者は分かれていましたが、開発者も自らが作成したソフトウェアの運用に責任を持つべきという発想から両者の統合モデルが考案されました。
WikipediaにおけるDevOpsの図では、左側のDev（ソフトウェアの開発）と右側のOps（ソフトウェアの運用）が連環を描いています。
DevはさらにPlan（計画する）、Create（制作する）、Verify（検証する）、Package（まとめる）のステップに分割されており、Devの最後のPackageのステップはOpsの最初のステップであるReleaseに繋がっています。
OpsはRelease（リリースする）、Configure（設定する）、Monitor（監視する）の3つのステップに分かれています。Opsの最後のMonitorがDevのPlanのステップと繋がっているのは、監視の結果を見て次の開発計画を立てるというPDCAのサイクルが想定されているからです。
この図はソフトウェアの開発と運用を包括的に表現しており、テストもこの中に含まれています。Devの中のVerifyがテスト相当であると言えるでしょう。しかし、Createの後にVerifyのステップが来るのは、制作がすべて完了した後にしか検証ができないといった印象を与えてしまいます。
テストという検証は、本当にCreateという制作のステップの後にしか実施できないのでしょうか。
DevOpsにおける自動テストの位置付け
この問いに対する答えはContinuous Testing in DevOpsというブログ記事に記されています。下図は記事からの引用です。
この記事によると、DevOpsにおいてテストはDevとOpsの各ステップにおいて実施するものとされています。例えば、Planのステップのテストは設計案が本当に良いものなのかをチェックすることです。また、Monitorのステップのテストとは設定したアラートが本当に必要なものか再検討することです。このように実装だけではなくアイデアもテストすることが可能です。
ただし、本連載は開発と運用における全てのテストを解説することが目的ではありません。本連載はコードで記述された一連のテストケース群がテストフレームワークで実施されるという自動テストを対象としています。
本記事の自動テストはアジャイルテストの四象限ににおけるQ1（開発者を支援する技術面のテスト）のUnit Tests と Component Test を想定しています。コードで実装されたテストケースをテストフレームワークがローカル上やCI上で自動で実行するものです。
このため、本記事ではCode（コーディングする）、Merge（マージする）、Build（ビルドする）を自動テストのカバー範囲であるステップとみなします。
Wikipediaと「Continuous Testing in DevOps」の図を見比べると、前者ではDevの中のCreate、Verify、Packageと分けられていた各ステップが、後者ではBranch、Code、Merge、Buildとより現場に即した表現に変更されています。こちらの方がより開発の実態を適切に表しているといえるでしょう（なお、Wikipediaの図はDevOpsを図示した例の一つに過ぎず、正しいとか間違っているという見方をするものではありません）。
ここまでの説明で、自動テストはソフトウェアの運用ではなく開発フェーズのステップに属するものと理解してもらえたと思います。
