2010-09-24 11:01:13 +02:00
|
|
|
########################################################################
|
|
|
|
|
# Experimental CMake build script for Google Test.
|
|
|
|
|
#
|
|
|
|
|
# Consider this a prototype. It will change drastically. For now,
|
|
|
|
|
# this is only for people on the cutting edge.
|
|
|
|
|
#
|
|
|
|
|
# To run the tests for Google Test itself on Linux, use 'make test' or
|
|
|
|
|
# ctest. You can select which tests to run using 'ctest -R regex'.
|
|
|
|
|
# For more options, run 'ctest --help'.
|
|
|
|
|
########################################################################
|
|
|
|
|
#
|
|
|
|
|
# Project-wide settings
|
|
|
|
|
|
|
|
|
|
# Where gtest's .h files can be found.
|
|
|
|
|
include_directories(
|
|
|
|
|
googletest/include
|
2013-11-15 11:20:45 +01:00
|
|
|
googletest
|
Add the 'googlemock' component of Google Test to LLVM's unittest libraries.
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
2017-01-10 23:32:26 +01:00
|
|
|
googlemock/include
|
|
|
|
|
googlemock
|
2010-09-24 11:01:13 +02:00
|
|
|
)
|
|
|
|
|
|
|
|
|
|
if(WIN32)
|
|
|
|
|
add_definitions(-DGTEST_OS_WINDOWS=1)
|
|
|
|
|
endif()
|
|
|
|
|
|
2017-01-07 00:16:00 +01:00
|
|
|
if(SUPPORTS_VARIADIC_MACROS_FLAG)
|
2010-10-07 20:12:54 +02:00
|
|
|
add_definitions("-Wno-variadic-macros")
|
|
|
|
|
endif()
|
2017-01-07 00:16:00 +01:00
|
|
|
if(SUPPORTS_GNU_ZERO_VARIADIC_MACRO_ARGUMENTS_FLAG)
|
2017-01-05 00:06:03 +01:00
|
|
|
add_definitions("-Wno-gnu-zero-variadic-macro-arguments")
|
|
|
|
|
endif()
|
|
|
|
|
if(CXX_SUPPORTS_COVERED_SWITCH_DEFAULT_FLAG)
|
|
|
|
|
add_definitions("-Wno-covered-switch-default")
|
|
|
|
|
endif()
|
2010-10-07 20:12:54 +02:00
|
|
|
|
2010-10-17 04:26:16 +02:00
|
|
|
set(LLVM_REQUIRES_RTTI 1)
|
|
|
|
|
add_definitions( -DGTEST_HAS_RTTI=0 )
|
|
|
|
|
|
2013-05-14 15:29:16 +02:00
|
|
|
if (NOT LLVM_ENABLE_THREADS)
|
|
|
|
|
add_definitions( -DGTEST_HAS_PTHREAD=0 )
|
|
|
|
|
endif()
|
|
|
|
|
|
2015-01-20 22:23:15 +01:00
|
|
|
find_library(PTHREAD_LIBRARY_PATH pthread)
|
|
|
|
|
if (PTHREAD_LIBRARY_PATH)
|
|
|
|
|
list(APPEND LIBS pthread)
|
|
|
|
|
endif()
|
|
|
|
|
|
2010-09-25 22:25:25 +02:00
|
|
|
add_llvm_library(gtest
|
2013-11-15 11:20:45 +01:00
|
|
|
googletest/src/gtest-all.cc
|
Add the 'googlemock' component of Google Test to LLVM's unittest libraries.
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
2017-01-10 23:32:26 +01:00
|
|
|
googlemock/src/gmock-all.cc
|
2010-09-24 11:01:13 +02:00
|
|
|
|
2014-02-26 07:41:29 +01:00
|
|
|
LINK_LIBS
|
2015-01-20 22:23:15 +01:00
|
|
|
${LIBS}
|
2016-02-12 02:42:43 +01:00
|
|
|
|
|
|
|
|
LINK_COMPONENTS
|
|
|
|
|
Support # Depends on llvm::raw_ostream
|
2016-09-09 21:45:34 +02:00
|
|
|
|
|
|
|
|
# This is a library meant only for the build tree.
|
|
|
|
|
BUILDTREE_ONLY
|
2015-01-20 22:23:15 +01:00
|
|
|
)
|
2014-02-10 12:27:41 +01:00
|
|
|
|
2014-01-10 12:02:26 +01:00
|
|
|
add_subdirectory(UnitTestMain)
|
