mirror of
https://github.com/Gericom/teak-llvm.git
synced 2025-06-24 14:05:49 -04:00

I have two immediate motivations for adding this: 1) It makes writing expectations in tests *dramatically* easier. A quick example that is a taste of what is possible: std::vector<int> v = ...; EXPECT_THAT(v, UnorderedElementsAre(1, 2, 3)); This checks that v contains '1', '2', and '3' in some order. There are a wealth of other helpful matchers like this. They tend to be highly generic and STL-friendly so they will in almost all cases work out of the box even on custom LLVM data structures. I actually find the matcher syntax substantially easier to read even for simple assertions: EXPECT_THAT(a, Eq(b)); EXPECT_THAT(b, Ne(c)); Both of these make it clear what is being *tested* and what is being *expected*. With `EXPECT_EQ` this is implicit (the LHS is expected, the RHS is tested) and often confusing. With `EXPECT_NE` it is just not clear. Even the failure error messages are superior with the matcher based expectations. 2) When testing any kind of generic code, you are continually defining dummy types with interfaces and then trying to check that the interfaces are manipulated in a particular way. This is actually what mocks are *good* for -- testing *interface interactions*. With generic code, there is often no "fake" or other object that can be used. For a concrete example of where this is currently causing significant pain, look at the pass manager unittests which are riddled with counters incremented when methods are called. All of these could be replaced with mocks. The result would be more effective at testing the code by having tighter constraints. It would be substantially more readable and maintainable when updating the code. And the error messages on failure would have substantially more information as mocks automatically record stack traces and other information *when the API is misused* instead of trying to diagnose it after the fact. I expect that #1 will be the overwhelming majority of the uses of gmock, but I think that is sufficient to justify having it. I would actually like to update the coding standards to encourage the use of matchers rather than any other form of `EXPECT_...` macros as they are IMO a strict superset in terms of functionality and readability. I think that #2 is relatively rarely useful, but there *are* cases where it is useful. Historically, I think misuse of actual mocking as described in #2 has led to resistance towards this framework. I am actually sympathetic to this -- mocking can easily be overused. However I think this is not a significant concern in LLVM. First and foremost, LLVM has very careful and rare exposure of abstract interfaces or dependency injection, which are the most prone to abuse with mocks. So there are few opportunities to abuse them. Second, a large fraction of LLVM's unittests are testing *generic code* where mocks actually make tremendous sense. And gmock is well suited to building interfaces that exercise generic libraries. Finally, I still think we should be willing to have testing utilities in tree even if they should be used rarely. We can use code review to help guide the usage here. For a longer and more complete discussion of this, see the llvm-dev thread here: http://lists.llvm.org/pipermail/llvm-dev/2017-January/108672.html The general consensus seems that this is a reasonable direction to start down, but that doesn't mean we should race ahead and use this everywhere. I have one test that is blocked on this to land and that was specifically used as an example. Before widespread adoption, I'm going to work up some (brief) guidelines as some of these facilities should be used sparingly and carefully. Differential Revision: https://reviews.llvm.org/D28156 llvm-svn: 291606
247 lines
9.2 KiB
C++
247 lines
9.2 KiB
C++
// Copyright 2007, Google Inc.
|
|
// All rights reserved.
|
|
//
|
|
// Redistribution and use in source and binary forms, with or without
|
|
// modification, are permitted provided that the following conditions are
|
|
// met:
|
|
//
|
|
// * Redistributions of source code must retain the above copyright
|
|
// notice, this list of conditions and the following disclaimer.
|
|
// * Redistributions in binary form must reproduce the above
|
|
// copyright notice, this list of conditions and the following disclaimer
|
|
// in the documentation and/or other materials provided with the
|
|
// distribution.
|
|
// * Neither the name of Google Inc. nor the names of its
|
|
// contributors may be used to endorse or promote products derived from
|
|
// this software without specific prior written permission.
|
|
//
|
|
// THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
|
|
// "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
|
|
// LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
|
|
// A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
|
|
// OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
|
|
// SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
|
|
// LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
|
|
// DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
|
|
// THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
|
|
// (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
|
|
// OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
|
|
//
|
|
// Author: wan@google.com (Zhanyong Wan)
|
|
|
|
// Google Mock - a framework for writing C++ mock classes.
|
|
//
|
|
// This file implements some actions that depend on gmock-generated-actions.h.
|
|
|
|
#ifndef GMOCK_INCLUDE_GMOCK_GMOCK_MORE_ACTIONS_H_
|
|
#define GMOCK_INCLUDE_GMOCK_GMOCK_MORE_ACTIONS_H_
|
|
|
|
#include <algorithm>
|
|
|
|
#include "gmock/gmock-generated-actions.h"
|
|
|
|
namespace testing {
|
|
namespace internal {
|
|
|
|
// Implements the Invoke(f) action. The template argument
|
|
// FunctionImpl is the implementation type of f, which can be either a
|
|
// function pointer or a functor. Invoke(f) can be used as an
|
|
// Action<F> as long as f's type is compatible with F (i.e. f can be
|
|
// assigned to a tr1::function<F>).
|
|
template <typename FunctionImpl>
|
|
class InvokeAction {
|
|
public:
|
|
// The c'tor makes a copy of function_impl (either a function
|
|
// pointer or a functor).
|
|
explicit InvokeAction(FunctionImpl function_impl)
|
|
: function_impl_(function_impl) {}
|
|
|
|
template <typename Result, typename ArgumentTuple>
|
|
Result Perform(const ArgumentTuple& args) {
|
|
return InvokeHelper<Result, ArgumentTuple>::Invoke(function_impl_, args);
|
|
}
|
|
|
|
private:
|
|
FunctionImpl function_impl_;
|
|
|
|
GTEST_DISALLOW_ASSIGN_(InvokeAction);
|
|
};
|
|
|
|
// Implements the Invoke(object_ptr, &Class::Method) action.
|
|
template <class Class, typename MethodPtr>
|
|
class InvokeMethodAction {
|
|
public:
|
|
InvokeMethodAction(Class* obj_ptr, MethodPtr method_ptr)
|
|
: method_ptr_(method_ptr), obj_ptr_(obj_ptr) {}
|
|
|
|
template <typename Result, typename ArgumentTuple>
|
|
Result Perform(const ArgumentTuple& args) const {
|
|
return InvokeHelper<Result, ArgumentTuple>::InvokeMethod(
|
|
obj_ptr_, method_ptr_, args);
|
|
}
|
|
|
|
private:
|
|
// The order of these members matters. Reversing the order can trigger
|
|
// warning C4121 in MSVC (see
|
|
// http://computer-programming-forum.com/7-vc.net/6fbc30265f860ad1.htm ).
|
|
const MethodPtr method_ptr_;
|
|
Class* const obj_ptr_;
|
|
|
|
GTEST_DISALLOW_ASSIGN_(InvokeMethodAction);
|
|
};
|
|
|
|
// An internal replacement for std::copy which mimics its behavior. This is
|
|
// necessary because Visual Studio deprecates ::std::copy, issuing warning 4996.
|
|
// However Visual Studio 2010 and later do not honor #pragmas which disable that
|
|
// warning.
|
|
template<typename InputIterator, typename OutputIterator>
|
|
inline OutputIterator CopyElements(InputIterator first,
|
|
InputIterator last,
|
|
OutputIterator output) {
|
|
for (; first != last; ++first, ++output) {
|
|
*output = *first;
|
|
}
|
|
return output;
|
|
}
|
|
|
|
} // namespace internal
|
|
|
|
// Various overloads for Invoke().
|
|
|
|
// Creates an action that invokes 'function_impl' with the mock
|
|
// function's arguments.
|
|
template <typename FunctionImpl>
|
|
PolymorphicAction<internal::InvokeAction<FunctionImpl> > Invoke(
|
|
FunctionImpl function_impl) {
|
|
return MakePolymorphicAction(
|
|
internal::InvokeAction<FunctionImpl>(function_impl));
|
|
}
|
|
|
|
// Creates an action that invokes the given method on the given object
|
|
// with the mock function's arguments.
|
|
template <class Class, typename MethodPtr>
|
|
PolymorphicAction<internal::InvokeMethodAction<Class, MethodPtr> > Invoke(
|
|
Class* obj_ptr, MethodPtr method_ptr) {
|
|
return MakePolymorphicAction(
|
|
internal::InvokeMethodAction<Class, MethodPtr>(obj_ptr, method_ptr));
|
|
}
|
|
|
|
// WithoutArgs(inner_action) can be used in a mock function with a
|
|
// non-empty argument list to perform inner_action, which takes no
|
|
// argument. In other words, it adapts an action accepting no
|
|
// argument to one that accepts (and ignores) arguments.
|
|
template <typename InnerAction>
|
|
inline internal::WithArgsAction<InnerAction>
|
|
WithoutArgs(const InnerAction& action) {
|
|
return internal::WithArgsAction<InnerAction>(action);
|
|
}
|
|
|
|
// WithArg<k>(an_action) creates an action that passes the k-th
|
|
// (0-based) argument of the mock function to an_action and performs
|
|
// it. It adapts an action accepting one argument to one that accepts
|
|
// multiple arguments. For convenience, we also provide
|
|
// WithArgs<k>(an_action) (defined below) as a synonym.
|
|
template <int k, typename InnerAction>
|
|
inline internal::WithArgsAction<InnerAction, k>
|
|
WithArg(const InnerAction& action) {
|
|
return internal::WithArgsAction<InnerAction, k>(action);
|
|
}
|
|
|
|
// The ACTION*() macros trigger warning C4100 (unreferenced formal
|
|
// parameter) in MSVC with -W4. Unfortunately they cannot be fixed in
|
|
// the macro definition, as the warnings are generated when the macro
|
|
// is expanded and macro expansion cannot contain #pragma. Therefore
|
|
// we suppress them here.
|
|
#ifdef _MSC_VER
|
|
# pragma warning(push)
|
|
# pragma warning(disable:4100)
|
|
#endif
|
|
|
|
// Action ReturnArg<k>() returns the k-th argument of the mock function.
|
|
ACTION_TEMPLATE(ReturnArg,
|
|
HAS_1_TEMPLATE_PARAMS(int, k),
|
|
AND_0_VALUE_PARAMS()) {
|
|
return ::testing::get<k>(args);
|
|
}
|
|
|
|
// Action SaveArg<k>(pointer) saves the k-th (0-based) argument of the
|
|
// mock function to *pointer.
|
|
ACTION_TEMPLATE(SaveArg,
|
|
HAS_1_TEMPLATE_PARAMS(int, k),
|
|
AND_1_VALUE_PARAMS(pointer)) {
|
|
*pointer = ::testing::get<k>(args);
|
|
}
|
|
|
|
// Action SaveArgPointee<k>(pointer) saves the value pointed to
|
|
// by the k-th (0-based) argument of the mock function to *pointer.
|
|
ACTION_TEMPLATE(SaveArgPointee,
|
|
HAS_1_TEMPLATE_PARAMS(int, k),
|
|
AND_1_VALUE_PARAMS(pointer)) {
|
|
*pointer = *::testing::get<k>(args);
|
|
}
|
|
|
|
// Action SetArgReferee<k>(value) assigns 'value' to the variable
|
|
// referenced by the k-th (0-based) argument of the mock function.
|
|
ACTION_TEMPLATE(SetArgReferee,
|
|
HAS_1_TEMPLATE_PARAMS(int, k),
|
|
AND_1_VALUE_PARAMS(value)) {
|
|
typedef typename ::testing::tuple_element<k, args_type>::type argk_type;
|
|
// Ensures that argument #k is a reference. If you get a compiler
|
|
// error on the next line, you are using SetArgReferee<k>(value) in
|
|
// a mock function whose k-th (0-based) argument is not a reference.
|
|
GTEST_COMPILE_ASSERT_(internal::is_reference<argk_type>::value,
|
|
SetArgReferee_must_be_used_with_a_reference_argument);
|
|
::testing::get<k>(args) = value;
|
|
}
|
|
|
|
// Action SetArrayArgument<k>(first, last) copies the elements in
|
|
// source range [first, last) to the array pointed to by the k-th
|
|
// (0-based) argument, which can be either a pointer or an
|
|
// iterator. The action does not take ownership of the elements in the
|
|
// source range.
|
|
ACTION_TEMPLATE(SetArrayArgument,
|
|
HAS_1_TEMPLATE_PARAMS(int, k),
|
|
AND_2_VALUE_PARAMS(first, last)) {
|
|
// Visual Studio deprecates ::std::copy, so we use our own copy in that case.
|
|
#ifdef _MSC_VER
|
|
internal::CopyElements(first, last, ::testing::get<k>(args));
|
|
#else
|
|
::std::copy(first, last, ::testing::get<k>(args));
|
|
#endif
|
|
}
|
|
|
|
// Action DeleteArg<k>() deletes the k-th (0-based) argument of the mock
|
|
// function.
|
|
ACTION_TEMPLATE(DeleteArg,
|
|
HAS_1_TEMPLATE_PARAMS(int, k),
|
|
AND_0_VALUE_PARAMS()) {
|
|
delete ::testing::get<k>(args);
|
|
}
|
|
|
|
// This action returns the value pointed to by 'pointer'.
|
|
ACTION_P(ReturnPointee, pointer) { return *pointer; }
|
|
|
|
// Action Throw(exception) can be used in a mock function of any type
|
|
// to throw the given exception. Any copyable value can be thrown.
|
|
#if GTEST_HAS_EXCEPTIONS
|
|
|
|
// Suppresses the 'unreachable code' warning that VC generates in opt modes.
|
|
# ifdef _MSC_VER
|
|
# pragma warning(push) // Saves the current warning state.
|
|
# pragma warning(disable:4702) // Temporarily disables warning 4702.
|
|
# endif
|
|
ACTION_P(Throw, exception) { throw exception; }
|
|
# ifdef _MSC_VER
|
|
# pragma warning(pop) // Restores the warning state.
|
|
# endif
|
|
|
|
#endif // GTEST_HAS_EXCEPTIONS
|
|
|
|
#ifdef _MSC_VER
|
|
# pragma warning(pop)
|
|
#endif
|
|
|
|
} // namespace testing
|
|
|
|
#endif // GMOCK_INCLUDE_GMOCK_GMOCK_MORE_ACTIONS_H_
|