新しい機能を開発したり、パッチを作ったり、作業が無事完了しました。そして、プルリクエスト(PR)を作ってメインブランチにマージしていく準備ができました。

でも、ちょっと待ってください。本当に準備完了ですか?

DevOpsパイプラインのテストについては前回の記事でも書かせていただきましたが、テストの成熟度モデルの頂点にいる組織のみが、コーディングフェーズでテストを実行している傾向があります。

つまり、PRフェーズになってから、テストを開始する組織の方が大半を占めています。そうすると、実行するテストが多くなった場合、それらを実行する時間が取れなくなってしまうといった欠点があります。

こういった制約を考慮した場合、どのようなテストの形が適しているのでしょうか?DevOpsパイプラインのテストについてまとめられたインフォグラフィックを見てみましょう。

infographic-testing-for-devops-pipelines-30NOV2020_U開発ライフサイクルにおけるPRフェーズでのテスト

説明のために、システム開発ライフサイクルのなかで、PRのフェーズを2つにわけてみました。最初はコミットフェーズで、開発者がブランチを切って、自分自身の作業を追加していくフェーズです。もうひとつは、作業用のブランチがメインブランチと統合されるPRの承認フェーズです。

開発者がコミットするたびに一連のテストを実行し、PRが承認される前に、もう一度テスト実行される形が理想的です。第1フェーズのテストでは、以下のようなテストが必要になります。

  • 明らかなコーディングエラーを排除する静的解析
  • 基本的な機能が動作することを確認するAPIスモークテスト
  • 個々のコミットの機能検証する単体テスト

インフォグラフィックを見ると、上記のようなテストは、コーディングフェーズでも実行できることがわかります。仮にこれらのテストがまだ完了していない場合、PR承認前の第2フェーズのテストでは、コードレビューがはじめに実施されるはずです。

従来、PRフェーズでは、チームによってコードがレビューされ、追加の修正が提案されたり、追加のコミットが必要になったりします。このプロセスが完了すると、PRが承認され、メインブランチにマージされていきます。

テストに対する成熟度の高いユーザは、「ビルド」というステップを行ったりもします。これは、ブランチがマージされる前に、自動的にそのブランチをビルドを行い、テストするステップです。

このステップによって、ビルドが壊れていないことが確認でき、新しい機能が承認されたあとすぐに、単体テストを実行できます。このような高度なレベルの自動化により、コードレベルの障害が原因で、開発者がPRをすぐにロールバックする問題が減少します。

ただし、このPRの承認フェーズ上で、コードのチェックに焦点を当てすぎると、予期せぬ盲点が生まれてしまいます。これらの盲点を見逃すと、質の悪いコードが本番環境に侵入するリスクが高まり、将来的に深刻な問題が発生してしまう可能性があります。

よって、このフェーズによりテストを追加することで、そのリスクを大幅に軽減し、チームの時間、労力、およびストレスを節約できます。

PRフェーズのテストを拡張と合理化

開発者が、PRを終える前に、次の3つの作業を行っておくのが理想です。

  • まず、コミット時にUIに対するスモーク テストを実行し、新しいコードが重要な機能を壊していないことを確認
  • 次に、既存のテストも壊していないかを確認
  • 最後に、新しい機能を含めて、最適なテストカバレッジになっていることを確認

コードレビューやビルド実行だけでなく、開発者はアプリケーションが意図したとおりに機能することを確認すべきでしょう。たとえば、用意したE2Eテストを実行し、テストの成功を確認する方法もとれます。また、メインブランチにマージする前に、既存のテストを壊していないか確認する必要もあります。

このフェーズでテストが壊れた場合、テストがパスするように、コードを書き直すのか、それともテストを書き直すのか。重要な決定を下す必要があります。

コードの変更をメインブランチにマージするときに、このような意思決定を下しているのはおそすぎます。そのかわりに、ブランチにコミットを行う時点でテストカバレッジを測定するすべきでしょう。

テストが成功するか失敗するかは、ほんの一部の結果でしかありません。テスト結果だでなく、テストカバレッジ、適切なアサーション、テストが高品質を保証しているかなどを確認していく必要があります。

このように、コーディング時と同等の標準的な作法や、エンジニアリングとしての規律を、テストにも適用できるのです。

開発とテストのライフサイクルに品質を統合する

mablを使えば、開発とテストのつなぎ目を簡単に取り除くことができます。mablは、テストに熟知していない人であっても、開発のワークフロー内に自動テストを、簡単に直感的に組み込むことができます。

開発ライフサイクルのどんなフェーズにも統合できる、再利用可能なE2Eテストフローの構築を試してみませんか? 今すぐ無料トライアルにお申込みを!