👩🏼‍🎨 🌽 👨🏼 CxxMock-アクションの原則 🤚 🏡 🎢

製品のアーキテクチャを調べて、それがどのように機能するかを見ることが面白い場合があります。時計を分解することはできましたが、元に戻すことはできません...しかし、時計とは異なり、ソースにアクセスするときにソフトウェア製品を分解して組み立てることができます。そして、解決策はすでに実践に適用されていることがわかりました。

CxxMock-C ++でのモックオブジェクトの記事で書いたCxxMockを作成する必要があるとき、同様のGoogleMockの動作原理を調べました。またはそれ以前に、c10kサーバーmathopdの基本的なアイデアを見つけました。これにより、その後のプロジェクトで、アーキテクチャの設計を改善することができました。

したがって、基本的な概念と、CxxMockが機能する原因について説明します。そして、これは思い付くのが面白かったです。他の人があなたの練習であなたを助ける間、いくつかのトリックは簡単であると思うかもしれません。

CxxMockインサイドルック

スピーチが行われる興味深い決定：

反射があるかのように振る舞う模倣
オーバーヘッドのない施設の工場の登録。
インターフェイスの目的の実装を作成します。
プログラミングメソッドの動作。
メソッド実行制御
引数の比較。
カスタムメソッドの実行。

反射があるかのように振る舞う模倣

C＃にはリフレクションがあり、C ++にはリフレクションがありませんが、タイプの識別に役立つRTTIがありますが、プログラムの実行中にメソッドを呼び出したり、クラスを動的に構築することはできません。つまり、何かを作成するには、コンパイル時にすでに存在している必要があり、CxxMockカーネルは作成する必要があるものとその作成方法を知っている必要があります。これを実現するには、CxxTestがテスト用の目次を作成し、Qtがすべての信号とスロットへのリンクを含むQMetaOBjectを作成するのと同じ方法でコードパーサーを使用できます。 CxxMockの場合、CxxTestの概念に準拠し、あらゆる種類の恐ろしい正規表現と、そのような場合を考慮して括弧を解析するアルゴリズムを使用して、Pythonでジェネレーターを作成する必要がありました。

namespace NS4 { namespace NS5 { class Interface { public: virtual void method(int a)=0; virtual Type* method2(const Type& a)=0; virtual ~Interface(){}; }; }}

出力で、ジェネレーターは、インターフェイスを実装するクラス（クラス）でヘッダーファイルを作成します

 namespace NS4 { namespace NS5 { class CXXMOCK_DECL( Interface ) { public: virtual int method(int a) { CXXMOCK( int, a ) } virtual Type* method2(const Type& a){ return CXXMOCK( Type*, a ) } virtual ~Interface(){}; }; CXXMOCK_IMPL( Interface ) }}

つまり、手動で記述でき、IDEのほぼすべての構文パーサーで解析できる非常に読みやすいコードです。最初のバージョンは、そのようなクラスを手動で作成することにより行われました。

オーバーヘッドのない工場の登録

額に近づくと、setUp（）のある時点でクラスごとにインターフェイスの特別な実装を持つか、すぐに次のようなコードを記述します。

 cxxmock::Repository::instance().registerFactory<Interface>( new MockFactory<Interface, InterfaceImpl>() ); cxxmock::Repository::instance().registerFactory<Interface2>( new MockFactory<Interface2, Interface2Impl>() ); ...

同意する必要があります。インターフェイスの名前を10回繰り返すのはあまり便利ではありません。このコードが自動的に作成された場合でも、どこに挿入する必要がありますか？

制限があります：

ほとんどの場合、CxxTestを使用する場合、main（）関数を手動で書き換える必要はありません。つまり、コードを挿入できません。
ただし、各テストセットの各setUp（）メソッドに登録することも、＃includeディレクティブを介して目次を接続することも便利ではありません。
そして、クラスが宣言されているのと同じ場所でコードを実行することは、一見不可能です

しかし、できないが、本当にしたいときは、できます。この目的のためにマクロ呼び出しが使用されます。

 CXXMOCK_IMPL( Interface )

このマクロは、静的変数（インターフェイスで入力されたコンテナと作成されたクラス）の作成を担当します。

 #define CXXMOCK_IMPL( interface ) CxxMock::Container<interface, cxxmocks_impl_##interface> cxxmocks_instance_##interface;

C ++では、ANSI Cと同様に、ライブラリをメモリにロードするときに、main（）および_init（）を開始する前でも、すべての静的変数とグローバル変数が最初に初期化されます。 CXXMOCK_IMPLで宣言された変数はクラスのインスタンスであるため、特定のインターフェイスを実装するオブジェクトを作成できるコンテナがあることをレジストリに伝えることができるコンストラクタが呼び出されます。

 template<class Interface, class Impl> Container<Interface, Impl>::Container() { Repository::instance().registerFactory( this ); }

