Skip to content

GitLab

Commit 07b2bd1f authored by Billy Donahue's avatar Billy Donahue
Browse files

Merge pull request #180 from google/wiki 

merge wiki branch into master
parents 6e108721 168ab067
Expand all Hide whitespace changes
Inline Side-by-side
Showing with 15685 additions and 88 deletions
README → README.md
View file @ 07b2bd1f
Google C++ Mocking Framework
============================
http://code.google.com/p/googlemock/
<http://github.com/google/googlemock/>
Overview
--------
......@@ -33,23 +33,22 @@ mailing list for questions, discussions, and development. There is
also an IRC channel on OFTC (irc.oftc.net) #gtest available. Please
join us!
Please note that code under scripts/generator/ is from the cppclean
project (http://code.google.com/p/cppclean/) and under the Apache
Please note that code under scripts/generator/ is from the [cppclean
project](http://code.google.com/p/cppclean/) and under the Apache
License, which is different from Google Mock's license.
Requirements for End Users
--------------------------
Google Mock is implemented on top of the Google Test C++ testing
framework (http://code.google.com/p/googletest/), and includes the
latter as part of the SVN repository and distribution package. You
must use the bundled version of Google Test when using Google Mock, or
Google Mock is implemented on top of the [Google Test C++ testing
framework](http://github.com/google/googletest/), and depends on it.
You must use the bundled version of Google Test when using Google Mock, or
you may get compiler/linker errors.
You can also easily configure Google Mock to work with another testing
framework of your choice; although it will still need Google Test as
an internal dependency. Please read
http://code.google.com/p/googlemock/wiki/ForDummies#Using_Google_Mock_with_Any_Testing_Framework
<http://code.google.com/p/googlemock/wiki/ForDummies#Using_Google_Mock_with_Any_Testing_Framework>
for how to do it.
Google Mock depends on advanced C++ features and thus requires a more
......@@ -91,39 +90,19 @@ Getting the Source
------------------
There are two primary ways of getting Google Mock's source code: you
can download a stable source release in your preferred archive format,
or directly check out the source from our Subversion (SVN) repository.
The SVN checkout requires a few extra steps and some extra software
can download a [stable source release](releases),
or directly check out the source from our Git repository.
The Git checkout requires a few extra steps and some extra software
packages on your system, but lets you track development and make
patches much more easily, so we highly encourage it.
### Source Package ###
### Git Checkout ###
Google Mock is released in versioned source packages which can be
downloaded from the download page [1]. Several different archive
formats are provided, but the only difference is the tools needed to
extract their contents, and the size of the resulting file. Download
whichever you are most comfortable with.
To check out the master branch of Google Mock, run the following git command:
[1] http://code.google.com/p/googlemock/downloads/list
git clone https://github.com/google/googlemock.git
Once downloaded expand the archive using whichever tools you prefer
for that type. This will always result in a new directory with the
name "gmock-X.Y.Z" which contains all of the source code. Here are
some examples on Linux:
tar -xvzf gmock-X.Y.Z.tar.gz
tar -xvjf gmock-X.Y.Z.tar.bz2
unzip gmock-X.Y.Z.zip
### SVN Checkout ###
To check out the main branch (also known as the "trunk") of Google
Mock, run the following Subversion command:
svn checkout http://googlemock.googlecode.com/svn/trunk/ gmock-svn
If you are using a *nix system and plan to use the GNU Autotools build
If you are using a \*nix system and plan to use the GNU Autotools build
system to build Google Mock (described below), you'll need to
configure it now. Otherwise you are done with getting the source
files.
......@@ -132,7 +111,7 @@ To prepare the Autotools build system, enter the target directory of
the checkout command you used ('gmock-svn') and proceed with the
following command:
autoreconf -fvi
autoreconf -fvi
Once you have completed this step, you are ready to build the library.
Note that you should only need to complete this step once. The
......@@ -144,7 +123,7 @@ will fail. You may need to explicitly specify a version to use. For
instance, if you have both GNU Automake 1.4 and 1.9 installed and
'automake' would invoke the 1.4, use instead:
AUTOMAKE=automake-1.9 ACLOCAL=aclocal-1.9 autoreconf -fvi
AUTOMAKE=automake-1.9 ACLOCAL=aclocal-1.9 autoreconf -fvi
Make sure you're using the same version of automake and aclocal.
......@@ -161,40 +140,40 @@ straightforward.
This section shows how you can integrate Google Mock into your
existing build system.
Suppose you put Google Mock in directory ${GMOCK_DIR} and Google Test
in ${GTEST_DIR} (the latter is ${GMOCK_DIR}/gtest by default). To
Suppose you put Google Mock in directory ${GMOCK\_DIR} and Google Test
in ${GTEST\_DIR} (the latter is ${GMOCK\_DIR}/gtest by default). To
build Google Mock, create a library build target (or a project as
called by Visual Studio and Xcode) to compile
${GTEST_DIR}/src/gtest-all.cc and ${GMOCK_DIR}/src/gmock-all.cc
${GTEST_DIR}/src/gtest-all.cc and ${GMOCK_DIR}/src/gmock-all.cc
with
${GTEST_DIR}/include and ${GMOCK_DIR}/include
${GTEST_DIR}/include and ${GMOCK_DIR}/include
in the system header search path, and
${GTEST_DIR} and ${GMOCK_DIR}
${GTEST_DIR} and ${GMOCK_DIR}
in the normal header search path. Assuming a Linux-like system and gcc,
something like the following will do:
g++ -isystem ${GTEST_DIR}/include -I${GTEST_DIR} \
-isystem ${GMOCK_DIR}/include -I${GMOCK_DIR} \
-pthread -c ${GTEST_DIR}/src/gtest-all.cc
g++ -isystem ${GTEST_DIR}/include -I${GTEST_DIR} \
-isystem ${GMOCK_DIR}/include -I${GMOCK_DIR} \
-pthread -c ${GMOCK_DIR}/src/gmock-all.cc
ar -rv libgmock.a gtest-all.o gmock-all.o
g++ -isystem ${GTEST_DIR}/include -I${GTEST_DIR} \
-isystem ${GMOCK_DIR}/include -I${GMOCK_DIR} \
-pthread -c ${GTEST_DIR}/src/gtest-all.cc
g++ -isystem ${GTEST_DIR}/include -I${GTEST_DIR} \
-isystem ${GMOCK_DIR}/include -I${GMOCK_DIR} \
-pthread -c ${GMOCK_DIR}/src/gmock-all.cc
ar -rv libgmock.a gtest-all.o gmock-all.o
(We need -pthread as Google Test and Google Mock use threads.)
Next, you should compile your test source file with
${GTEST_DIR}/include and ${GMOCK_DIR}/include in the header search
${GTEST\_DIR}/include and ${GMOCK\_DIR}/include in the header search
path, and link it with gmock and any other necessary libraries:
g++ -isystem ${GTEST_DIR}/include -isystem ${GMOCK_DIR}/include \
-pthread path/to/your_test.cc libgmock.a -o your_test
g++ -isystem ${GTEST_DIR}/include -isystem ${GMOCK_DIR}/include \
-pthread path/to/your_test.cc libgmock.a -o your_test
As an example, the make/ directory contains a Makefile that you can
use to build Google Mock on systems where GNU make is available
......@@ -206,13 +185,11 @@ script.
If the default settings are correct for your environment, the
following commands should succeed:
cd ${GMOCK_DIR}/make
make
./gmock_test
cd ${GMOCK_DIR}/make
make
./gmock_test
If you see errors, try to tweak the contents of make/Makefile to make
them go away. There are instructions in make/Makefile on how to do
it.
If you see errors, try to tweak the contents of [make/Makefile](make/Makefile) to make them go away.
### Windows ###
......@@ -223,11 +200,11 @@ selected tests.
Change to the appropriate directory and run "msbuild gmock.sln" to
build the library and tests (or open the gmock.sln in the MSVC IDE).
If you want to create your own project to use with Google Mock, you'll
have to configure it to use the gmock_config propety sheet. For that:
have to configure it to use the `gmock_config` propety sheet. For that:
* Open the Property Manager window (View | Other Windows | Property Manager)
* Right-click on your project and select "Add Existing Property Sheet..."
* Navigate to gmock_config.vsprops or gmock_config.props and select it.
* Navigate to `gmock_config.vsprops` or `gmock_config.props` and select it.
* In Project Properties | Configuration Properties | General | Additional
Include Directories, type <path to Google Mock>/include.
......@@ -238,11 +215,12 @@ Google Mock can be used in diverse environments. The default
configuration may not work (or may not work well) out of the box in
some environments. However, you can easily tweak Google Mock by
defining control macros on the compiler command line. Generally,
these macros are named like GTEST_XYZ and you define them to either 1
these macros are named like `GTEST_XYZ` and you define them to either 1
or 0 to enable or disable a certain feature.
We list the most frequently used macros below. For a complete list,
see file ${GTEST_DIR}/include/gtest/internal/gtest-port.h.
see file [${GTEST\_DIR}/include/gtest/internal/gtest-port.h](
../googletest/include/gtest/internal/gtest-port.h).
### Choosing a TR1 Tuple Library ###
......@@ -259,13 +237,13 @@ you need to tell Google Test and Google Mock to use the same TR1 tuple
library the rest of your project uses, or the two tuple
implementations will clash. To do that, add
-DGTEST_USE_OWN_TR1_TUPLE=0
-DGTEST_USE_OWN_TR1_TUPLE=0
to the compiler flags while compiling Google Test, Google Mock, and
your tests. If you want to force Google Test and Google Mock to use
their own tuple library, just add
-DGTEST_USE_OWN_TR1_TUPLE=1
-DGTEST_USE_OWN_TR1_TUPLE=1
to the compiler flags instead.
......@@ -277,13 +255,14 @@ it and set it up.
Google Mock is compact, so most users can build and link it as a static
library for the simplicity. Google Mock can be used as a DLL, but the
same DLL must contain Google Test as well. See Google Test's README
file for instructions on how to set up necessary compiler settings.
same DLL must contain Google Test as well. See
[Google Test's README][gtest_readme]
for instructions on how to set up necessary compiler settings.
### Tweaking Google Mock ###
Most of Google Test's control macros apply to Google Mock as well.
Please see file ${GTEST_DIR}/README for how to tweak them.
Please see [Google Test's README][gtest_readme] for how to tweak them.
Upgrading from an Earlier Version
---------------------------------
......@@ -296,24 +275,24 @@ do if you are upgrading from an earlier version of Google Mock.
### Upgrading from 1.1.0 or Earlier ###
You may need to explicitly enable or disable Google Test's own TR1
tuple library. See the instructions in section "Choosing a TR1 Tuple
Library".
tuple library. See the instructions in section "[Choosing a TR1 Tuple
Library](../googletest/#choosing-a-tr1-tuple-library)".
### Upgrading from 1.4.0 or Earlier ###
On platforms where the pthread library is available, Google Test and
Google Mock use it in order to be thread-safe. For this to work, you
may need to tweak your compiler and/or linker flags. Please see the
"Multi-threaded Tests" section in file ${GTEST_DIR}/README for what
you may need to do.
"[Multi-threaded Tests](../googletest#multi-threaded-tests
)" section in file Google Test's README for what you may need to do.
If you have custom matchers defined using MatcherInterface or
MakePolymorphicMatcher(), you'll need to update their definitions to
use the new matcher API [2]. Matchers defined using MATCHER() or
MATCHER_P*() aren't affected.
If you have custom matchers defined using `MatcherInterface` or
`MakePolymorphicMatcher()`, you'll need to update their definitions to
use the new matcher API (
[monomorphic](http://code.google.com/p/googlemock/wiki/CookBook#Writing_New_Monomorphic_Matchers),
[polymorphic](http://code.google.com/p/googlemock/wiki/CookBook#Writing_New_Polymorphic_Matchers)).
Matchers defined using `MATCHER()` or `MATCHER_P*()` aren't affected.
[2] http://code.google.com/p/googlemock/wiki/CookBook#Writing_New_Monomorphic_Matchers,
http://code.google.com/p/googlemock/wiki/CookBook#Writing_New_Polymorphic_Matchers
Developing Google Mock
----------------------
......@@ -328,13 +307,13 @@ For that you'll need Autotools. First, make sure you have followed
the instructions in section "SVN Checkout" to configure Google Mock.
Then, create a build output directory and enter it. Next,
${GMOCK_DIR}/configure # Standard GNU configure script, --help for more info
${GMOCK_DIR}/configure # Standard GNU configure script, --help for more info
Once you have successfully configured Google Mock, the build steps are
standard for GNU-style OSS packages.
make # Standard makefile following GNU conventions
make check # Builds and runs all tests - all should pass.
make # Standard makefile following GNU conventions
make check # Builds and runs all tests - all should pass.
Note that when building your project against Google Mock, you are building
against Google Test as well. There is no need to configure Google Test
......@@ -345,25 +324,27 @@ separately.
Some of Google Mock'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/gmock/gmock-generated-actions.h.pump is used to generate
gmock-generated-actions.h in the same directory.
file `include/gmock/gmock-generated-actions.h.pump` is used to generate
`gmock-generated-actions.h` in the same directory.
Normally you don't need to worry about regenerating the source files,
unless you need to modify them. In that case, you should modify the
corresponding .pump files instead and run the 'pump' script (for Pump
corresponding `.pump` files instead and run the 'pump' script (for Pump
is Useful for Meta Programming) to regenerate them. You can find
pump.py in the ${GTEST_DIR}/scripts/ directory. Read the Pump manual
[3] for how to use it.
pump.py in the `${GTEST_DIR}/scripts/` directory. Read the
[Pump manual](http://code.google.com/p/googletest/wiki/PumpManual)
for how to use it.
[3] http://code.google.com/p/googletest/wiki/PumpManual.
### Contributing a Patch ###
We welcome patches. Please read the Google Mock developer's guide [4]
We welcome patches. Please read the [Google Mock developer's Guide](
http://code.google.com/p/googlemock/wiki/DevGuide)
for how you can contribute. In particular, make sure you have signed
the Contributor License Agreement, or we won't be able to accept the
patch.
[4] http://code.google.com/p/googlemock/wiki/DevGuide
Happy testing!
[gtest_readme]: ../googletest/ "googletest"
docs/CheatSheet.md 0 → 100644
View file @ 07b2bd1f
This diff is collapsed.
docs/CookBook.md 0 → 100644
View file @ 07b2bd1f
This diff is collapsed.
docs/DesignDoc.md 0 → 100644
View file @ 07b2bd1f
This page discusses the design of new Google Mock features.
# Macros for Defining Actions #
## Problem ##
Due to the lack of closures in C++, it currently requires some
non-trivial effort to define a custom action in Google Mock. For
example, suppose you want to "increment the value pointed to by the
second argument of the mock function and return it", you could write:
```
int IncrementArg1(Unused, int* p, Unused) {
return ++(*p);
}
... WillOnce(Invoke(IncrementArg1));
```
There are several things unsatisfactory about this approach:
* Even though the action only cares about the second argument of the mock function, its definition needs to list other arguments as dummies. This is tedious.
* The defined action is usable only in mock functions that takes exactly 3 arguments - an unnecessary restriction.
* To use the action, one has to say `Invoke(IncrementArg1)`, which isn't as nice as `IncrementArg1()`.
The latter two problems can be overcome using `MakePolymorphicAction()`,
but it requires much more boilerplate code:
```
class IncrementArg1Action {
public:
template <typename Result, typename ArgumentTuple>
Result Perform(const ArgumentTuple& args) const {
return ++(*tr1::get<1>(args));
}
};
PolymorphicAction<IncrementArg1Action> IncrementArg1() {
return MakePolymorphicAction(IncrementArg1Action());
}
... WillOnce(IncrementArg1());
```
Our goal is to allow defining custom actions with the least amount of
boiler-plate C++ requires.
## Solution ##
We propose to introduce a new macro:
```
ACTION(name) { statements; }
```
Using this in a namespace scope will define an action with the given
name that executes the statements. Inside the statements, you can
refer to the K-th (0-based) argument of the mock function as `argK`.
For example:
```
ACTION(IncrementArg1) { return ++(*arg1); }
```
allows you to write
```
... WillOnce(IncrementArg1());
```
Note that you don't need to specify the types of the mock function
arguments, as brevity is a top design goal here. Rest assured that
your code is still type-safe though: you'll get a compiler error if
`*arg1` doesn't support the `++` operator, or if the type of
`++(*arg1)` isn't compatible with the mock function's return type.
Another example:
```
ACTION(Foo) {
(*arg2)(5);
Blah();
*arg1 = 0;
return arg0;
}
```
defines an action `Foo()` that invokes argument #2 (a function pointer)
with 5, calls function `Blah()`, sets the value pointed to by argument
#1 to 0, and returns argument #0.
For more convenience and flexibility, you can also use the following
pre-defined symbols in the body of `ACTION`:
| `argK_type` | The type of the K-th (0-based) argument of the mock function |
|:------------|:-------------------------------------------------------------|
| `args` | All arguments of the mock function as a tuple |
| `args_type` | The type of all arguments of the mock function as a tuple |
| `return_type` | The return type of the mock function |
| `function_type` | The type of the mock function |
For example, when using an `ACTION` as a stub action for mock function:
```
int DoSomething(bool flag, int* ptr);
```
we have:
| **Pre-defined Symbol** | **Is Bound To** |
|:-----------------------|:----------------|
| `arg0` | the value of `flag` |
| `arg0_type` | the type `bool` |
| `arg1` | the value of `ptr` |
| `arg1_type` | the type `int*` |
| `args` | the tuple `(flag, ptr)` |
| `args_type` | the type `std::tr1::tuple<bool, int*>` |
| `return_type` | the type `int` |
| `function_type` | the type `int(bool, int*)` |
## Parameterized actions ##
Sometimes you'll want to parameterize the action. For that we propose
another macro
```
ACTION_P(name, param) { statements; }
```
For example,
```
ACTION_P(Add, n) { return arg0 + n; }
```
will allow you to write
```
// Returns argument #0 + 5.
... WillOnce(Add(5));
```
For convenience, we use the term _arguments_ for the values used to
invoke the mock function, and the term _parameters_ for the values
used to instantiate an action.
Note that you don't need to provide the type of the parameter either.
Suppose the parameter is named `param`, you can also use the
Google-Mock-defined symbol `param_type` to refer to the type of the
parameter as inferred by the compiler.
We will also provide `ACTION_P2`, `ACTION_P3`, and etc to support
multi-parameter actions. For example,
```
ACTION_P2(ReturnDistanceTo, x, y) {
double dx = arg0 - x;
double dy = arg1 - y;
return sqrt(dx*dx + dy*dy);
}
```
lets you write
```
... WillOnce(ReturnDistanceTo(5.0, 26.5));
```
You can view `ACTION` as a degenerated parameterized action where the
number of parameters is 0.
## Advanced Usages ##
### Overloading Actions ###
You can easily define actions overloaded on the number of parameters:
```
ACTION_P(Plus, a) { ... }
ACTION_P2(Plus, a, b) { ... }
```
### Restricting the Type of an Argument or Parameter ###
For maximum brevity and reusability, the `ACTION*` macros don't let
you specify the types of the mock function arguments and the action
parameters. Instead, we let the compiler infer the types for us.
Sometimes, however, we may want to be more explicit about the types.
There are several tricks to do that. For example:
```
ACTION(Foo) {
// Makes sure arg0 can be converted to int.
int n = arg0;
... use n instead of arg0 here ...
}
ACTION_P(Bar, param) {
// Makes sure the type of arg1 is const char*.
::testing::StaticAssertTypeEq<const char*, arg1_type>();
// Makes sure param can be converted to bool.
bool flag = param;
}
```
where `StaticAssertTypeEq` is a compile-time assertion we plan to add to
Google Test (the name is chosen to match `static_assert` in C++0x).
### Using the ACTION Object's Type ###
If you are writing a function that returns an `ACTION` object, you'll
need to know its type. The type depends on the macro used to define
the action and the parameter types. The rule is relatively simple:
| **Given Definition** | **Expression** | **Has Type** |
|:---------------------|:---------------|:-------------|
| `ACTION(Foo)` | `Foo()` | `FooAction` |
| `ACTION_P(Bar, param)` | `Bar(int_value)` | `BarActionP<int>` |
| `ACTION_P2(Baz, p1, p2)` | `Baz(bool_value, int_value)` | `BazActionP2<bool, int>` |
| ... | ... | ... |
Note that we have to pick different suffixes (`Action`, `ActionP`,
`ActionP2`, and etc) for actions with different numbers of parameters,
or the action definitions cannot be overloaded on the number of
parameters.
## When to Use ##
While the new macros are very convenient, please also consider other
means of implementing actions (e.g. via `ActionInterface` or
`MakePolymorphicAction()`), especially if you need to use the defined
action a lot. While the other approaches require more work, they give
you more control on the types of the mock function arguments and the
action parameters, which in general leads to better compiler error
messages that pay off in the long run. They also allow overloading
actions based on parameter types, as opposed to just the number of
parameters.
## Related Work ##
As you may have realized, the `ACTION*` macros resemble closures (also
known as lambda expressions or anonymous functions). Indeed, both of
them seek to lower the syntactic overhead for defining a function.
C++0x will support lambdas, but they are not part of C++ right now.
Some non-standard libraries (most notably BLL or Boost Lambda Library)
try to alleviate this problem. However, they are not a good choice
for defining actions as:
* They are non-standard and not widely installed. Google Mock only depends on standard libraries and `tr1::tuple`, which is part of the new C++ standard and comes with gcc 4+. We want to keep it that way.
* They are not trivial to learn.
* They will become obsolete when C++0x's lambda feature is widely supported. We don't want to make our users use a dying library.
* Since they are based on operators, they are rather ad hoc: you cannot use statements, and you cannot pass the lambda arguments to a function, for example.
* They have subtle semantics that easily confuses new users. For example, in expression `_1++ + foo++`, `foo` will be incremented only once where the expression is evaluated, while `_1` will be incremented every time the unnamed function is invoked. This is far from intuitive.
`ACTION*` avoid all these problems.
## Future Improvements ##
There may be a need for composing `ACTION*` definitions (i.e. invoking
another `ACTION` inside the definition of one `ACTION*`). We are not
sure we want it yet, as one can get a similar effect by putting
`ACTION` definitions in function templates and composing the function
templates. We'll revisit this based on user feedback.
The reason we don't allow `ACTION*()` inside a function body is that
the current C++ standard doesn't allow function-local types to be used
to instantiate templates. The upcoming C++0x standard will lift this
restriction. Once this feature is widely supported by compilers, we
can revisit the implementation and add support for using `ACTION*()`
inside a function.
C++0x will also support lambda expressions. When they become
available, we may want to support using lambdas as actions.
# Macros for Defining Matchers #
Once the macros for defining actions are implemented, we plan to do
the same for matchers:
```
MATCHER(name) { statements; }
```
where you can refer to the value being matched as `arg`. For example,
given:
```
MATCHER(IsPositive) { return arg > 0; }
```
you can use `IsPositive()` as a matcher that matches a value iff it is
greater than 0.
We will also add `MATCHER_P`, `MATCHER_P2`, and etc for parameterized
matchers.
\ No newline at end of file
docs/DevGuide.md 0 → 100644
View file @ 07b2bd1f
If you are interested in understanding the internals of Google Mock,
building from source, or contributing ideas or modifications to the
project, then this document is for you.
# Introduction #
First, let's give you some background of the project.
## Licensing ##
All Google Mock source and pre-built packages are provided under the [New BSD License](http://www.opensource.org/licenses/bsd-license.php).
## The Google Mock Community ##
The Google Mock community exists primarily through the [discussion group](http://groups.google.com/group/googlemock), the
[issue tracker](http://code.google.com/p/googlemock/issues/list) and, to a lesser extent, the [source control repository](http://code.google.com/p/googlemock/source/checkout). You are definitely encouraged to contribute to the
discussion and you can also help us to keep the effectiveness of the
group high by following and promoting the guidelines listed here.
### Please Be Friendly ###
Showing courtesy and respect to others is a vital part of the Google
culture, and we strongly encourage everyone participating in Google
Mock development to join us in accepting nothing less. Of course,
being courteous is not the same as failing to constructively disagree
with each other, but it does mean that we should be respectful of each
other when enumerating the 42 technical reasons that a particular
proposal may not be the best choice. There's never a reason to be
antagonistic or dismissive toward anyone who is sincerely trying to
contribute to a discussion.
Sure, C++ testing is serious business and all that, but it's also
a lot of fun. Let's keep it that way. Let's strive to be one of the
friendliest communities in all of open source.
### Where to Discuss Google Mock ###
As always, discuss Google Mock in the official [Google C++ Mocking Framework discussion group](http://groups.google.com/group/googlemock). You don't have to actually submit
code in order to sign up. Your participation itself is a valuable
contribution.
# Working with the Code #
If you want to get your hands dirty with the code inside Google Mock,
this is the section for you.
## Checking Out the Source from Subversion ##
Checking out the Google Mock source is most useful if you plan to
tweak it yourself. You check out the source for Google Mock using a
[Subversion](http://subversion.tigris.org/) client as you would for any
other project hosted on Google Code. Please see the instruction on
the [source code access page](http://code.google.com/p/googlemock/source/checkout) for how to do it.
## Compiling from Source ##
Once you check out the code, you can find instructions on how to
compile it in the [README](http://code.google.com/p/googlemock/source/browse/trunk/README) file.
## Testing ##
A mocking framework is of no good if itself is not thoroughly tested.
Tests should be written for any new code, and changes should be
verified to not break existing tests before they are submitted for
review. To perform the tests, follow the instructions in [README](http://code.google.com/p/googlemock/source/browse/trunk/README) and
verify that there are no failures.
# Contributing Code #
We are excited that Google Mock is now open source, and hope to get
great patches from the community. Before you fire up your favorite IDE
and begin hammering away at that new feature, though, please take the
time to read this section and understand the process. While it seems
rigorous, we want to keep a high standard of quality in the code
base.
## Contributor License Agreements ##
You must sign a Contributor License Agreement (CLA) before we can
accept any code. The CLA protects you and us.
* If you are an individual writing original source code and you're sure you own the intellectual property, then you'll need to sign an [individual CLA](http://code.google.com/legal/individual-cla-v1.0.html).
* If you work for a company that wants to allow you to contribute your work to Google Mock, then you'll need to sign a [corporate CLA](http://code.google.com/legal/corporate-cla-v1.0.html).
Follow either of the two links above to access the appropriate CLA and
instructions for how to sign and return it.
## Coding Style ##
To keep the source consistent, readable, diffable and easy to merge,
we use a fairly rigid coding style, as defined by the [google-styleguide](http://code.google.com/p/google-styleguide/) project. All patches will be expected
to conform to the style outlined [here](http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml).
## Submitting Patches ##
Please do submit code. Here's what you need to do:
1. Normally you should make your change against the SVN trunk instead of a branch or a tag, as the latter two are for release control and should be treated mostly as read-only.
1. Decide which code you want to submit. A submission should be a set of changes that addresses one issue in the [Google Mock issue tracker](http://code.google.com/p/googlemock/issues/list). Please don't mix more than one logical change per submittal, because it makes the history hard to follow. If you want to make a change that doesn't have a corresponding issue in the issue tracker, please create one.
1. Also, coordinate with team members that are listed on the issue in question. This ensures that work isn't being duplicated and communicating your plan early also generally leads to better patches.
1. Ensure that your code adheres to the [Google Mock source code style](#Coding_Style.md).
1. Ensure that there are unit tests for your code.
1. Sign a Contributor License Agreement.
1. Create a patch file using `svn diff`.
1. We use [Rietveld](http://codereview.appspot.com/) to do web-based code reviews. You can read about the tool [here](http://code.google.com/p/rietveld/wiki/CodeReviewHelp). When you are ready, upload your patch via Rietveld and notify `googlemock@googlegroups.com` to review it. There are several ways to upload the patch. We recommend using the [upload\_gmock.py](http://code.google.com/p/googlemock/source/browse/trunk/scripts/upload_gmock.py) script, which you can find in the `scripts/` folder in the SVN trunk.
## Google Mock Committers ##
The current members of the Google Mock engineering team are the only
committers at present. In the great tradition of eating one's own
dogfood, we will be requiring each new Google Mock engineering team
member to earn the right to become a committer by following the
procedures in this document, writing consistently great code, and
demonstrating repeatedly that he or she truly gets the zen of Google
Mock.
# Release Process #
We follow the typical release process for Subversion-based projects:
1. A release branch named `release-X.Y` is created.
1. Bugs are fixed and features are added in trunk; those individual patches are merged into the release branch until it's stable.
1. An individual point release (the `Z` in `X.Y.Z`) is made by creating a tag from the branch.
1. Repeat steps 2 and 3 throughout one release cycle (as determined by features or time).
1. Go back to step 1 to create another release branch and so on.
---
This page is based on the [Making GWT Better](http://code.google.com/webtoolkit/makinggwtbetter.html) guide from the [Google Web Toolkit](http://code.google.com/webtoolkit/) project. Except as otherwise [noted](http://code.google.com/policies.html#restrictions), the content of this page is licensed under the [Creative Commons Attribution 2.5 License](http://creativecommons.org/licenses/by/2.5/).
\ No newline at end of file
docs/Documentation.md 0 → 100644
View file @ 07b2bd1f
This page lists all documentation wiki pages for Google Mock **(the SVN trunk version)**
- **if you use a released version of Google Mock, please read the documentation for that specific version instead.**
* [ForDummies](ForDummies.md) -- start here if you are new to Google Mock.
* [CheatSheet](CheatSheet.md) -- a quick reference.
* [CookBook](CookBook.md) -- recipes for doing various tasks using Google Mock.
* [FrequentlyAskedQuestions](FrequentlyAskedQuestions.md) -- check here before asking a question on the mailing list.
To contribute code to Google Mock, read:
* [DevGuide](DevGuide.md) -- read this _before_ writing your first patch.
* [Pump Manual](http://code.google.com/p/googletest/wiki/PumpManual) -- how we generate some of Google Mock's source files.
\ No newline at end of file
docs/ForDummies.md 0 → 100644
View file @ 07b2bd1f
This diff is collapsed.
docs/FrequentlyAskedQuestions.md 0 → 100644
View file @ 07b2bd1f
This diff is collapsed.
docs/KnownIssues.md 0 → 100644
View file @ 07b2bd1f
This diff is collapsed.
docs/ProjectHome.md 0 → 100644
View file @ 07b2bd1f
This diff is collapsed.
docs/V1_5_CheatSheet.md 0 → 100644
View file @ 07b2bd1f
This diff is collapsed.
docs/V1_5_CookBook.md 0 → 100644
View file @ 07b2bd1f
This diff is collapsed.
docs/V1_5_Documentation.md 0 → 100644
View file @ 07b2bd1f
This page lists all documentation wiki pages for Google Mock **version 1.5.0** -- **if you use a different version of Google Mock, please read the documentation for that specific version instead.**
* [ForDummies](V1_5_ForDummies.md) -- start here if you are new to Google Mock.
* [CheatSheet](V1_5_CheatSheet.md) -- a quick reference.
* [CookBook](V1_5_CookBook.md) -- recipes for doing various tasks using Google Mock.
* [FrequentlyAskedQuestions](V1_5_FrequentlyAskedQuestions.md) -- check here before asking a question on the mailing list.
To contribute code to Google Mock, read:
* DevGuide -- read this _before_ writing your first patch.
* [Pump Manual](http://code.google.com/p/googletest/wiki/PumpManual) -- how we generate some of Google Mock's source files.
\ No newline at end of file
docs/V1_5_ForDummies.md 0 → 100644
View file @ 07b2bd1f
This diff is collapsed.
docs/V1_5_FrequentlyAskedQuestions.md 0 → 100644
View file @ 07b2bd1f
This diff is collapsed.
docs/V1_6_CheatSheet.md 0 → 100644
View file @ 07b2bd1f
This diff is collapsed.
docs/V1_6_CookBook.md 0 → 100644
View file @ 07b2bd1f
This diff is collapsed.
docs/V1_6_Documentation.md 0 → 100644
View file @ 07b2bd1f
This diff is collapsed.
docs/V1_6_ForDummies.md 0 → 100644
View file @ 07b2bd1f
This diff is collapsed.
docs/V1_6_FrequentlyAskedQuestions.md 0 → 100644
View file @ 07b2bd1f
This diff is collapsed.
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment