Google Mock(Gmock)简单使用和源码分析——源码分析
源碼分析
? ? ? ? 通過《Google Mock(Gmock)簡單使用和源碼分析——簡單使用》中的例子,我們發現被mock的相關方法在mock類中已經被重新實現了,否則它們也不會按照我們的期待的行為執行。我們通過閱讀源碼,來分析整個過程的實現邏輯。(轉載請指明出于breaksoftware的csdn博客)
MOCK_METHOD系列宏
? ? ? ? 首先我們以MOCK_METHOD0為例
#define MOCK_METHOD0(m, ...) GMOCK_METHOD0_(, , , m, __VA_ARGS__)
? ? ? ? 可以看到它實際上封裝了GMOCK_METHOD0_。我們在介紹GMOCK_METHOD0_之前,還可以看到其他無參數的宏
#define MOCK_CONST_METHOD0(m, ...) GMOCK_METHOD0_(, const, , m, __VA_ARGS__)
……
#define MOCK_METHOD0_T(m, ...) GMOCK_METHOD0_(typename, , , m, __VA_ARGS__)
……
#define MOCK_CONST_METHOD0_T(m, ...) \GMOCK_METHOD0_(typename, const, , m, __VA_ARGS__)
……
#define MOCK_METHOD0_WITH_CALLTYPE(ct, m, ...) \GMOCK_METHOD0_(, , ct, m, __VA_ARGS__)
……
#define MOCK_CONST_METHOD0_WITH_CALLTYPE(ct, m, ...) \GMOCK_METHOD0_(, const, ct, m, __VA_ARGS__)
……
#define MOCK_METHOD0_T_WITH_CALLTYPE(ct, m, ...) \GMOCK_METHOD0_(typename, , ct, m, __VA_ARGS__)
……
#define MOCK_CONST_METHOD0_T_WITH_CALLTYPE(ct, m, ...) \GMOCK_METHOD0_(typename, const, ct, m, __VA_ARGS__)
……
? ? ? ? 這些無參數的宏宏都是基于GMOCK_METHOD0_實現的,它們的差別只是不同參數的組合。這兒要列出它們是因為GMOCK_METHOD0_的定義比較晦澀,通過這些醒目的定義,我們將會發現其各個參數的作用。
// INTERNAL IMPLEMENTATION - DON'T USE IN USER CODE!!!
#define GMOCK_METHOD0_(tn, constness, ct, Method, ...) \GMOCK_RESULT_(tn, __VA_ARGS__) ct Method( \) constness { \GTEST_COMPILE_ASSERT_((::testing::tuple_size< \tn ::testing::internal::Function<__VA_ARGS__>::ArgumentTuple>::value \== 0), \this_method_does_not_take_0_arguments); \GMOCK_MOCKER_(0, constness, Method).SetOwnerAndName(this, #Method); \return GMOCK_MOCKER_(0, constness, Method).Invoke(); \} \::testing::MockSpec<__VA_ARGS__>& \gmock_##Method() constness { \GMOCK_MOCKER_(0, constness, Method).RegisterOwner(this); \return GMOCK_MOCKER_(0, constness, Method).With(); \} \mutable ::testing::FunctionMocker<__VA_ARGS__> GMOCK_MOCKER_(0, constness, \Method)
? ? ? ? 上面宏中的tn可以通過之前的調用發現其應該是typename這類用于定義模板的關鍵字。constness表示mock的方法是不是const類型的。ct是調用約定,比如我們在windows程序里經常見到的STDMETHODCALLTYPE。Method是被mock的函數名。不定參數則是函數指針類型。這兒比較有意思的是不定參數,因為作為一個框架,它需要支持各種類型的函數,而我們不可能把所有類型一一進行羅列。這個時候我們就可以使用不定參數來解決這個問題。
? ? ? ? 我們先總覽一下GMOCK_METHOD0_的實現。上述代碼第17行定義了一個具有mutable屬性的變量,之所以使用mutable是因為它可能會被使用在const類型的函數中,然而該對象的方法并不一定是const的。這個參數的名稱使用GMOCK_MOCKER_宏組裝
#define GMOCK_MOCKER_(arity, constness, Method) \GTEST_CONCAT_TOKEN_(gmock##constness##arity##_##Method##_, __LINE__)#define GTEST_CONCAT_TOKEN_(foo, bar) GTEST_CONCAT_TOKEN_IMPL_(foo, bar)
#define GTEST_CONCAT_TOKEN_IMPL_(foo, bar) foo ## bar
? ? ? ? 可以見得該參數名包括了gmock關鍵字、是否有const屬性、參數個數、方法名已經所在的行號組成。這樣就盡可能的保證該變量在同一個文件中的唯一性。
? ? ? ? 該變量的類型是一個以函數類型為模板參數的對象,其模板類的定義是
template <typename R>
class FunctionMocker<R()> : publicinternal::FunctionMockerBase<R()> {public:typedef R F();typedef typename internal::Function<F>::ArgumentTuple ArgumentTuple;MockSpec<F>& With() {return this->current_spec();}R Invoke() {// Even though gcc and MSVC don't enforce it, 'this->' is required// by the C++ standard [14.6.4] here, as the base class type is// dependent on the template argument (and thus shouldn't be// looked into when resolving InvokeWith).return this->InvokeWith(ArgumentTuple());}
};
? ? ? ? 該模板類定義的模板類型就是函數的返回值類型——R。比如例子中Online方法,它被mock之后,傳導到該類的R就是bool。上面代碼中05行使用返回類型重新定義了函數類型為F()。06行別名了用于保存函數參數的元組類型為ArgumentTuple。08行定義的With函數是用于對參數的篩選。于是我們是以無參數函數為例,所以該處沒有設定參數預期。12行是我們mock函數的真實實現。這些內容我們將在之后詳細講解,我們再回到GMOCK_METHOD0_的定義上
GMOCK_RESULT_(tn, __VA_ARGS__) ct Method( \) constness { \GTEST_COMPILE_ASSERT_((::testing::tuple_size< \tn ::testing::internal::Function<__VA_ARGS__>::ArgumentTuple>::value \== 0), \this_method_does_not_take_0_arguments); \GMOCK_MOCKER_(0, constness, Method).SetOwnerAndName(this, #Method); \return GMOCK_MOCKER_(0, constness, Method).Invoke(); \} \
? ? ? ??GMOCK_RESULT_宏定義了mock函數的返回類型
#define GMOCK_RESULT_(tn, ...) \tn ::testing::internal::Function<__VA_ARGS__>::Resulttemplate <typename R>
struct Function<R()> {typedef R Result;typedef ::testing::tuple<> ArgumentTuple;typedef typename MatcherTuple<ArgumentTuple>::type ArgumentMatcherTuple;typedef void MakeResultVoid();typedef IgnoredValue MakeResultIgnoredValue();
};
? ? ? ? 這么定義的一個優點就是可以通過模板將函數類型的定義中的返回類型給拆出來。這和FunctionMocker定義方式是一樣的。
? ? ? ??GTEST_COMPILE_ASSERT_宏用于檢測定義的參數個數是否符合規定。檢測完之后,使用FunctionMocker模板類對象的SetOwnerAndName方法將對象指針和方法名傳遞到底層邏輯中。最后就會調用FunctionMocker模板類對象的Invoke方法實現函數行為邏輯的調用。
? ? ? ??GMOCK_METHOD0_中還定義了另一個方法
::testing::MockSpec<__VA_ARGS__>& \gmock_##Method() constness { \GMOCK_MOCKER_(0, constness, Method).RegisterOwner(this); \return GMOCK_MOCKER_(0, constness, Method).With(); \} \
? ? ? ? 它使用了gmock和函數名組合成為一個新的函數。該函數內部通過FunctionMocker模板類對象的RegisterOwner方法保存了對象指針,最后返回了MockSpec模板對象。MockSpec模板對象在之前我們見過,它是為了實現參數篩選而設計的。其具體實現我們在之后會分析。
? ? ? ? 無參數的版本忽略了很多函數參數的問題,但是其讓我們可以清晰的看見實現的脈絡。現在我們將以有兩個參數的版本來講解其實現。
// INTERNAL IMPLEMENTATION - DON'T USE IN USER CODE!!!
#define GMOCK_METHOD2_(tn, constness, ct, Method, ...) \GMOCK_RESULT_(tn, __VA_ARGS__) ct Method( \GMOCK_ARG_(tn, 1, __VA_ARGS__) gmock_a1, \GMOCK_ARG_(tn, 2, __VA_ARGS__) gmock_a2) constness { \GTEST_COMPILE_ASSERT_((::testing::tuple_size< \tn ::testing::internal::Function<__VA_ARGS__>::ArgumentTuple>::value \== 2), \this_method_does_not_take_2_arguments); \GMOCK_MOCKER_(2, constness, Method).SetOwnerAndName(this, #Method); \return GMOCK_MOCKER_(2, constness, Method).Invoke(gmock_a1, gmock_a2); \} \::testing::MockSpec<__VA_ARGS__>& \gmock_##Method(GMOCK_MATCHER_(tn, 1, __VA_ARGS__) gmock_a1, \GMOCK_MATCHER_(tn, 2, __VA_ARGS__) gmock_a2) constness { \GMOCK_MOCKER_(2, constness, Method).RegisterOwner(this); \return GMOCK_MOCKER_(2, constness, Method).With(gmock_a1, gmock_a2); \} \mutable ::testing::FunctionMocker<__VA_ARGS__> GMOCK_MOCKER_(2, constness, \Method)
? ? ? ? 上例中,我們發現相關函數的定義多了兩個參數聲明。我們先看和mock函數同名的函數的參數定義,它使用了GMOCK_ARG_宏指定參數類型
#define GMOCK_ARG_(tn, N, ...) \tn ::testing::internal::Function<__VA_ARGS__>::Argument##N
? ? ? ? Function模板類在之前我們反復見過,它的一個非常大的作用就是從函數類型中拆分出函數返回值類型和各個參數類型。因為之前以無參數函數為例,所以我們并沒有欣賞到它的妙處。
template <typename R, typename A1>
struct Function<R(A1)>: Function<R()> {typedef A1 Argument1;typedef ::testing::tuple<A1> ArgumentTuple;typedef typename MatcherTuple<ArgumentTuple>::type ArgumentMatcherTuple;typedef void MakeResultVoid(A1);typedef IgnoredValue MakeResultIgnoredValue(A1);
};template <typename R, typename A1, typename A2>
struct Function<R(A1, A2)>: Function<R(A1)> {typedef A2 Argument2;typedef ::testing::tuple<A1, A2> ArgumentTuple;typedef typename MatcherTuple<ArgumentTuple>::type ArgumentMatcherTuple;typedef void MakeResultVoid(A1, A2);typedef IgnoredValue MakeResultIgnoredValue(A1, A2);
};
? ? ? ? Function模板類的兩個參數的版本繼承于一個參數的版本,一個參數版本繼承于無參數版本。這樣兩個參數版本中,它從無參數版本中繼承到了
typedef R Result;
? ? ? ? 從一個參數版本中繼承到了
typedef A1 Argument1;
? ? ? ? 而自身定義了
typedef A2 Argument2;
? ? ? ? 它還覆蓋了基類中ArgumentTuple、ArgumentMatcherTuple等的定義。
? ? ? ? 我們看到兩個參數版本的Function類的模板類型是R(A1, A2),這種方式就是函數類型的定義。而R、A1和A2是Function模板類的模板。以Login方法為例
MOCK_METHOD2(Login, bool(const std::string&, const std::string&));
? ? ? ? 編譯器將推導出R是bool,A1和A2都是const ?std::string&。這樣它便將函數返回類型和參數進行了拆分。并別名了各個類型,從而方便在之后模板中忽略具體類型。
? ? ? ?相應的FunctionMocker也是使用相同的方式實現了拆分,我們看下兩個參數版本的實現
template <typename R, typename A1, typename A2>
class FunctionMocker<R(A1, A2)> : publicinternal::FunctionMockerBase<R(A1, A2)> {public:typedef R F(A1, A2);typedef typename internal::Function<F>::ArgumentTuple ArgumentTuple;MockSpec<F>& With(const Matcher<A1>& m1, const Matcher<A2>& m2) {this->current_spec().SetMatchers(::testing::make_tuple(m1, m2));return this->current_spec();}R Invoke(A1 a1, A2 a2) {// Even though gcc and MSVC don't enforce it, 'this->' is required// by the C++ standard [14.6.4] here, as the base class type is// dependent on the template argument (and thus shouldn't be// looked into when resolving InvokeWith).return this->InvokeWith(ArgumentTuple(a1, a2));}
};
? ? ? ? 相比于無參數版本,它在With函數中使用了SetMatchers方法實現了參數限制,并在Invoke中,使用兩個參數定義了一個臨時的參數元組類型ArgumentTuple對象。這樣將參數放到一個元組對象中,是對InvokeWith方法對不同個數、不同類型、不同順序的參數調用實現統一化處理。
EXPECT_CALL、ON_CALL宏? ? ? ??
? ? ? ? 在介紹MOCK_METHOD系列宏是,我們發現其在我們mock的類中定義兩個方法和一個變量:
- GMOCK_RESULT_(tn, __VA_ARGS__) ct Method(……)
- ::testing::MockSpec<__VA_ARGS__>& gmock_##Method(……)
- mutable ::testing::FunctionMocker<__VA_ARGS__> GMOCK_MOCKER_(0, constness, Method)
? ? ? ? 1中的方法和我們希望mock的方法同名,這將方便使用者調用它。2中的函數是使用gmock和函數名聯合組裝成的新函數名,它返回了一個被參數篩選的函數對象。EXPECT_CALL和ON_CALL宏中就是調用了它。
#define GMOCK_ON_CALL_IMPL_(obj, call) \((obj).gmock_##call).InternalDefaultActionSetAt(__FILE__, __LINE__, \#obj, #call)
#define ON_CALL(obj, call) GMOCK_ON_CALL_IMPL_(obj, call)#define GMOCK_EXPECT_CALL_IMPL_(obj, call) \((obj).gmock_##call).InternalExpectedAt(__FILE__, __LINE__, #obj, #call)
#define EXPECT_CALL(obj, call) GMOCK_EXPECT_CALL_IMPL_(obj, call)
? ? ? ? 宏中((obj).gmock_##call)就是調用了2中的方法,并對返回的對象調用InternalDefaultActionSetAt或InternalExpectedAt。以下面的調用為例
EXPECT_CALL(test_user, Pay(_)).WillRepeatedly(testing::Return(true));
? ? ? ? 其最終是這樣的調用
test_user.gmock_Pay(_).InternalExpectedAt(__FILE__, __LINE__, 'test_user', 'Pay').WillRepeatedly(testing::Return(true));
? ? ? ? 下劃線_是通配符,它的定義如下
const internal::AnythingMatcher _ = {};class AnythingMatcher {public:template <typename T>operator Matcher<T>() const { return A<T>(); }
};template <typename T>
inline Matcher<T> A() { return MakeMatcher(new internal::AnyMatcherImpl<T>()); }template <typename T>
inline Matcher<T> MakeMatcher(const MatcherInterface<T>* impl) {return Matcher<T>(impl);
}
? ? ? ? 為什么任何函數的參數都可以接受AnythingMatcher。我們可以見2中參數的定義
::testing::MockSpec<__VA_ARGS__>& \gmock_##Method(GMOCK_MATCHER_(tn, 1, __VA_ARGS__) gmock_a1) constness { \GMOCK_MOCKER_(1, constness, Method).RegisterOwner(this); \return GMOCK_MOCKER_(1, constness, Method).With(gmock_a1); \} \// The matcher type for argument N of the given function type.// INTERNAL IMPLEMENTATION - DON'T USE IN USER CODE!!!#define GMOCK_MATCHER_(tn, N, ...) \const ::testing::Matcher<GMOCK_ARG_(tn, N, __VA_ARGS__)>&
? ? ? ? 函數的參數類型都是Matcher模板類,而AnythingMatcher定義了Matcher<T>()方法用于返回一個Matcher<T>對象。
參數過濾 ? ? ? ?
? ? ? ?參數過濾是Gmock非常有用的一個功能,它讓我們可以通過參數定義不同的調用場景。
? ? ? ?Gmock中提供了兩處設置參數過濾的地方,舉個例子
EXPECT_CALL(test_user, Pay(Eq(1))).With(_).WillRepeatedly(testing::Return(true));
? ? ? ?Pay中指定參數不能等于1,With則表示對參數沒有限制。這就是兩處參數約束。一般來說gmock##Method中的參數約束是針對各自參數的,而With則是關注于參數之間的關系。我們看下這兩處約束是怎么工作的。
? ? ? ? 以一個參數的版本為例,MOCK_METHOD1宏中
::testing::MockSpec<__VA_ARGS__>& \gmock_##Method(GMOCK_MATCHER_(tn, 1, __VA_ARGS__) gmock_a1) constness { \GMOCK_MOCKER_(1, constness, Method).RegisterOwner(this); \return GMOCK_MOCKER_(1, constness, Method).With(gmock_a1); \} \mutable ::testing::FunctionMocker<__VA_ARGS__> GMOCK_MOCKER_(1, constness, \Method)
? ? ? ? gmock##Method方法調用了FunctionMocker模板類的With方法,該方法返回了一個MockSpec模板對象。gmock##Method方法是在EXPECT_CALL宏中被調用的。
? ? ? ??FunctionMocker中的With是這么實現的
MockSpec<F>& With(const Matcher<A1>& m1) {this->current_spec().SetMatchers(::testing::make_tuple(m1));return this->current_spec();}
? ? ? ??current_spec()是其基類FunctionMockerBase的方法,它返回了以FunctionMocker<R(A1)> 為模板的MockSpec對象。SetMatchers方法將參數的匹配規則設置到其底層的matchers_中
void SetMatchers(const ArgumentMatcherTuple& matchers) {matchers_ = matchers;}
? ? ? ??matchers_這個匹配規則會在調用EXPECT_CALL時通過下列兩個方法保存起來
// Adds a new default action spec to the function mocker and returns// the newly created spec.internal::OnCallSpec<F>& InternalDefaultActionSetAt(const char* file, int line, const char* obj, const char* call) {LogWithLocation(internal::kInfo, file, line,string("ON_CALL(") + obj + ", " + call + ") invoked");return function_mocker_->AddNewOnCallSpec(file, line, matchers_);}// Adds a new expectation spec to the function mocker and returns// the newly created spec.internal::TypedExpectation<F>& InternalExpectedAt(const char* file, int line, const char* obj, const char* call) {const string source_text(string("EXPECT_CALL(") + obj + ", " + call + ")");LogWithLocation(internal::kInfo, file, line, source_text + " invoked");return function_mocker_->AddNewExpectation(file, line, source_text, matchers_);}
? ? ? ? 具體的保存邏輯是
// Adds and returns a default action spec for this mock function.OnCallSpec<F>& AddNewOnCallSpec(const char* file, int line,const ArgumentMatcherTuple& m)GTEST_LOCK_EXCLUDED_(g_gmock_mutex) {Mock::RegisterUseByOnCallOrExpectCall(MockObject(), file, line);OnCallSpec<F>* const on_call_spec = new OnCallSpec<F>(file, line, m);untyped_on_call_specs_.push_back(on_call_spec);return *on_call_spec;}// Adds and returns an expectation spec for this mock function.TypedExpectation<F>& AddNewExpectation(const char* file,int line,const string& source_text,const ArgumentMatcherTuple& m)GTEST_LOCK_EXCLUDED_(g_gmock_mutex) {Mock::RegisterUseByOnCallOrExpectCall(MockObject(), file, line);TypedExpectation<F>* const expectation =new TypedExpectation<F>(this, file, line, source_text, m);const linked_ptr<ExpectationBase> untyped_expectation(expectation);untyped_expectations_.push_back(untyped_expectation);// Adds this expectation into the implicit sequence if there is one.Sequence* const implicit_sequence = g_gmock_implicit_sequence.get();if (implicit_sequence != NULL) {implicit_sequence->AddExpectation(Expectation(untyped_expectation));}return *expectation;}
? ? ? ? 即以該規則為參數,新建了OnCallSpec<F>或TypedExpectation<F>對象,這兩個對象將會被保存到各自的vector中。當mock的函數被調用時,Gmock將通過下面兩個函數之一去檢測參數是否匹配
// Returns the ON_CALL spec that matches this mock function with the// given arguments; returns NULL if no matching ON_CALL is found.// L = *const OnCallSpec<F>* FindOnCallSpec(const ArgumentTuple& args) const {for (UntypedOnCallSpecs::const_reverse_iterator it= untyped_on_call_specs_.rbegin();it != untyped_on_call_specs_.rend(); ++it) {const OnCallSpec<F>* spec = static_cast<const OnCallSpec<F>*>(*it);if (spec->Matches(args))return spec;}return NULL;}
// Returns the expectation that matches the arguments, or NULL if no// expectation matches them.TypedExpectation<F>* FindMatchingExpectationLocked(const ArgumentTuple& args) constGTEST_EXCLUSIVE_LOCK_REQUIRED_(g_gmock_mutex) {g_gmock_mutex.AssertHeld();for (typename UntypedExpectations::const_reverse_iterator it =untyped_expectations_.rbegin();it != untyped_expectations_.rend(); ++it) {TypedExpectation<F>* const exp =static_cast<TypedExpectation<F>*>(it->get());if (exp->ShouldHandleArguments(args)) {return exp;}}return NULL;}
? ? ? ? 這兩個函數最終將在Matches函數中進行參數匹配
// Returns true iff this expectation matches the given arguments.bool Matches(const ArgumentTuple& args) constGTEST_EXCLUSIVE_LOCK_REQUIRED_(g_gmock_mutex) {g_gmock_mutex.AssertHeld();return TupleMatches(matchers_, args) && extra_matcher_.Matches(args);}
? ? ? ? 這個函數中,還有extra_matcher_這種參數匹配規則。它是通過TypedExpectation模板類的With方法(不是FunctionMocker模板類的With方法)傳遞進來的
// Implements the .With() clause.TypedExpectation& With(const Matcher<const ArgumentTuple&>& m) {if (last_clause_ == kWith) {ExpectSpecProperty(false,".With() cannot appear ""more than once in an EXPECT_CALL().");} else {ExpectSpecProperty(last_clause_ < kWith,".With() must be the first ""clause in an EXPECT_CALL().");}last_clause_ = kWith;extra_matcher_ = m;extra_matcher_specified_ = true;return *this;}
? ? ? ? 總結一下,Gmock的參數匹配通過FunctionMocker的With方法設置了一個通用匹配規則,還可以通過TypedExpectation的With方法設置額外的匹配規則,只有這兩個匹配規則都滿足時,才會被選中。
設定約束
? ? ? ? 我們主要分析下Times、WillOnce和WillRepeatedly這幾個常見的約束。先回顧一個例子
EXPECT_CALL(test_user, Pay(_)).Times(5).WillOnce(testing::Return(true)).WillOnce(testing::Return(true)).WillRepeatedly(testing::Return(false));
? ? ? ? 這例子說,Pay行為有5次可控的執行次數,第6次執行就按默認值返回了。第1個WillOnce規定第一次執行Pay的行為,第2個WillOnce規定第二次執行Pay的行為,之后的3~5次都按WillRepeatedly規定的方式去執行。
? ? ? ? 我們先看Times的實現
// Implements the .Times() clause.TypedExpectation& Times(const Cardinality& a_cardinality) {ExpectationBase::UntypedTimes(a_cardinality);return *this;}// Implements the .Times() clause.TypedExpectation& Times(int n) {return Times(Exactly(n));}
// Implements the .Times() clause.
void ExpectationBase::UntypedTimes(const Cardinality& a_cardinality) {if (last_clause_ == kTimes) {ExpectSpecProperty(false,".Times() cannot appear ""more than once in an EXPECT_CALL().");} else {ExpectSpecProperty(last_clause_ < kTimes,".Times() cannot appear after "".InSequence(), .WillOnce(), .WillRepeatedly(), ""or .RetiresOnSaturation().");}last_clause_ = kTimes;SpecifyCardinality(a_cardinality);
}// Explicitly specifies the cardinality of this expectation. Used by
// the subclasses to implement the .Times() clause.
void ExpectationBase::SpecifyCardinality(const Cardinality& a_cardinality) {cardinality_specified_ = true;cardinality_ = a_cardinality;
}
? ? ? ? 執行次數最終被轉換為Cardinality類的一個對象保存在FunctionMocker模板對象中。它將在IsSatisfied、IsSaturated和IsOverSaturated方法中被使用,用以判定執行的次數是否符合約定
// Returns true iff this expectation is satisfied.bool IsSatisfied() constGTEST_EXCLUSIVE_LOCK_REQUIRED_(g_gmock_mutex) {g_gmock_mutex.AssertHeld();return cardinality().IsSatisfiedByCallCount(call_count_);}// Returns true iff this expectation is saturated.bool IsSaturated() constGTEST_EXCLUSIVE_LOCK_REQUIRED_(g_gmock_mutex) {g_gmock_mutex.AssertHeld();return cardinality().IsSaturatedByCallCount(call_count_);}// Returns true iff this expectation is over-saturated.bool IsOverSaturated() constGTEST_EXCLUSIVE_LOCK_REQUIRED_(g_gmock_mutex) {g_gmock_mutex.AssertHeld();return cardinality().IsOverSaturatedByCallCount(call_count_);}
? ? ? ? 參數中的call_count_就是函數執行的次數,它是在IncrementCallCount函數中實現自增。IncrementCallCount函數則是在獲取行為時被調用到
const Action<F>* GetActionForArguments(const FunctionMockerBase<F>* mocker,const ArgumentTuple& args,::std::ostream* what,::std::ostream* why)GTEST_EXCLUSIVE_LOCK_REQUIRED_(g_gmock_mutex) {g_gmock_mutex.AssertHeld();if (IsSaturated()) {
......IncrementCallCount();
......}IncrementCallCount();
......}
? ? ? ? 我們再看下WillOnce的實現
// Implements the .WillOnce() clause.TypedExpectation& WillOnce(const Action<F>& action) {ExpectSpecProperty(last_clause_ <= kWillOnce,".WillOnce() cannot appear after "".WillRepeatedly() or .RetiresOnSaturation().");last_clause_ = kWillOnce;untyped_actions_.push_back(new Action<F>(action));if (!cardinality_specified()) {set_cardinality(Exactly(static_cast<int>(untyped_actions_.size())));}return *this;}
? ? ? ? 可見WillOnce將入參重新賦值給一個新建的Action<F>對象。然后將它保存到untyped_actions_列表中。最終它會在GetCurrentAction方法中,通過參數匹配后被取出
return count <= action_count ?*static_cast<const Action<F>*>(untyped_actions_[count - 1]) :repeated_action();
? ? ? ? 上面代碼中的repeated_action方法是在WillRepeatedly方法這被賦值的
// Implements the .WillRepeatedly() clause.TypedExpectation& WillRepeatedly(const Action<F>& action) {if (last_clause_ == kWillRepeatedly) {ExpectSpecProperty(false,".WillRepeatedly() cannot appear ""more than once in an EXPECT_CALL().");} else {ExpectSpecProperty(last_clause_ < kWillRepeatedly,".WillRepeatedly() cannot appear ""after .RetiresOnSaturation().");}last_clause_ = kWillRepeatedly;repeated_action_specified_ = true;repeated_action_ = action;if (!cardinality_specified()) {set_cardinality(AtLeast(static_cast<int>(untyped_actions_.size())));}// Now that no more action clauses can be specified, we check// whether their count makes sense.CheckActionCountIfNotDone();return *this;}
? ? ? ? 再看下testing::Return(true)是怎么轉換為Action<F>的。它的定義是
template <typename R>
internal::ReturnAction<R> Return(R value) {return internal::ReturnAction<R>(internal::move(value));
}
? ? ? ? 其中ReturnAction是個模板類,它重載了Action<F>()方法,將返回值轉換為一個Action<F>對象
template <typename F>operator Action<F>() const {typedef typename Function<F>::Result Result;GTEST_COMPILE_ASSERT_(!is_reference<Result>::value,use_ReturnRef_instead_of_Return_to_return_a_reference);return Action<F>(new Impl<R, F>(value_));}
? ? ? ? 在new一個Action<F>是,傳入了一個Impl模板類對象,這個模板類有一個Perform方法,其實現就是返回期待的值
virtual Result Perform(const ArgumentTuple&) { return value_; }
? ? ? ? 那么Action<F>對象和這個Impl模板類是怎么聯系的呢?我們看下Impl的定義
template <typename R_, typename F>class Impl : public ActionInterface<F> {public:
……
? ? ? ? 而在Action模板類的內部有
template <typename F>
class Action {
……
Action(const Action& action) : impl_(action.impl_) {}
……Result Perform(const ArgumentTuple& args) const {
…… return impl_->Perform(args);}private:
……internal::linked_ptr<ActionInterface<F> > impl_;
};
? ? ? ? 很醒目,最終執行的行為將由Action類中的Impl_成員變量來執行,而該Impl_變量就是在Action被創建時傳入的。
執行
? ? ? ? 當我們調用mock的類的mock的函數時,將會調用到MOCK_METHOD系列宏中定義的函數。以一個參數版本為例
GMOCK_RESULT_(tn, __VA_ARGS__) ct Method( \GMOCK_ARG_(tn, 1, __VA_ARGS__) gmock_a1) constness { \GTEST_COMPILE_ASSERT_((::testing::tuple_size< \tn ::testing::internal::Function<__VA_ARGS__>::ArgumentTuple>::value \== 1), \this_method_does_not_take_1_argument); \GMOCK_MOCKER_(1, constness, Method).SetOwnerAndName(this, #Method); \return GMOCK_MOCKER_(1, constness, Method).Invoke(gmock_a1); \} \
? ? ? ? 其最終調用到FunctionMocker類的Invoke函數中
R Invoke(A1 a1) {// Even though gcc and MSVC don't enforce it, 'this->' is required// by the C++ standard [14.6.4] here, as the base class type is// dependent on the template argument (and thus shouldn't be// looked into when resolving InvokeWith).return this->InvokeWith(ArgumentTuple(a1));}
? ? ? ? 調用InvokeWith之前,已將參數轉換成一個ArgumentTuple對象,這樣將方便之后統一處理。? ? ? ??InvokeWith函數內部使用了一個結果承載器——ResultHolder用于保存結果。InvokeWith最終會調用到FunctionMockerBase的PerformDefaultAction中
Result PerformDefaultAction(const ArgumentTuple& args,const string& call_description) const {const OnCallSpec<F>* const spec =this->FindOnCallSpec(args);if (spec != NULL) {return spec->GetAction().Perform(args);}const string message = call_description +"\n The mock function has no default action ""set, and its return type has no default value set.";
#if GTEST_HAS_EXCEPTIONSif (!DefaultValue<Result>::Exists()) {throw std::runtime_error(message);}
#elseAssert(DefaultValue<Result>::Exists(), "", -1, message);
#endifreturn DefaultValue<Result>::Get();}
? ? ? ? 第3行通過參數匹配相應的處理行為。找到行為后,在06行執行該行為;沒有找到,則返回默認值。
? ? ? ? 至此,Gmock的主要流程相關的源碼已經分析結束了。我們稍微總結下:
- Mock的類通過MOCK_METHOD系列方法,聲明了一個Mock函數的對象,并定義了一個通過該對象獲取符合相應約束的函數對象。還定義了一個和需要mock的函數同名的函數,該函數內部完成最終的結果計算。
- EXPECT_CALL宏和WillOnce、WillRepeatedly等方法,設定了函數對象的一些特性。
- 最終用戶調用函數時,將通過參數匹配得到適合的函數對象,并執行該函數對象中的預期行為。
總結
以上是生活随笔為你收集整理的Google Mock(Gmock)简单使用和源码分析——源码分析的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: Google Mock(Gmock)简单
- 下一篇: 朴素、Select、Poll和Epoll