この記事はCameron Lairdによるゲスト投稿です。

継続的テスト(CT)は、たいてい単体テストとの関連で説明されます。しかし、パフォーマンステストもCTに含める価値があります。パフォーマンステストには特有の課題がありますが、正しく理解することで、単にパフォーマンステストをCTに適合させるだけでなく、利点を最大化することもできます。

パフォーマンステストに関するCTの課題とその解決策については、少しばかり説明が必要です。一般的に、単体テストでは、迅速であること、外部リソースに依存しないこと、確定的であること、客観的であること、定型化されていることが特に求められます。単体テストの構成でよくある課題の1つが、データベースなどのホスト外のリソースへの依存です。

一般的に、単体テストのノウハウにはモック化、依存関係の置換、あるいは外部依存関係からテストを分離するその他の技法が含まれます。このような分離を行うことで、個々の単体テストは開発者のデスクトップでも、CTパイプラインでも、その他必要に応じてどこで実行しても、等しく有益な情報を提供します。

いっぽう、パフォーマンステストの特性はだいぶ異なります。パフォーマンステストは、リソースを限界まで酷使したときや、運用環境に近い環境で実行したときに最も有益です。同じコードでも、運用環境では重大な問題が診断されるが、開発者の統合開発環境(IDE)では何の問題も観測されない場合もあります。

パフォーマンステストは、メモリの配置や大容量ストレージからのデータ取得速度などの詳細に左右される可能性があります。多くの場合、小規模で透明性と予測可能性を重視して設計される単体テストとは対照的であることに注意してください。

テストの周期

このような違いはあっても、CTを調整して、従来CTに組み込まれることが多いテストと同様にパフォーマンステストを含めることができます。まず行うべき調整は、パフォーマンステストのために異なるテスト周期を用意することです。一般的に、CTはコミットごとに単体テストを開始し、単体テストの結果を基にコミットが成功か失敗かを判定します。パフォーマンステストは実行に何倍も時間がかかるので、この設定は実用的ではありません。

それでも、1時間に1回、あるいは1日に1回など、定期的にパフォーマンステストをスケジュールすることは可能です。 そうすれば、あるコミットがパフォーマンステストを失敗させる原因を導入したとしても、少なくとも1時間または1日以内には失敗が検出されるため、最終的な品質保証レビューではじめて問題が見つかるということはありません。プログラミングエラーの早期検出— テストの「シフトレフト」 —はエラーを迅速に修正するのに おおいに役立つと広く信じられています。

パフォーマンステストを効果的に行うには、他にもCTに適合させるための調整が必要になるかもしれません。おそらく、ネットワークの負荷、ディスク処理、サービス利用率などが軽微で、有意義な計測が可能なオフピーク時にのみパフォーマンステストを実行するべきでしょう。限られた権限だけを持つリソースが必要になるかもしれません。

パフォーマンステストを本来あるべきレベルまでシステマティックかつ重要なものにできるのは自動化やCTツールだけです。たしかに、既存のツールはどちらかというと単体テスト向けにできています。たとえば次のように判断します。

通常、単体テストは「値$Vが$Rであること」を検証するいっぽう、パフォーマンスの「合格水準」は「計測値$Mがベースラインの7%以内にあること」というようなものでしょう。このような違いを見て、だからCTにパフォーマンステストを入れるべきではないと考える人もいるかもしれません。実際は、このような違いこそ、CTを拡張してパフォーマンステストを含めるべき理由です。

    assert operation.result == expected_result

けれど、少し慣れれば、次のように書くのも自然なことになるでしょう。

    assert within_range(elapsed_time, expected_time, agreed_tolerance)

後者のような判断がなければ、代わりの手段としては、おそらく品質保証の締め切り直前に何らかの主観的な手動テストを行うしかないことに注意してください。たとえ不完全であっても、CTによって安定的にスケジュールされ、自動化されたパフォーマンステストは、手動テストよりはるかにましです。

意識の変革

パフォーマンステストとCTの統合に関して得られる最大の結論は、適切な意識を持てば、この統合がどれほどの「成功」であるかは明白だということです。パフォーマンステストは単体テストよりも統合が難しいと判断され、除外されることもあるかもしれません。しかし、パフォーマンステストをCTに統合することで得られる品質上の利点に着目すれば、統合をやりとげることの魅力が増すでしょう。

ぜひやってみて、パフォーマンステストにまでCTを拡大した結果がどうだったかを教えてください。

Cameron Lairdは、賞を授けられたソフトウェア開発者で著述家です。Cameronは、Python Software Foundationの投票権を持つほか、いくつかの業界のサポートや標準化組織に参加しています。長くTexas Gulf Coastに住み、農場自動化アプリケーションがお気に入りです。

（この記事は、開発元Gurock社の Blog 「Performance Tests Deserve Continuous Testing Too」2021年5月5日の翻訳記事です。）