問題タブ [check-framework]

ここ StackOverflow でかなりのスレッドを読んだ後、何らかの形のテスト駆動型開発/単体テストを採用する (または少なくともその領域を調査する) 必要があるという結論に達しました。

Linux での C コードについて話しているので、チェックを試してみることにしました (これが正しい選択かどうかはわかりませんが、うまくいかない場合は、後でいつでも別のことを試すことができます)。

しかし、この単体テストと単体テスト フレームワークの概念は私にとってまったく新しいものだったので、非常に小さなテスト コードで単体テストを実行することから始めました (しかし、とにかく完全に道に迷い、何かが足りないように感じました)。

これは私がこれまで行ってきたことであり、次のファイルを作成しました。

• main.c は、my_pow という関数のみを呼び出して結果を出力するメインです。
• my_pow.c には、関数 my_pow が含まれています。
• my_pow.h
• my_pow_test.c、ここに my_pow 関数のユニット コードを配置する必要があると考えました。

(したがって、「通常のプログラム」は main.c、my_pow.c、および my_pow.h です。)

これは my_pow.c です

次に、 my_pow_test.c に次のようなものを入れることにしました。

これは基本的にチェックマニュアルの 3.1 章と同じですが、それでも違います....

誰かが私を正しい方向に押してくれませんか？

ありがとうヨハン

更新: check を使用しようとした理由はありません。どこかから始めるべきだと思っただけです。おそらく CUnit の方が良い選択です (私もそれを試してから、知識に基づいた選択をすると思います)。

更新: オンライン ドキュメントが真実の半分にすぎないことを間接的に指摘してくれた @philippe に感謝します。ドキュメントの内容を明確にするサンプル コードは、チェック パッケージと共に既にインストールされています。Ubuntu の場合 /usr/share/doc/check/example/tests/

更新: コード例は、彼の最初のバージョン、次に 2 番目のバージョンなどを見ることから始められるように作成されました。そのため、彼が非常に基本的なテスト ケース/コードを何もないところから何かに役立つものまで作成する方法をたどることができます。伝統的なTTDの方法。

私のコードは壊れていたので、単体テストでこれを証明したかったので、少しごまかして、実際の pow 関数に対してテストしました。このようなもの：

ただし、将来的には、すでに標準ライブラリにあるものを再現しません:-)

関連している：

• C コードの単体テスト
• C コードのテスト方法
• C の単体テスト フレームワーク
• C のテスト フレームワーク
• 基本的な単体テストと C を始めるにはどうすればよいですか?

検索から取得[c] [unit-testing]。

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

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

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

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

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

ありがとうヨハン

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

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

C アプリケーションにチェック ユニット テスト フレームワークを使用しようとしています。しかし、次の 2 つの理由から、デバッガー (gdb) を使用できません。

• 最初に、いくつかの複雑なマクロ (START_TESTおよびEND_TEST) の使用を確認します。デバッガーは、これら 2 つのマクロの間のコードにブレークポイントを配置するのに問題があります (実際、ソフトウェア ブレークポイントを配置することはできますが、gdb には表示されません)。

• 次に、割り込みの動作を再定義して、ある種の例外を定義することを確認します。したがって、ハードウェア ブレークポイントを設定しようとすると、ハードウェア ブレークポイントはテストの失敗と見なされるため、テストは失敗して終了します。

誰かがすでにこの問題に遭遇し、解決策を持っていますか?

私は組み込みデバイス用のかなり単純なCプロジェクトを開発しています。xUnitテストを採用したいと思います。Checkフレームワーク（ http://check.sourceforge.net/ ）で落ち着きましたが、関数スタブをサポートしていないようです。数年前にスタブをサポートする非常に構文的に類似したフレームワークを使用したことを覚えていますが、その名前を思い出せません。

それで、誰かがスタブをサポートするC用のxUnitフレームワークを提案できますか？チェックライブラリを使用しながらスタブを模倣する方法もOKです。

Checkと呼ばれる C の単体テスト フレームワークを使用しようとしています。

パッケージ内のファイル INSTALL の指示に従って、パッケージをインストールしました。

