SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

実践! ユニットテスト入門

【実践的ユニットテスト入門】ソフトウェア開発における自動テストの位置付けを考察する

実践! ユニットテスト入門 第2回


  • X ポスト
  • このエントリーをはてなブックマークに追加

 「テストを書くと開発に時間がかかる」。こんな話を一度は耳にしたことがあると思います。実際はその逆で、テストを書かないとむしろ開発の工数が増えてしまうのです。本連載では、テストの基本知識はあるが今まで実際のプロダクトでテストを書いたことがない人や、自分が書いたコードのどこをテストしたらいいのかわからない人を対象に、まずはテストを書く→質のいいユニットテストを目指すことを目的として、足がかりとなるポイントを解説します。第2回となる本稿では、ソフトウェア開発における自動テストの位置付けを考察します。

  • X ポスト
  • このエントリーをはてなブックマークに追加

はじめに

 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を図示した例の一つに過ぎず、正しいとか間違っているという見方をするものではありません)。

 ここまでの説明で、自動テストはソフトウェアの運用ではなく開発フェーズのステップに属するものと理解してもらえたと思います。

次のページ
改めて自動テストを書く意義とは何か

この記事は参考になりましたか?

  • X ポスト
  • このエントリーをはてなブックマークに追加
実践! ユニットテスト入門連載記事一覧

もっと読む

この記事の著者

プログラミングをするパンダ(プログラミングヲスルパンダ)

 https://twitter.com/Panda_Program/ フロントエンドエンジニア。元々サーバーサイドエンジニアだったが、個人開発を機に HTML, CSS, JS に興味を持つ。特に React、Next.js に熱中しフロントエンジニアに転向。TDD、XP、DevOps が好き。

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/20057 2024/08/29 17:35

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング