229 lines
10 KiB
Plaintext
229 lines
10 KiB
Plaintext
Google C++ Testing Framework
|
|
============================
|
|
http://code.google.com/p/googletest/
|
|
|
|
Overview
|
|
--------
|
|
Google's framework for writing C++ tests on a variety of platforms (Linux, Mac
|
|
OS X, Windows, Windows CE, and Symbian). Based on the xUnit architecture.
|
|
Supports automatic test discovery, a rich set of assertions, user-defined
|
|
assertions, death tests, fatal and non-fatal failures, various options for
|
|
running the tests, and XML test report generation.
|
|
|
|
Please see the project page above for more information as well as mailing lists
|
|
for questions, discussions, and development. There is also an IRC channel on
|
|
OFTC (irc.oftc.net) #gtest available. Please join us!
|
|
|
|
Requirements
|
|
------------
|
|
Google Test is designed to have fairly minimal requirements to build and use
|
|
with your projects, but there are some. Currently, the only Operating System
|
|
(OS) on which Google Test is known to build properly is Linux, but we are
|
|
actively working on Windows and Mac support as well. The source code itself is
|
|
already portable across many other platforms, but we are still developing
|
|
robust build systems for each.
|
|
|
|
### Linux Requirements ###
|
|
These are the base requirements to build and use Google Test from a source
|
|
package (as described below):
|
|
* GNU-compatible Make or "gmake"
|
|
* POSIX-standard shell
|
|
* POSIX(-2) Regular Expressions (regex.h)
|
|
* A C++98 standards compliant compiler
|
|
|
|
Furthermore, if you are building Google Test from a VCS Checkout (also
|
|
described below), there are further requirements:
|
|
* Automake version 1.9 or newer
|
|
* Autoconf version 2.59 or newer
|
|
* Libtool / Libtoolize
|
|
* Python version 2.4 or newer
|
|
|
|
### Windows Requirements ###
|
|
* Microsoft Visual Studio 7.1 or newer
|
|
|
|
### Cygwin Requirements ###
|
|
* Cygwin 1.5.25-14 or newer
|
|
|
|
### Mac OS X Requirements ###
|
|
* Mac OS X 10.4 Tiger or newer
|
|
* Developer Tools Installed
|
|
* Optional: Xcode 2.5 or later for univeral-binary framework; see note below.
|
|
|
|
Getting the Source
|
|
------------------
|
|
There are two primary ways of getting Google Test's source code: you can
|
|
download a source release in your preferred archive format, or directly check
|
|
out the source from a Version Control System (VCS, we use Google Code's
|
|
Subversion hosting). The VCS checkout requires a few extra steps and some extra
|
|
software packages on your system, but lets you track development, and make
|
|
patches to contribute much more easily, so we highly encourage it.
|
|
|
|
### VCS Checkout: ###
|
|
The first step is to select whether you want to check out the main line of
|
|
development on Google Test, or one of the released branches. The former will be
|
|
much more active and have the latest features, but the latter provides much
|
|
more stability and predictability. Choose whichever fits your needs best, and
|
|
proceed with the following Subversion commands:
|
|
|
|
$ svn checkout http://googletest.googlecode.com/svn/trunk/ gtest-svn
|
|
|
|
or for a release version X.Y.*'s branch:
|
|
|
|
$ svn checkout http://googletest.googlecode.com/svn/branches/release-X.Y/ gtest-X.Y-svn
|
|
|
|
Next you will need to prepare the GNU Autotools build system, if you
|
|
are using Linux, Mac OS X, or Cygwin. Enter the target directory of
|
|
the checkout command you used ('gtest-svn' or 'gtest-X.Y-svn' above)
|
|
and proceed with the following commands:
|
|
|
|
$ aclocal-1.9 # Where "1.9" must match the following automake command.
|
|
$ libtoolize -c # Use "glibtoolize -c" instead on Mac OS X.
|
|
$ autoheader
|
|
$ automake-1.9 -ac # See Automake version requirements above.
|
|
$ autoconf
|
|
|
|
While this is a bit complicated, it will most often be automatically re-run by
|
|
your "make" invocations, so in practice you shouldn't need to worry too much.
|
|
Once you have completed these steps, you are ready to build the library.
|
|
|
|
### Source Package: ###
|
|
Google Test is also released in source packages which can be downloaded from
|
|
its Google Code download page[1]. Several different archive formats are
|
|
provided, but the only difference is the tools used to manipulate them, and the
|
|
size of the resulting file. Download whichever you are most comfortable with.
|
|
|
|
[1] Google Test Downloads: http://code.google.com/p/googletest/downloads/list
|
|
|
|
Once downloaded expand the archive using whichever tools you prefer for that
|
|
type. This will always result in a new directory with the name "gtest-X.Y.Z"
|
|
which contains all of the source code. Here are some examples in Linux:
|
|
|
|
$ tar -xvzf gtest-X.Y.Z.tar.gz
|
|
$ tar -xvjf gtest-X.Y.Z.tar.bz2
|
|
$ unzip gtest-X.Y.Z.zip
|
|
|
|
Building the Source
|
|
-------------------
|
|
### Linux, Mac OS X (without Xcode), and Cygwin ###
|
|
There are two primary options for building the source at this point: build it
|
|
inside the source code tree, or in a separate directory. We recommend building
|
|
in a separate directory as that tends to produce both more consistent results
|
|
and be easier to clean up should anything go wrong, but both patterns are
|
|
supported. The only hard restriction is that while the build directory can be
|
|
a subdirectory of the source directory, the opposite is not possible and will
|
|
result in errors. Once you have selected where you wish to build Google Test,
|
|
create the directory if necessary, and enter it. The following steps apply for
|
|
either approach by simply substituting the shell variable SRCDIR with "." for
|
|
building inside the source directory, and the relative path to the source
|
|
directory otherwise.
|
|
|
|
$ ${SRCDIR}/configure # Standard GNU configure script, --help for more info
|
|
$ make # Standard makefile following GNU conventions
|
|
$ make check # Builds and runs all tests - all should pass
|
|
|
|
Other programs will only be able to use Google Test's functionality if you
|
|
install it in a location which they can access, in Linux this is typically
|
|
under '/usr/local'. The following command will install all of the Google Test
|
|
libraries, public headers, and utilities necessary for other programs and
|
|
libraries to leverage it:
|
|
|
|
$ sudo make install # Not necessary, but allows use by other programs
|
|
|
|
TODO(chandlerc@google.com): This section needs to be expanded when the
|
|
'gtest-config' script is finished and Autoconf macro's are provided (or not
|
|
provided) in order to properly reflect the process for other programs to
|
|
locate, include, and link against Google Test.
|
|
|
|
Finally, should you need to remove Google Test from your system after having
|
|
installed it, run the following command, and it will back out its changes.
|
|
However, note carefully that you must run this command on the *same* Google
|
|
Test build that you ran the install from, or the results are not predictable.
|
|
If you install Google Test on your system, and are working from a VCS checkout,
|
|
make sure you run this *before* updating your checkout of the source in order
|
|
to uninstall the same version which you installed.
|
|
|
|
$ sudo make uninstall # Must be run against the exact same build as "install"
|
|
|
|
### Windows ###
|
|
Open the gtest.sln file in the msvc/ folder using Visual Studio, and
|
|
you are ready to build Google Test the same way you build any Visual
|
|
Studio project.
|
|
|
|
### Mac OS X (universal-binary framework) ###
|
|
Open the gtest.xcodeproj in the xcode/ folder using Xcode. Build the "gtest"
|
|
target. The universal binary framework will end up in your selected build
|
|
directory (selected in the Xcode "Preferences..." -> "Building" pane and
|
|
defaults to xcode/build). Alternatively, at the command line, enter:
|
|
|
|
$ xcodebuild
|
|
|
|
This will build the "Release" configuration of the gtest.framework, but you can
|
|
select the "Debug" configuration with a command line option. See the
|
|
"xcodebuild" man page for more information.
|
|
|
|
To test the gtest.framework in Xcode, change the active target to "Check" and
|
|
then build. This target builds all of the tests and then runs them. Don't worry
|
|
if you see some errors. Xcode reports all test failures (even the intentional
|
|
ones) as errors. However, you should see a "Build succeeded" message at the end
|
|
of the build log. To run all of the tests from the command line, enter:
|
|
|
|
$ xcodebuid -target Check
|
|
|
|
It is also possible to build and execute individual tests within Xcode. Each
|
|
test has its own Xcode "Target" and Xcode "Executable". To build any of the
|
|
tests, change the active target and the active executable to the test of
|
|
interest and then build and run.
|
|
|
|
NOTE: many of the tests are executed from Python scripts. These tests are
|
|
indicated by a trailing underscore "_" in the test name. These tests should not
|
|
be executed directly. Instead a custom Xcode "Executable" was created to run the
|
|
Python script from within Xcode. These custom executables do not have the
|
|
trailing underscore in the name. For example, to run the gtest_color_test, set
|
|
the active target to "gtest_color_test_" (with a trailing underscore). This
|
|
target will build the gtest_color_test_, which should not be run directly.
|
|
Then set the active executable to "gtest_color_test" (no trailing underscore).
|
|
This executable will execute the gtest_color_test_ from within the
|
|
gtest_color_test.py script).
|
|
|
|
Individual tests can be built from the command line using:
|
|
|
|
$ xcodebuild -target <test_name>
|
|
|
|
These tests can be executed from the command line by moving to the build
|
|
directory and then (in bash)
|
|
|
|
$ export DYLD_FRAMEWORK_PATH=`pwd`
|
|
$ ./<test_name> # (e.g. ./gtest_unittest or ./gtest_color_test.py)
|
|
|
|
To use the gtest.framework for your own tests, first, add the framework to Xcode
|
|
project. Next, create a new executable target and add the framework to the
|
|
"Link Binary With Libraries" build phase. Select "Edit Active Executable" from
|
|
the "Project" menu. In the "Arguments" tab, add
|
|
|
|
"DYLD_FRAMEWORK_PATH" : "/real/framework/path"
|
|
|
|
in the "Variables to be set in the environment:" list, where you replace
|
|
"/real/framework/path" with the actual location of the gtest.framework. Now
|
|
when you run your executable, it will load the framework and your test will
|
|
run as expected.
|
|
|
|
Regenerating Source Files
|
|
-------------------------
|
|
|
|
Some of Google Test's source files are generated from templates (not
|
|
in the C++ sense) using a script. A template file is named FOO.pump,
|
|
where FOO is the name of the file it will generate. For example, the
|
|
file include/gtest/internal/gtest-type-util.h.pump is used to generate
|
|
gtest-type-util.h in the same directory.
|
|
|
|
Normally you don't need to worry about regenerating the source files,
|
|
unless you need to modify them (e.g. if you are working on a patch for
|
|
Google Test). In that case, you should modify the corresponding .pump
|
|
files instead and run the 'pump' script (for Pump is Useful for Meta
|
|
Programming) to regenerate them. We are still working on releasing
|
|
the script and its documentation. If you need it now, please email
|
|
googletestframework@googlegroups.com such that we know to make it
|
|
happen sooner.
|
|
|
|
Happy testing!
|