Googletest in Netbeans for Test Driven Development

Netbeans is my favoured IDE for C/C++ development. It has some support for test driven development but not for Googletest which I like for its simplicity. Find out how to use Googletest in Netbeans for embedded TDD.

This is the first section in a two part article on using Googletest for test driven development in the Netbeans IDE.

Part 1 will  show you how to get googletest, add it to your Netbeans project and use it to run unit tests on your code.

Part 2 will show you how to do some very simple test driven development of a sample library using the googletest tests.

Netbeans

One of the nice featues of recent versions of Netbeans is that you can easily set up unit tests. Built into the IDE is the ability to create a test and run it separately from the main build.
This is not the place to go into how to set up Netbeans projects. Perhaps I will do that later. For now, I assume you have Netbeans and know how to create a project from existing sources or create a new project from scratch.

Embedded Development

The constraint here is that the main project and the test project have to be built with the same toolchain. That means that, if you have Netbeans set up to use, say GCC for the ARM, the tests will be built by the same tool and thus will only run on the target. There may be occsions where that is a good idea but, it is not how I want to work when developing new code and refactoring old code. Instead, I set up my project to use one of the desktop compilers on my machine. Then I add whatever links to include directories are needed for the Netbeans code assistance to work properly. I can not build for the embedded target but I can compile the code for the desktop. Clearly, there will be issues in running any code that relies on hardware but that can be worked around as needed.

If I am developing for the desktop or simply working some some library code, then I can just set things up using whatever defaults Netbeans provides.

In both cases, the process for creating and using unit tests is the same. For illustration here, I will set up Googletest for use with the desktop tools and use it to develop a small set of functions for manipulating rectangles. The process will work with both C and C++ projects but, since Googletest is all C++, any C header files will need guards to ensure the functions link properly.

Test Driven Development

Put simply, the idea behind test driven development (TDD) is that no code is written unless it is to make a test pass. The programmer decides what behaviour is required from the code andwrites a test. The test should fail because the code has not been writen or the feature not added. At this stage, the least amount of code is written or modified that will allow the test to compile, run and pass. No more. Additional features and functionality require additional tests. Without the test, you cannot know if the code works. Once the tests have all passed, the programmer can then do any refactoring needed to improve readability or code structure. During this time, the tests are run frequently to ensure that they all pass. So long as that is the case, the code cannot be broken. This is a good time to make a commit to the chosen source control system – assuming that has not been happening all along anyway.

This cycle is repeated until all the features and functionality are present. The test suite grows withthe project and, since no code gets written without a test preceding it, the tests drive the project development. At every stage, the code will be working – at least in terms of the soecification to date. New features can be proven not to break existing code and teams working on a project can be sure their contribution has not broken anyone elses.

Googletest

Googletest – or gtest when I am feeling more lazy – is a framework for creating tests in a simple and intuitive manner. The tests are genrally quite simple and the reporting method is very clear in showing the success or failure of the test suite. There is provision for more complex testing and the creation of test fixtures and mocks if that is required. If you don’t know what they are, you don’t need them yet.

Another great benefit of gtest in terms of this article is that the installation and configuration can be very simple without the need for full installs of libraries and programs on your computer. By just adding some source files to your existing project, you get to carry the test facility with the project and can relatively easily work on the project on another system. This is particularly handy if you work on a team project held in a source repository on something like github. Others can easily clone the entire project and run the tests without worrying that they don’t have the correct testing environment installed on their machine.

Grabbing Googletest

The first thing is to download a copy of the current versin of gtest. It can be found on github here https://github.com/google/googletest. Download the zip file and unpack it to some convenient location on your computer. The zip will unpack to a folder called googletest-master. in there is a folder called googletest with the following contents:

├── googletest
│   ├── CHANGES
│   ├── CMakeLists.txt
│   ├── CONTRIBUTORS
│   ├── LICENSE
│   ├── Makefile
│   ├── README.md
│   ├── build-aux
│   ├── cmake
│   ├── codegear
│   ├── configure.ac
│   ├── docs
│   ├── include
│   ├── m4
│   ├── make
│   ├── msvc
│   ├── samples
│   ├── scripts
│   ├── src
│   ├── test
│   └── xcode

I am going to ignore all the installation stuff, samples and so on and extract out the source files needed to add gtest to your project.

First create a new folder somewhere outside the googletest-master folder and call it gtest. Into that copy the googletest-master/googletest/src folder. Next copy in the googletest-master/googletest/include/gtest folder into the new gtest folder. Your new folder structure should look like this:

