36

ほんの数日前、check と呼ばれる単体テスト フレームワークの調査を開始し、Linux で C コードでテストを実行するつもりです。

ここで、適切に設計されたコードといくつかのテスト コードを確認して、基本的な機能が正しいことを確認するのに役立ちます。つまり、変数を見て応答を返し、関数が正しいかどうかを判断するのは非常に簡単です。

しかし、malloc と free を大幅にオフにして動的メモリ構造をテストしたいとしましょう。データを入れて、正しいデータを再び取得できることがわかりました。しかし、それは私がその過程でいくつかのメモリを壊していないことを証明するものではありません.メモリの半分を解放するのを忘れてポインタを失ったとしましょう(古典的なメモリリーク). そのコードは、おそらくほとんどの単体テストに合格するでしょう。

それでは質問です。ユニット テスト コード全体を Valgrind で実行し、malloc/free の問題を検出させるのは良い考えですか? (または、Electric Fence のようなものでコンパイルしますか?)

いいアイデアのように感じますが、ここで何を考えているのかわかりません.....

ありがとうヨハン


更新: Douglas と Jonathan に感謝します。

更新: Valgrind は楽しいツールですが、これを行うと最初に見つかった memleaks は、自分のコードではなくテスト フレームワークにありました (かなり面白いですが)。したがって、残りのヒントは、独自のコードをひっくり返す前に、使用している単体テスト フレームワークがリークしていないことを確認することです。私の場合は空のテスト ケースで十分でした。それは、単体テスト フレームワークしか実行されていないためです。

4

2 に答える 2

60

確かにそうです - 完全なプログラムよりも単体テストに対して valgrind を実行する方がはるかに簡単です。

また、メモリ エラーは、単体テストがテストしているコードの領域に限定されるため、修正が容易になります。

さらに、完全なプログラムに対するより複雑なテストではなく、単体テストを実行しているため、修正したことを確認する方が簡単です。

自動化された方法でvalgrindを実行している場合は、おそらく必要です--error-exitcode=<number> [default: 0]

Valgrind が実行中にエラーを報告した場合に返す代替終了コードを指定します。デフォルト値 (ゼロ) に設定すると、Valgrind からの戻り値は、常にシミュレートされているプロセスの戻り値になります。ゼロ以外の値に設定すると、Valgrind がエラーを検出すると、代わりにその値が返されます。これは、自動化されたテスト スイートの一部として Valgrind を使用する場合に便利です。戻りコードを検査するだけで、Valgrind がエラーを報告したテスト ケースを簡単に検出できるからです。

http://valgrind.org/docs/manual/manual-core.html#manual-core.erropts

于 2009-01-19T21:42:52.453 に答える
10

Douglas Leeder が言ったように、実際に期待どおりに動作することを確認できる任意の診断ソフトウェアを使用してユニット テストを実行する価値は十分にあります。これには、メモリを悪用しないことも含まれるため、valgrind を使用することをお勧めします。

単体テストで、コードが機能することを証明することが本当に必要です。

常に valgrind の下でそれらを実行する必要はありませんが、実行するのはできるだけ簡単であるべきであり、定期的に実行する必要があります (大きな変更の後など)。

于 2009-01-19T22:02:02.883 に答える