コード ベースの単体テスト カバレッジを、理にかなっている程度にまで高めたとしましょう。(特定のポイントを超えると、カバレッジを増やしても ROI は向上しません。)
次に、パフォーマンスをテストしたいと思います。コードをベンチマークして、新しいコミットが不必要に速度を低下させていないことを確認します。私は、コミットによる速度低下に対するSafari のゼロ トレランス ポリシーに非常に興味をそそられました。スピードへのコミットメントのレベルがほとんどのプロジェクトで良い ROI をもたらすかどうかはわかりませんが、少なくともスピードの後退が発生したことを警告され、それについて判断できるようになりたいと思っています.
環境は Linux 上の Python であり、BASH スクリプトでも実行可能な提案は非常に嬉しく思います。(しかし、Python が主な焦点です。)
可能であれば、システム レベルでパフォーマンス テストを実行することをお勧めします。アプリケーション全体をコンテキスト内で、本番環境での使用にできるだけ近いデータと動作でテストします。
これは簡単なことではなく、自動化して一貫した結果を得るのはさらに困難です。
さらに、VM をパフォーマンス テストに使用することはできません (運用環境が VM で実行されている場合を除きます。その場合でも、他に何もないホストで VM を実行する必要があります)。
パフォーマンスの単体テストを行うと言うとき、それは価値があるかもしれませんが、(開発者の頭の中だけでなく) システム レベルで実際に存在する問題を診断するために使用されている場合に限られます。
また、ユニット テストでのユニットのパフォーマンスは、コンテキスト内のパフォーマンスを反映しない場合があるため、まったく役に立たない場合があります。
システム レベルでパフォーマンスをテストする方が最終的にはより適切であることに同意しますが、Python の UnitTest スタイルの負荷テストを行いたい場合は、FunkLoad http://funkload.nuxeo.org/がまさにそれを行います。
マイクロ ベンチマークは、コードベースで特定のアクションを高速化しようとしている場合に役立ちます。後続のパフォーマンス ユニット テストを実行することは、最適化したこのアクションが今後のコミット時に意図せずパフォーマンスを低下させないようにするための便利な方法です。
パフォーマンス テストを行うときは、通常、データ入力のテスト スイートを用意し、プログラムが各入力を処理するのにかかる時間を測定します。
パフォーマンスは日単位または週単位でログに記録できますが、すべての機能が実装されるまでパフォーマンスについて心配することは特に役に立ちません。
パフォーマンスが低すぎる場合は、cProfileを分解し、同じデータ入力で実行して、ボトルネックがどこにあるかを調べます。
MarkR の言うとおりです... 実世界でのパフォーマンス テストを行うことが重要であり、単体テストではやや危険な場合があります。そうは言っても、cProfile標準ライブラリのモジュールを見てください。少なくとも、コミットからコミットまでの実行速度を相対的に把握するのに役立ちます。単体テスト内で実行できますが、もちろん、オーバーヘッドを含む詳細な結果が得られます。単体テスト フレームワーク自体の。
ただし、目的がゼロトレランスである場合は、これよりもはるかに堅牢なものが必要になります...単体テストの cProfile はまったく効果がなく、誤解を招く可能性があります。