コンテナの主な目的は、インターフェイスとそのクラススタブの対応に関する情報を格納することですが、クラスのインスタンスを作成するためのファクトリメソッドがあり、ファクトリから継承されます。

 template<class Interface, class Impl> Interface* Container<Interface, Impl>::create(){ return new Impl(); }

したがって、さらにファクトリと呼ばれます。

もちろん、グローバル変数の初期化の順序は定義されていませんが、コンテナリポジトリ（ファクトリ）の遅延初期化を使用しているため、グローバル変数を作成する順序は重要ではありません。したがって、一連の単体テストの実行が開始されると、CxxMockは単体テストに必要なインターフェイスを実装するすべてのクラスを認識します。

適切な実装の作成

何かを作成するには、何を作成するかを知って、必要なものを作成する方法を知っている人を見つける必要があります。

.NETでは、次のように簡単に記述できます。

 _registry[ typeof( factory ) ] = factory;

C ++の場合、RTTIでマジックを適用する必要があります。

 template<class T> void Repository::registerFactory(Factory<T>* factory) { string tname = typeid( typename Factory<T>::TargetType ).name(); _registry[ tname ] = factory; }

_registryは通常のstd :: map <string、Handle *>であり、Handle（ファクトリーの基本クラス）へのポインターを使用してdynamic_castが機能するようにします。

ファクトリがレジストリに登録されたら、リポジトリにインターフェイスのスタブオブジェクトの実装を作成するように依頼できます。

 template<class T> T* Repository::create() { RepositoryTypeMap::iterator it = _registry.find( typeid(T).name() ); ... return dynamic_cast< Factory<T>* >(&(*it->second))->create(); }

ここでは、HandleからFactory *に型をキャストするトリックを適用します。コレクションにあるのは、Handleクラスのみを共有する完全に異なる型のファクトリです。

プログラミング方法の動作

メソッドの動作のプログラミングはCxxMockの最も重要な部分です。IDEが必要なすべての引数を強調表示するようにインターフェイスメソッドを明示的に呼び出す必要がありますが、この特定の呼び出しに関するパラメーターをCxxMockに伝える必要があるためです。

理想的には次のようになります（Rhino.Mocks、C＃）：

 Expect.Call( mock->method( 5 ) ).returns( 10 ); Expect.Call( ()=> { mock->voidMethod( 5 ); } ).repeat.any;

実際、ここでは2つの呼び出しが発生します。

まず、インターフェイスメソッドmock-> method（）が正直に呼び出され、次に
結果は、何であれExpect.Call（）呼び出しに渡され、呼び出し情報を含むCalllInfo構造体が返されます。

Rhino.Mocksは、現在のコンテキストとアクティブなMockRepositoryについて「」を知っているExpectクラスも使用します。

C ++バージョンの場合、同様のトリックを適用しました。

  TS_EXPECT_CALL( mock->method(10) ).returns(5);

ただし、呼び出しが非表示になった互換性のあるCxxTest署名でマクロTS_EXPECT_CALLを使用します。

  CxxMock::Repository::instance().expectCall( mock->method(10) )

ここでのRhino.Mocksとの違いは、最初のケースではリポジトリインスタンス（MocksRepository）へのアクセスを隠すために追加のクラスが使用されず、2番目ではmethod（）メソッドが呼び出される方法をマスクする機会があることです。

callInfo構造体がexpectCall（）からの参照によって返された後、オブジェクトを設定する通常の作業が発生します。

引数を渡す

メソッドが呼び出された引数を書き留め、戻り値が保存されて返されるようにすることに関する興味深い質問。引数を保存し、それらと比較する必要があります。

CxxMockには混合ソリューションがあります。

1.自動生成プログラムは、CXXMOCKマクロを使用してクラスを作成します。これにより、手動モードでの使用が簡単になります。

 int method(int a) { return CXXMOCK(int, a); }

2. CXXMOCKマクロは、オーバーロードされたメソッドcxxmock_object.mock（MOCK_FUNCID、args）を呼び出します。 C＃のAction <>（最大10個の引数）に似た任意のタイピングがあり、CxxMockカーネルにメソッド名の文字列表現を伝えます。呼び出されたメソッドとそのシグネチャを正確に知ることが重要であり、C ++が純粋な純粋メソッドをオーバーロードできるため、__ PRETTY_FUNCTION__または__FUNCDNAME__を実装するMOCK_FUNCIDマクロを使用して、完全なメソッドシグネチャを呼び出すことによる登録が使用されますコンパイラについて。

 template <typename R, typename A1, typename A2> R MockObject::mock( const std::string& funcname, A1 a1, A2 a2) { // processCall()  :     . return this->processCall<R>( method(funcname).arg( a1 ).arg( a2 ) ); } CallInfo& MockObject::method( std::string funcname ) { CallInfoPtr ptr = new CallInfo(funcname); Repository::instance().setLastCall( ptr ); return *ptr; }

オーバーロードされたメソッド内で、すべての引数が実際に登録され、CallInfo構造がさらに構成するために形成されます

googlemockソリューションとは異なり、ここでは、各呼び出しのMockObject :: mock（）メソッドは、呼び出しに関するすべての情報が書き込まれる同じCallInfo構造を形成します。メソッドの引数は、クラスファクトリの場合と同じ方法で保存されます。

 template<typename A> CallInfo& CallInfo::arg(const A value ) { inValues[ inValues.size() ] = new Argument<A>(value); return *this; }

その後、再生モードでは、すべてのArgument実装に対して統一されたIArgumentインターフェイスを使用して、引数のコレクションの単純な比較が実行されます。

引数の比較

引数の比較は非常に簡単です。これを行うには、予想される値を取得し、ユーザーインターフェイス呼び出しに来た値と比較します。また、多くの比較オプションがあるため、ここではすべてのタイプを比較するためにCxxTest機能を使用します。彼にはこの機会があります。

 template<typename T> bool Argument<T>::compare( const IArgument& other ) const { const Argument<T> *arg = dynamic_cast< const Argument<T>* >( &other ); return CxxTest::equals( Value, arg->Value); }

より深刻な問題は、次のような適切なエラーメッセージを形成するために、値の文字列表現を取得することでした。

呼び出し予定：インターフェイス::メソッド（5）

実際の呼び出し：Interace :: method2（6）

開発者は自分のデータ型を適用でき、テストに何らかのフレームワークを使用する場合は、余分なものを記述しないでください。したがって、CxxTestもここに適用されます。

 template<typename TVal> std::string convertToString(TVal arg ) const { return CxxTest::ValueTraits<T>( Value ).asString(); } const std::string toString() const { return convertToString( Value ); }

これら2つのことを行うことが、CxxTestとの統合が実際に使用される唯一の場所です。

カスタムメソッドの実行

カスタムメソッドを実行するには、いくつかの条件が必要です。

メソッドを正しく呼び出すためには、呼び出す必要があるメソッドとそのタイプに関する情報を保存する必要があります。
引数の数に関係なく、ユーザーメソッド呼び出しを等しく呼び出す必要があります。
厳密な型指定を考えると、可変数の引数があるかのようにメソッド呼び出しを作成する必要があります。

メソッドに関する情報を保存するには、入力で受け取った関数へのポインターを格納するテンプレートクラスを作成します。

 template< typename Sender, typename T> CallInfo& action( Sender* sender, T method ) { _action = new Action<Sender, T>(sender, method ); return *this; }

「何がわからない」を呼び出すために、インターフェイス（IAction）を実装するプロキシメソッドを適用しますが、その内部でユーザーメソッドを呼び出すための特定の戦略を実装するテンプレートメソッドを呼び出します。

 template< typename Sender, typename T> class Action : public IAction { Sender* _sender; T _method; ... //  template<typename R, typename A> void callMethod(IArgumentPtr result, const ArgList& args, R (Sender::*method)(A)){ result->setValue(Argument<R>((_sender->*_method)( args.val<A>(0) )) ); } ... void call(IArgumentPtr result, const ArgList& args) { callMethod(result, args, _method ); } }

各テンプレート実装では、ユーザーメソッドの署名を明示的に示しているため、callMethod（）の時点で、タイプTはタイプR（Sender :: * method）（A）に分解されます。これにより、コールの特定のバージョンを個別に処理できます。また、メソッド呼び出しを登録するのと同じ方法でユーザーメソッドへの呼び出しを作成します。

「インターフェイスから継承されたテンプレート」ソリューションを使用するため、多くのサービスクラスを作成する必要はありません。呼び出し戦略の実装でメソッドの多くのバージョンを作成するだけで十分です。これは、可変数の引数を持つメソッド呼び出しをシミュレートします。

おわりに

適用されるトリックの主なポイント：

単純なテキストでも、本当にしたいときに「リフレクション」を模倣することができます
オブジェクトのコンストラクターを使用して、制御をmain（）に渡す前に任意のコードを実行できます。
テンプレートクラスを共通のポイントにバインドするには、インターフェイスを継承する必要があります。dynamic_castは、必要に応じて残りを実行します。
グローバルコンテキスト（Expect.Call（...））を暗黙的に使用して、シーケンスチェーンを構築できます。
多数のオーバーロードされたメソッドと引数コンテナーのコレクションにより、独自のバージョンのRPCまたは引数リストの比較タスクを簡単に作成できます。
自分ですべてを行う必要はありません。プラットフォームがこの機会をすでに提供している場合もあります
テンプレート内の複合型は、より単純な型に分解できます。これにより、実装方法をより正確に選択できます

これはおそらく、この単純なCxxMockライブラリで使用されるすべての主なトリックです。メインコードはわずか15kbですが、開発者とIDEの生活を大幅に簡素化できます。

すべてがSourceForgeとGitHubにあります。

ご清聴ありがとうございました。

参照資料

何を読む

DAOプログラミングを理解するために、以下もお勧めします。

マイヤーズ・スコット。 C ++の効果的な使用。 55プログラムの構造とコードを改善する確かな方法
ジョン・ベントレープログラミングの真珠

CxxMock-アクションの原則