proxygen
|
This guide will explain how to use the Google Testing Framework in your Xcode projects on Mac OS X. This tutorial begins by quickly explaining what to do for experienced users. After the quick start, the guide goes provides additional explanation about each step.
Here is the quick guide for using Google Test in your Xcode project.
svn checkout http://googletest.googlecode.com/svn/trunk/ googletest-read-only
gtest.xcodeproj
in the googletest-read-only/xcode/
directory and build the gtest.framework.The following sections further explain each of the steps listed above in depth, describing in more detail how to complete it including some variations.
Currently, the gtest.framework discussed here isn't available in a tagged release of Google Test, it is only available in the trunk. As explained at the Google Test [site](http://code.google.com/p/googletest/source/checkout">svn), you can get the code from anonymous SVN with this command:
Alternatively, if you are working with Subversion in your own code base, you can add Google Test as an external dependency to your own Subversion repository. By following this approach, everyone that checks out your svn repository will also receive a copy of Google Test (a specific version, if you wish) without having to check it out explicitly. This makes the set up of your project simpler and reduces the copied code in the repository.
To use svn:externals
, decide where you would like to have the external source reside. You might choose to put the external source inside the trunk, because you want it to be part of the branch when you make a release. However, keeping it outside the trunk in a version-tagged directory called something like third-party/googletest/1.0.1
, is another option. Once the location is established, use svn propedit svn:externals _directory_
to set the svn:externals property on a directory in your repository. This directory won't contain the code, but be its versioned parent directory.
The command svn propedit
will bring up your Subversion editor, making editing the long, (potentially multi-line) property simpler. This same method can be used to check out a tagged branch, by using the appropriate URL (e.g. http://googletest.googlecode.com/svn/tags/release-1.0.1
). Additionally, the svn:externals property allows the specification of a particular revision of the trunk with the -r_##_
option (e.g. externals/src/googletest -r60 http://googletest.googlecode.com/svn/trunk
).
Here is an example of using the svn:externals properties on a trunk (read via svn propget
) of a project. This value checks out a copy of Google Test into the trunk/externals/src/googletest/
directory.
The next step is to build and add the gtest.framework to your own project. This guide describes two common ways below.
To start writing tests, make a new "Shell Tool" target. This target template is available under BSD, Cocoa, or Carbon. Add your unit test source code to the "Compile Sources" build phase of the target.
Next, you'll want to add gtest.framework in two different ways, depending upon which option you chose above.
Since the unit test executable is a shell tool, it doesn't have a bundle with a Contents/Frameworks
directory, in which to place gtest.framework. Instead, the dynamic linker must be told at runtime to search for the framework in another location. This can be accomplished by setting the "DYLD\_FRAMEWORK\_PATH" environment variable in the "Edit Active Executable ..." Arguments tab, under "Variables to be set in the environment:". The path for this value is the path (relative or absolute) of the directory containing the gtest.framework.
If you haven't set up the DYLD_FRAMEWORK_PATH, correctly, you might get a message like this:
To correct this problem, got to the directory containing the executable named in "Referenced from:" value in the error message above. Then, with the terminal in this location, find the relative path to the directory containing the gtest.framework. That is the value you'll need to set as the DYLD_FRAMEWORK_PATH.
Now, when you click "Build and Go", the test will be executed. Dumping out something like this:
Unit testing is a valuable way to ensure your data model stays valid even during rapid development or refactoring. The Google Testing Framework is a great unit testing framework for C and C++ which integrates well with an Xcode development environment.