gtest
├── gtest
│   ├── gtest-death-test.h
│   ├── gtest-message.h
│   ├── gtest-param-test.h
│   ├── gtest-param-test.h.pump
│   ├── gtest-printers.h
│   ├── gtest-spi.h
│   ├── gtest-test-part.h
│   ├── gtest-typed-test.h
│   ├── gtest.h
│   ├── gtest_pred_impl.h
│   ├── gtest_prod.h
│   └── internal
│   ├── custom
│   │   ├── gtest-port.h
│   │   ├── gtest-printers.h
│   │   └── gtest.h
│   ├── gtest-death-test-internal.h
│   ├── gtest-filepath.h
│   ├── gtest-internal.h
│   ├── gtest-linked_ptr.h
│   ├── gtest-param-util-generated.h
│   ├── gtest-param-util-generated.h.pump
│   ├── gtest-param-util.h
│   ├── gtest-port-arch.h
│   ├── gtest-port.h
│   ├── gtest-string.h
│   ├── gtest-tuple.h
│   ├── gtest-tuple.h.pump
│   ├── gtest-type-util.h
│   └── gtest-type-util.h.pump
└── src
├── gtest-all.cc
├── gtest-death-test.cc
├── gtest-filepath.cc
├── gtest-internal-inl.h
├── gtest-port.cc
├── gtest-printers.cc
├── gtest-test-part.cc
├── gtest-typed-test.cc
├── gtest.cc
└── gtest_main.cc

To be honest, that is quite a lot of stuff. 1.3MB in my example. Never mind, you don’t have to look into any of it to make it work.

This folder is going to be copied into any project where you want to use googletest.

Create a Netbeans project

In this example, I will create a new C application to run from the command line. For now it will have just a main.c that prints a short message to the screen. Check that the program builds and runs. My project is called rectangles and it lives in a folder called rectangles. Copy the new gtest folder into the project folder and the folder structure will look like this:

├── Makefile
├── gtest
│   ├── gtest
│   │   ├── gtest-death-test.h
│   │   ├── gtest-message.h
│   │   ├── gtest-param-test.h
│   │   ├── gtest-param-test.h.pump
│   │   ├── gtest-printers.h
│   │   ├── gtest-spi.h
│   │   ├── gtest-test-part.h
│   │   ├── gtest-typed-test.h
│   │   ├── gtest.h
│   │   ├── gtest_pred_impl.h
│   │   ├── gtest_prod.h
│   │   └── internal
│   │   ├── custom
│   │   │   ├── gtest-port.h
│   │   │   ├── gtest-printers.h
│   │   │   └── gtest.h
│   │   ├── gtest-death-test-internal.h
│   │   ├── gtest-filepath.h
│   │   ├── gtest-internal.h
│   │   ├── gtest-linked_ptr.h
│   │   ├── gtest-param-util-generated.h
│   │   ├── gtest-param-util-generated.h.pump
│   │   ├── gtest-param-util.h
│   │   ├── gtest-port-arch.h
│   │   ├── gtest-port.h
│   │   ├── gtest-string.h
│   │   ├── gtest-tuple.h
│   │   ├── gtest-tuple.h.pump
│   │   ├── gtest-type-util.h
│   │   └── gtest-type-util.h.pump
│   └── src
│   ├── gtest-all.cc
│   ├── gtest-death-test.cc
│   ├── gtest-filepath.cc
│   ├── gtest-internal-inl.h
│   ├── gtest-port.cc
│   ├── gtest-printers.cc
│   ├── gtest-test-part.cc
│   ├── gtest-typed-test.cc
│   ├── gtest.cc
│   └── gtest_main.cc
├── main.c
└── nbproject
├── Makefile-Debug.mk
├── Makefile-Release.mk
├── Makefile-impl.mk
├── Makefile-variables.mk
├── Package-Debug.bash
├── Package-Release.bash
├── configurations.xml
├── private
│   ├── Makefile-variables.mk
│   ├── configurations.xml
│   ├── launcher.properties
│   └── private.xml
└── project.xml

Modify the project settings in Netbeans

Check that your project still builds and runs. None of the gtest code needs to, or should, appear in your Netbeans project. However, you will need to add some paths to the Netbeans project and a reference to one of the files in the gtest/src folder.

Add a C++ Simple test

First, right click the project name and choose Add a C++ SimpleTest. You won’t be using the test but creating it tells Netbeans to set up the projct for testing and creates the appropriate build targets. Give the test any descriptive name you like. Make sure the test file goes in a folder named test and the test file name is testRunner.cpp:

In the project view of Netbeans, your project should look like this:

If you want, you can right click the project and select test. You should see the test build and execute. The result should be a message in the IDE telling you that one test succeeded and one test failed. You don’t want all that stuff in testRunner.cpp so delete the contents of the file and replace it with this code:

Before any test can run, two more changes must be made.

Set the Include path for tests

First, the gtest code needs to know where to find its include folder. Right click the TestFiles folder in the project, select properties and, in the C++ compiler section add an entry for the include directories pointing to the gtest folder. Make sure it is a relative link to allow your project to be moved safely later if needed.

Add a reference to the gtest code

Rather than add all the gtest source code files to the test project, it is only necessary to add one. The file gtest-all.cc includes all the others and must be present in the test folder. Right click the test folder that contains your testRunner.cpp file and select Add Existing Item. In the dialogue, find src/gtest-all.cc and select it. Make the reference relative as before so that your project can be moved around safely.

Try out the test setup

If you now run Test on the project, all the gtest code will build and you will be rewarded with the boring message

hello
[==========] Running 0 tests from 0 test cases.

But at least now you know your test environment is working

In part 2, I will look at using the gtest setup to do some simple test driven development.