非同期 I/O 用の libevent ライブラリを使用してイベント ドリブン アプリケーションを作成しています。基本的に、アプリケーションには、ポートでデータをリッスンする evconnlistener があります。データを受信すると、データ ペイロードに応じて、対応する http REST エンド ポイントにデータが転送されます。転送コンポーネントは libevent が提供する evhttp_* を使用します。
アプリケーションの健全性を満たすためにアプリケーションを外部プロセスとしてテストすることはできますが、コード カバレッジ レポートの生成に関しては困惑しています。cppunit などの通常の単体テスト フレームワークを介して呼び出すことができる単体テストを作成するにはどうすればよいですか?
非同期 I/O 呼び出しの周りにラッパー レイヤーを追加します。次に、「MockIO」クラスを代用して、I/O 接続の処理に関するテストをフィードできます。
単体テストよりも統合について説明しているように思えます。単体テストとは、実際には個々のモジュールを個別にテストすることであり、すべてを組み合わせてシステム機能を提供する方法ではありません。
1 つの単体テストでは、データが I/O イベントから受信されたことを確認します。別のテストでは、REST エンドポイントに供給されたデータが適切に受信されたことを確認します。別の別のテストでは、REST エンドポイントが必要に応じて解析していることを確認します。I/O イベント テストに関しては、I/O 障害、切断された接続、およびその他の望ましくないパスをシミュレートするための単体テストを追加して、例外処理コードが適切に機能していること、およびその中のすべてのコード行が確実に機能していることを確認します。モジュールがテストされました。同様に、あらゆる種類の不適切な入力を使用してエンドポイントをテストします: null ポインター、空のバッファー、非常に長いバッファー、予期しないデータ型、メソッドを介してすべてのパスを実行するために必要なさまざまなテスト。
単体テストで完全なコード カバレッジを実現するよう努めています (ただし、常に達成できるわけではありません)。統合テストでは、ピースがうまく組み合わされていることが示されていますが、すべての相互作用を常にテストできるわけではありません。大前提として、単体テストに合格すれば、実行内容に関係なく、各部分がうまく連携して動作するはずです。
自動化された単体テストの全体像を把握することで、「困った」段階を突破するのに本が役立つのではないかと考えています。既存のプロジェクトに単体テストを追加しようとしている場合は、Michael Feathers の書籍 Working Effectively with Legacy Code が非常に優れています (Mike は CppUnit の著者です)。 Roy Osherove による Unit Testing はよく読んでいます。単体テストのアイデアを理解したら、Gerard Meszaros による xUnit Test Patterns は、保守可能なテストの作成方法を学ぶのに役立つ優れたリソースです。
機会があれば、メンターから学ぶ質の高い時間を過ごしてください。