この質問は、サイトの Q&A 基準の一部に違反している可能性があると思います。私が受け取る回答は意見に基づくものと見なされる可能性があるためです。とはいえ、このまま…。
CMake を使用してビルド/テスト/パッケージ化プロセスを駆動し、GTest と GMock をテスト用に使用して、C++ プロジェクトに取り組んでいるとします。さらに、プロジェクトの構造が次のようになっているとします。
cool_project
|
|-- source
| |
| |-- module_foo
| | |
| | |-- (bunch of source files)
| |
| |-- module_bar
| |
| |-- (yet more source files)
|
|-- tests
|
|-- module_foo
| |
| |-- (tests for module_foo)
|
|-- module_bar
|
|-- (tests for module_bar)
もちろん、これは単純化しすぎた状況ですが、その考えは理解できます。
これらのモジュールがライブラリであり、すべてのテスト (つまり、 の下のすべてのディレクトリtests) が実行可能である場合、後者を前者とリンクする必要があります。問題は、これらのライブラリが共有されている場合、ローダーはもちろんそれらを見つける必要があるということです。明らかな解決策は、CMake の を使用して、テストの作業ディレクトリをライブラリのディレクトリに設定することset_propertyです。ただし、GTest と GMock の両方が共有ライブラリとしてビルドされている場合、それらもロードする必要があるため、これは機能しません。
私が思いついた解決策は次のとおりです。
- 両方のライブラリ (つまり、GTest と GMock) をモジュールのビルド ディレクトリにコピーします。共有ライブラリの主な利点 (つまり、プログラム間でコードを共有すること) が完全にバイパスされ、ビルド ディレクトリ全体にこれらのコピーが複数存在することになるため、これはちょっとばかげているように感じます。
- 代わりに、GTest と GMock の両方を静的ライブラリとしてビルドします。これは、両方のライブラリのコピーがすべての実行可能ファイルに含まれることになり、サイズが大きくなることを意味します。1000回のテストはありませんが、これはなんとなくぎこちなく感じます。
ですから、この状況を考えると、誰かがこれに襲われたことがあるかどうか、そして彼/彼女がどのような道をたどったかを知りたいです. make && make test（解決策が私が言及したものと異なる場合は、喜んですべてを聞いてください。）理想的には、何も実行することなく、すべてのテストを実行できる立場になりたいです。物事に対応するための追加のスクリプト。すべてのライブラリを静的ライブラリとして構築することでうまくいきますが、代わりに共有ライブラリとして構築するとどうなるでしょうか? それらを 2 回ビルドする必要がありますか? それはばかげている。
もう 1 つの問題も同様ですが、その解決には再設計または同様のアーティファクトが必要だと思います。module_fooたとえば、サードパーティのライブラリに依存しているとしましょうlibrary_baz。module_fooに直接リンクしている場合、関係のない機能をテストしている可能性があるとしてもlibrary_baz、前者のテストは をロードする必要があります。library_baz同じ問題が発生します。
ここでモッキングを行うのは正しいことのように思えますが、インターフェイスと対話するためにリファクタリングするのはあまり意味がないと感じていmodule_fooます (動的ポリモーフィズムまたは静的ポリモーフィズムのいずれかによって)。そのような柔軟性：library_baz仕事をします。「確かに、今日は柔軟性は必要ありませんが、明日は誰にもわかりません」と言う人もいると思います。システムが遭遇する可能性のあるすべてのシナリオをプレビューしようとすると、直感に反するように思えますが、繰り返しになりますが、私よりもはるかに経験豊富な人がいます。
何かご意見は？