1

Linux でバックグラウンド サービスとして実行するプログラムを作成しています。私はC++で書いており、イベントループにglibmmを使用しています。

プログラムが持つ唯一のユーザー インターフェイスは、D-Bus サービスです。

Google Test を使用していくつかのテストを書きたいと思います。私が計画しているのは、プログラム自体が D-Bus サービスをインスタンス化する一方で、テスト コードも D-Bus クライアントをインスタンス化し、D-Bus 呼び出しを介してプログラムでアクションを開始することです。

私が念頭に置いているテスト ケースは、ほとんどの場合、「D-Bus メソッドを呼び出し、アサートを使用して、特定の引数でメソッドが呼び出されることを確認する」のようなものです。テストの重要な結果の 1 つは、テストがクラッシュしないことを確認することでもあります。

プログラムとテストの書き方に関する重大なオプションが表示されます。たとえば、理論的には、イベント ループを main() で 1 回作成するか、各テスト ケースで個別に作成することができます。一度だけ作成された場合でも、理論的には継続的に実行するか、各テスト ケースで開始および停止することができます。例をグーグルで検索してみましたが、Glib の代わりに Qt が使用されているものしか見つかりませんでした。それが大きな違いを生むかどうかはわかりません。

このようなケースについて、既存の知恵はありますか? 試す価値のあるものとそうでないものは何ですか？それとも、Google Test を本来の目的ではないものに使用するつもりですか?

4

1 に答える 1

1

C++ インターフェイスを使用してサーバーをライブラリとして構築し、通常の単体テストを使用してテストする方が簡単な場合があります。D-Bus を介してそれを公開するシム層は非常に薄く、広範なテストを必要としません。

D-Bus サービスをテストしたい場合は、(D-Bus クライアントとサーバーが同じプロセスで実行されるように) テスト プログラムにコンパイルする方がおそらく簡単なので、処理について心配する必要はありません。サブプロセスとしてのサーバー (これにより、複雑さが増し、デバッグの失敗がより複雑になります)。

次に、D-Bus サービスを 1 つのスレッドで実行し、D-Bus クライアント + テスト コードを別のスレッドで実行して、相互にブロックされないようにします。

通常、各テストの後にメイン コンテキストとメイン ループ (およびその他のコンテキスト) を破棄して、あるテストの状態が次のテストに影響を与えないようにする方が安全です。特に、GSourceあるテストで残った s がGMainContext次のテストで発火し続けることが問題の原因となることがよくあります。

これが Google Test の使用にどのように変換されるかについてはコメントできません。通常のGLib 単体テスト APIでそれを行うことは確かに可能です。

于 2020-10-28T10:05:58.790 に答える