1. 。/構成、設定
2. 作る
3. make check -> パッケージに付属のセルフテストを実行します (合格)。
4. インストールする

それを行った後、自分のテストを実行できなかったので、最終的に のパッケージ例を使用することにしました/usr/local/share/doc/check/example。

次のコマンドを実行しました。

それでも同じ問題：

メイクファイルにディレクトリを追加しようとしLDFLAGSましたが、それは役に立ちませんでした。また、Rick Hightower がここで行ったことを実行しようとしました (... *.so ファイル (およびそのリンク) を削除します)。リンク

Checkを使用して記述されたテストの 1 つにファイルを使用する必要があります。最初にパスをハードコーディングしましたが、うまくいきました。ただし、コードがソース ディレクトリの外でビルドされている場合、これは機能しませんでした。私は次の解決策を思いつきました。(次に、パス名の前に を付けますTESTS_DIR)

残念ながら、これは で再び失敗しmake distcheckます。特定のパスのレイアウトと構造を投稿できますが、これらすべての場合にソース ディレクトリ内のファイルを参照する「簡単な」方法があるかどうか疑問に思っています。ありがとう！

更新:絶対パスを使用しようとしましたが$abs_top_srcdir、で定義を更新しようとしたときに設定されていないようですconfigure.ac。それがなぜなのかについての考えをいただければ幸いです。

クロスコンパイルも必要な組み込みデバイスのユニットテストフレームワークとしてチェックを使用した人はいますか?

それは良い考えですか、それとも何か他のもの (embunit など) を使用する必要がありますか?

その場合、Makefile.ams と configure.ac はどのように記述すればよいですか? そもそもautotoolsを使用していないため、このクロスコンパイルのすべては確かに役に立ちません...

1 つまたは 2 つの環境でしかコンパイルしないため、実際の構成チェックをすべてスキップすることもできますが、ターゲットへのコンパイル チェックは必要ですか? 実際のフレームワークをテスト コードにリンクする方法が説明からわかりません。

必要な最小限のファイルは何ですか? 例はすべての構成を行いますが、何を省略できるかわかりません。

テストコードに*.cを超えるファイルがある場合、Check makefile.amの記述方法を知っている人はいますか？例：

これは私のmakefile.amです：

私はこれを言っているエラーを受け取りました：

コンパイルコードをリンクできないようです。libクラスを間違って指定しましたか、それとも単一のクラスファイルのみが必要ですか？

アップデート

からmakefile.amを編集して解決します

に

フラグ付きのチェック ユニット テスト フレームワークを使用してテストをコンパイルしようとすると、奇妙な構文エラーが発生します。-std=c99

だから、私はコンパイルしようとしていますexample.c：

autotools を使用して、次のようにしMakefile.amます。

とconfigure.ac:

ただし、この奇妙なエラーが発生します。

そのため、構文エラーが見つかりましたfail()（チェックはマクロとして実装されていると思います）。-std=c99フラグを削除すると、構文エラーがなくなり、正常に動作します。

これを修正する方法はありますか？私は間違いなく、可変引数マクロの-std=c99使用 (およびcheck.hの使用) がコンパイラーによって許可されるようにしたいと考えています。

Check for Cを使用してユニットテストを始めたばかりです。

これは単体テスト理論の問題です。シリアル プロトコルとの間でメッセージをフォーマットするコードのモジュールがあるとしましょう (これは本当です)。これらのメッセージを送受信するステート マシンを実装する別のモジュールがあります。

メッセージ送信機能と解析機能の単体テストを書き始めており、ステート マシンのテストも書く予定です。いずれの場合も、モック/スタブを使用して他のモジュールを偽装しています (ここでユニット テストの専門用語を誤用していたら申し訳ありません)。

2 つのモジュールを一緒にテストすることも良い考えですか? そこで、実際のプロトコル エンジンを使用して実際のステート マシンを構築し、それをワイヤ レベルのメッセージで駆動して、適切な状態遷移とメッセージが出力されるかどうかを確認しました。

理論的には、これはすでに個々のテストでカバーされています..

いくつかの一般的な手がかりを探していますが、これを感じるにはまだ十分な経験がありません.