UnitTesting

This document is under development by killerbot. Starting from 7 September 2009.

Introduction

This document will describe how unit testing can be combined with the Code::Blocks IDE. It will give a hands-on example on a unit testing framework and how it can be used with Code::Blocks.

What is Unit Testing

Simply put Unit Testing is the discipline and best practice of writing and running little test programs that test little units of code. Such a unit can be :

• a class
• a free function
• an interface
• ...

There are several unit test frameworks available to help you write, deploy, manage your unit tests. The most famous family is the xUnit framework, and some of it's descendants.

Why Unit Testing

When code is written that implements some functionality. A way to check and prove that the implementation is correct is needed. Therefor, tests are needed. Tests are needed at different levels :

• the application level; and
• the integration level of different components, classes, and interfaces.

But tests are also needed for the smallest building blocks, the units. These tests need to run very quickly. Thus, the tests can be run often - manually or automated. These tests will also be our safeguards during refactoring, extending, or maintaining the code. These tests encourage the programmer to think of the use of the class, method, or whatever unit because the test can be seen as a user of our code. Thanks to this process, thinking about the tests before implementing the functionality can help the programmer in the design : emergent design. It will help the programmer to avoid creating big classes and complex functions. The programmer will only write the methods that are really needed, and no methods that the programmer thinks might ever - or never - be useful in the future. Programmers are not good future tellers! Those 'might be needed' methods and their tests are simply a waste of time. Extending and refactoring will be done when it is actually needed, and at that time the programmer have unit tests to ensure they don't break any existing code.

Other times when a programmer might add a new unit test is - typically - when a bug is discovered. The programmer will: (1)write a unit test to reproduce the bug; (2) fix the code; and (3) from now on the new unit test will watch the programmer's back so the bug won't reappear.

Unit test are also a good place of documentation. The little tests show how the class or method is used. The code documents itself.

So the benefits are :

• better design
• prove of your code
• safe guard during code maintenance (refactoring, extensions)
• documentation
• ...

Unit Test frameworks

When writing unit tests, one will create a lot of similar code. Because unit tests are nothing more then little programs, several tasks will be repeated: (1)setting up the test environment; (2)create your class; (3)call a method; (4)verify its result; (5)write out an error message - preferably specifying the wrong outcome - when the test fails; and (6) what the expected result is. All these repetitive chores are taken care of by the frame work so the developer can focus on the real code of the test. This document will use a small but very effective framework for the C++ language. It is called UnitTest++. It's homepage is at : UnitTest++. You can download it directly at this [1]. At the time of writing the latest version is 1.4.

Setup our environment

Let's create a directory on our PC in which we will cary out our experiments. I will refer to this directory from now on as <TestPit>. For my laptop on which I am writing this article, that will be /home/lieven/Projects/UnitTestArticle. Note that everything we will do, works on linux and on windows! Download the "unittest-cpp-1.4.zip" file from the link specified above. Extract it in the <TestPit> directory. All the files will end up in the <TestPit>/UnitTest++ directory.

Build UnitTest++

After the extracted the zip archive we have a directory structure like this :

<TestPit>/UnitTest++
|
+docs
|
+src

The files in the UnitTest++ directory are of little use for us, since they bring project files for some bizarre Microsoft IDE ;-) . We will create our own Code::Blocks project to build the UnitTest++ framework.

Why do we need to build something ? Well as said, the framework will do a lot of chores for us, those chores are implemented by code, that code is the framework. We will build to framework into a static library, and for every unit test (or set of unit tests) we create a little (console/shell) program with the test code we wrote, which will link with the static library to obtain a unit test executable, driven by the framework.

We will put our Code::Blocks project file in a nice structured directory tree, therefor let's create a 'Project' subdirectory in the <TestPit>/UnitTest++ directory.

In there create a new file with the name "UnitTest++.cbp". Give that file the following content :

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<CodeBlocks_project_file>
	<FileVersion major="1" minor="6" />
	<Project>
		<Option title="UnitTest++" />
		<Option pch_mode="2" />
		<Option compiler="gcc" />
		<Build>
			<Target title="Debug">
				<Option platforms="Windows;" />
				<Option output="../Deliv/Debug/libUnitTest++.a" prefix_auto="0" extension_auto="0" />
				<Option working_dir="" />
				<Option object_output="../Deliv/Debug/" />
				<Option type="2" />
				<Option compiler="gcc" />
				<Option createDefFile="1" />
				<Compiler>
					<Add option="-Winit-self" />
					<Add option="-Wredundant-decls" />
					<Add option="-Wcast-align" />
					<Add option="-Wundef" />
					<Add option="-Wfloat-equal" />
					<Add option="-Wmissing-declarations" />
					<Add option="-Wmissing-include-dirs" />
					<Add option="-Wswitch-enum" />
					<Add option="-Wswitch-default" />
					<Add option="-Wmain" />
					<Add option="-pedantic" />
					<Add option="-std=c++98" />
					<Add option="-Wextra" />
					<Add option="-Wall" />
					<Add option="-ansi" />
					<Add option="-g" />
				</Compiler>
			</Target>
			<Target title="Release">
				<Option platforms="Windows;" />
				<Option output="../Deliv/Release/libUnitTest++.a" prefix_auto="0" extension_auto="0" />
				<Option working_dir="" />
				<Option object_output="../Deliv/Release/" />
				<Option type="2" />
				<Option compiler="gcc" />
				<Option createDefFile="1" />
				<Compiler>
					<Add option="-O3" />
					<Add option="-Winit-self" />
					<Add option="-Wredundant-decls" />
					<Add option="-Wcast-align" />
					<Add option="-Wundef" />
					<Add option="-Wfloat-equal" />
					<Add option="-Wmissing-declarations" />
					<Add option="-Wmissing-include-dirs" />
					<Add option="-Wswitch-enum" />
					<Add option="-Wswitch-default" />
					<Add option="-Wmain" />
					<Add option="-pedantic" />
					<Add option="-std=c++98" />
					<Add option="-Wextra" />
					<Add option="-Wall" />
					<Add option="-ansi" />
				</Compiler>
				<Linker>
					<Add option="-s" />
				</Linker>
			</Target>
			<Target title="Debug(linux)">
				<Option platforms="Unix;Mac;" />
				<Option output="../Deliv/Debug/libUnitTest++.a" prefix_auto="0" extension_auto="0" />
				<Option working_dir="" />
				<Option object_output="../Deliv/Debug/" />
				<Option type="2" />
				<Option compiler="gcc" />
				<Option createDefFile="1" />
				<Compiler>
					<Add option="-Winit-self" />
					<Add option="-Wredundant-decls" />
					<Add option="-Wcast-align" />
					<Add option="-Wundef" />
					<Add option="-Wfloat-equal" />
					<Add option="-Wmissing-declarations" />
					<Add option="-Wmissing-include-dirs" />
					<Add option="-Wswitch-enum" />
					<Add option="-Wswitch-default" />
					<Add option="-Wmain" />
					<Add option="-pedantic" />
					<Add option="-std=c++98" />
					<Add option="-Wextra" />
					<Add option="-Wall" />
					<Add option="-ansi" />
					<Add option="-g" />
				</Compiler>
			</Target>
			<Target title="Release(linux)">
				<Option platforms="Unix;Mac;" />
				<Option output="../Deliv/Release/libUnitTest++.a" prefix_auto="0" extension_auto="0" />
				<Option working_dir="" />
				<Option object_output="../Deliv/Release/" />
				<Option type="2" />
				<Option compiler="gcc" />
				<Option createDefFile="1" />
				<Compiler>
					<Add option="-O3" />
					<Add option="-Winit-self" />
					<Add option="-Wredundant-decls" />
					<Add option="-Wcast-align" />
					<Add option="-Wundef" />
					<Add option="-Wfloat-equal" />
					<Add option="-Wmissing-declarations" />
					<Add option="-Wmissing-include-dirs" />
					<Add option="-Wswitch-enum" />
					<Add option="-Wswitch-default" />
					<Add option="-Wmain" />
					<Add option="-pedantic" />
					<Add option="-std=c++98" />
					<Add option="-Wextra" />
					<Add option="-Wall" />
					<Add option="-ansi" />
				</Compiler>
				<Linker>
					<Add option="-s" />
				</Linker>
			</Target>
		</Build>
		<VirtualTargets>
			<Add alias="All" targets="Debug;Release;Debug(linux);Release(linux);" />
		</VirtualTargets>
		<Unit filename="../UnitTest++/AssertException.cpp" />
		<Unit filename="../UnitTest++/AssertException.h" />
		<Unit filename="../UnitTest++/CheckMacros.h" />
		<Unit filename="../UnitTest++/Checks.cpp" />
		<Unit filename="../UnitTest++/Checks.h" />
		<Unit filename="../UnitTest++/Config.h" />
		<Unit filename="../UnitTest++/CurrentTest.cpp" />
		<Unit filename="../UnitTest++/CurrentTest.h" />
		<Unit filename="../UnitTest++/DeferredTestReporter.cpp" />
		<Unit filename="../UnitTest++/DeferredTestReporter.h" />
		<Unit filename="../UnitTest++/DeferredTestResult.cpp" />
		<Unit filename="../UnitTest++/DeferredTestResult.h" />
		<Unit filename="../UnitTest++/ExecuteTest.h" />
		<Unit filename="../UnitTest++/MemoryOutStream.cpp" />
		<Unit filename="../UnitTest++/MemoryOutStream.h" />
		<Unit filename="../UnitTest++/Posix/SignalTranslator.cpp">
			<Option target="Debug(linux)" />
			<Option target="Release(linux)" />
		</Unit>
		<Unit filename="../UnitTest++/Posix/SignalTranslator.h">
			<Option target="Debug(linux)" />
			<Option target="Release(linux)" />
		</Unit>
		<Unit filename="../UnitTest++/Posix/TimeHelpers.cpp">
			<Option target="Debug(linux)" />
			<Option target="Release(linux)" />
		</Unit>
		<Unit filename="../UnitTest++/Posix/TimeHelpers.h">
			<Option target="Debug(linux)" />
			<Option target="Release(linux)" />
		</Unit>
		<Unit filename="../UnitTest++/ReportAssert.cpp" />
		<Unit filename="../UnitTest++/ReportAssert.h" />
		<Unit filename="../UnitTest++/RequiredCheckException.cpp" />
		<Unit filename="../UnitTest++/RequiredCheckException.h" />
		<Unit filename="../UnitTest++/RequiredCheckTestReporter.cpp" />
		<Unit filename="../UnitTest++/RequiredCheckTestReporter.h" />
		<Unit filename="../UnitTest++/RequireMacros.h" />
		<Unit filename="../UnitTest++/Test.cpp" />
		<Unit filename="../UnitTest++/Test.h" />
		<Unit filename="../UnitTest++/TestDetails.cpp" />
		<Unit filename="../UnitTest++/TestDetails.h" />
		<Unit filename="../UnitTest++/TestList.cpp" />
		<Unit filename="../UnitTest++/TestList.h" />
		<Unit filename="../UnitTest++/TestMacros.h" />
		<Unit filename="../UnitTest++/TestReporter.cpp" />
		<Unit filename="../UnitTest++/TestReporter.h" />
		<Unit filename="../UnitTest++/TestReporterStdout.cpp" />
		<Unit filename="../UnitTest++/TestReporterStdout.h" />
		<Unit filename="../UnitTest++/TestResults.cpp" />
		<Unit filename="../UnitTest++/TestResults.h" />
		<Unit filename="../UnitTest++/TestRunner.cpp" />
		<Unit filename="../UnitTest++/TestRunner.h" />
		<Unit filename="../UnitTest++/TestSuite.h" />
		<Unit filename="../UnitTest++/TimeConstraint.cpp" />
		<Unit filename="../UnitTest++/TimeConstraint.h" />
		<Unit filename="../UnitTest++/TimeHelpers.h" />
		<Unit filename="../UnitTest++/UnitTest++.h" />
		<Unit filename="../UnitTest++/Win32/TimeHelpers.cpp">
			<Option target="Debug" />
			<Option target="Release" />
		</Unit>
		<Unit filename="../UnitTest++/Win32/TimeHelpers.h">
			<Option target="Debug" />
			<Option target="Release" />
		</Unit>
		<Unit filename="../UnitTest++/XmlTestReporter.cpp" />
		<Unit filename="../UnitTest++/XmlTestReporter.h" />
		<Extensions>
			<envvars />
			<code_completion />
			<debugger />
		</Extensions>
	</Project>
</CodeBlocks_project_file>

Some things to note about the content of the project file, the power of Code::Blocks.

• there are 4 targets : Debug/Release for Windows and Debug/Release for linux [yes : 1 project file that allows building on linux and on windows]
• some files are only part of the linux targets, some only for the windows targets

But before we build, let's modify some source files (not really needed, but I prefer to have warning free compilations). These are the changes I carried out :

• DeferredTestResult.h: remove semicolon after UNITTEST_STDVECTOR_LINKAGE(UnitTest::DeferredTestFailure)
• DeferredTestReporter.h: remove semicolon after UNITTEST_STDVECTOR_LINKAGE(UnitTest::DeferredTestResult)

Next open up this project file in Code::Blocks and build the debug and release target. From now one we will only use the Release target, we go for speed ;-)

The result of the build process will show up in subdirectories of the new 'Deliv' subdirectory of <testPit>/UnitTest++ : <testPit>/UnitTest++/Deliv/Release/libUnitTest++.a

Alright, we have build the unit test framework in a platform independent way, no silly makefiles, no obscure M$ IDE, good old super Code::Blocks. It is time to write some code so we have something to unit test.

In the first example we will create a simple free function that checks if a given year is a leap year or not.

The business logic is as follows : a year is a leap year when it can be divided by 4, unless it can be divided by 100. But in case it can be divided by 400, then again it is a leap year.

In the next section we will first setup a Code::Blocks project containing both the 'functionality files, and the unit test files. Typically one will package several functionality files into a static library and create a unit test project that tests all the class/functionalities in that library package, also called a component. That is we have a component (whose deliverable is the static library, and we have a unit test project that tests the entire component).

Our first test project environment

Let's create a new directory in our <TestPit> : <TestPit>/LeapYear. For the simplicity we will put the project file and the source file all together in this directory. Normally we would work in a more structured way, but in a demo article we have some artistic freedom ;-) Next you can create with the Code::Block's wizard a new console project in the LeapYear directory. Or you can create the following 5 files and give the the contents as specified below. Note that this demo works on linux and on windows, everything is still completely platform independent. Long Live Code::Blocks.

The project file : LeapYear.cbp (the one below already contains the 4 source files, in case you use the wizard you have to add the LeapYear.h/cpp and LeapYearTest.cpp files to the project)

    <?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
    <CodeBlocks_project_file>
        <FileVersion major="1" minor="6" />
    	<Project>
		<Option title="LeapYear" />
		<Option pch_mode="2" />
		<Option compiler="gcc" />
		<Build>
			<Target title="Debug">
				<Option output="Deliv/Debug/LeapYear" prefix_auto="1" extension_auto="1" />
				<Option object_output="Deliv/Debug/" />
				<Option type="1" />
				<Option compiler="gcc" />
				<Compiler>
					<Add option="-g" />
				</Compiler>
			</Target>
			<Target title="Release">
				<Option output="Deliv/Release/LeapYear" prefix_auto="1" extension_auto="1" />
				<Option object_output="Deliv/Release/" />
				<Option type="1" />
				<Option compiler="gcc" />
				<Compiler>
					<Add option="-O2" />
				</Compiler>
				<Linker>
					<Add option="-s" />
				</Linker>
			</Target>
		</Build>
		<Compiler>
			<Add option="-Wall" />
			<Add option="-fexceptions" />
		</Compiler>
		<Unit filename="LeapYear.cpp" />
		<Unit filename="LeapYear.h" />
		<Unit filename="LeapYearTest.cpp" />
		<Unit filename="main.cpp" />
		<Extensions>
			<envvars />
			<code_completion />
			<lib_finder disable_auto="1" />
			<debugger />
		</Extensions>
	</Project>
    </CodeBlocks_project_file>

The main source file : main.cpp

   int main()
   {
       return 0;
   }

The header exporting our powerful function : LeapYear.h

   #ifndef LEAPYEAR_H_INCLUDED 
   #define LEAPYEAR_H_INCLUDED
   
   #endif // LEAPYEAR_H_INCLUDED

And the implementation of the leap year logic : LeapYear.cpp

   #include "LeapYear.h"

And finishing with the source file for the tests : LeapYearTest.cpp (currently) empty

We can already build the project, we have a nice little program that does .... nothing.

Time to move to the next section, a little word about Test Driven Development.

Test Driven Development

This is a practice where new code is only added to make a failing test pass. And one only adds the code needed to make that test pass. Once that is done, a new test is added that will check the next functionality to add. On this really simple example we will more or less practice some TDD.

So get ready, it's time for LeapYear-Step1.

LeapYear-Step1

We will turn our main.cpp into the guy in charge to carry out the tests, all we need to do is change the contents of main.cpp into this :

    #include "UnitTest++.h"
    
    int main()
    {
        return UnitTest::RunAllTests();
    }

And add ../UnitTest++/src to the compiler search directories on the project level of our LeapYear project. And add ../UnitTest++/Deliv/Release/libUnitTest++.a to the link libraries of the project

Why : well we need to link with the framework and we need to include the UnitTest++ header so we can use it's functionalities.

The line UnitTest::RunAllTests() will make sure all test encountered in our sources will be carried out. We don't have any tests yet, nor any functionality, but go ahead build the project and run it. This is the output :

   Success: 0 tests passed
   Test time: 0.00 seconds.

Great : success, but no tests yet. Well it's a start. Time to move forward, and write our first test.

LeapYear-Step2

Test, test, but there's nothing to test. Yes, absolutely. Let's think of a test, a test that will help us in the design. Now that's a good idea. Suppose I would be the user of the uplifting problem solving leap year checking library/component ... hmmm modesty first : leap year checking function. How would I like that function to look.

    bool IsLeapYear(int Year);

Yes that seems acceptable. So let's write a test that will call that method. We do that by adding the following code to LeapYearTest.cpp

    #include "UnitTest++.h"
    
    namespace
    {
    
    TEST(OurFirstTest)
    {
        const bool Result = IsLeapYear(1972);
        CHECK_EQUAL(true, Result);
    }
    
    }

Things to note :

• we include the unit test header
• it is good to put the tests in a nameless namespace (will be explained later on)
• we use the TEST macro, the argument is the name of the test : OurFirstTest
• we use CHECK_EQUAL to check if the expected result (the first argument) matches the computed result (the second argument)

Time to build. Woooooops errors. The test fails completely, it does not even build. Time to add the code needed. In order to compile the test file, we need to include the LeapYear.h header and have that header export our function. Our LeapYear header will look like this now (don't forget the include in the test file of our LeapYear.h header, it is not shown here) :

    #ifndef LEAPYEAR_H_INCLUDED
    #define LEAPYEAR_H_INCLUDED
    
    bool IsLeapYear(int Year);
    
    #endif // LEAPYEAR_H_INCLUDED

At least now it compiles, but it doesn't link yet. Duh ! That's because we don't have an implementation yet. Time to provide the bare minimum of code to make the test pass. So we change the LeapYear.cpp into :

    #include "LeapYear.h"
    
    bool IsLeapYear(int /*Year*/)
    {
    	return true;
    }

Build it, run it. Yes, we have one working test. Great. Let's move on.

LeapYear-Step3

Does anyone have the feeling we are cheating? Well the user does not know how we wrote our code on the inside. So just to be sure the user (we) adds the following test, ending up in :

    #include "UnitTest++.h"
    
    namespace
    {
    
    TEST(OurFirstTest)
    {
        const bool Result = IsLeapYear(1972);
        CHECK_EQUAL(true, Result);
    }
    
    TEST(OurSecondTest)
    {
        const bool Result = IsLeapYear(1973);
        CHECK_EQUAL(false, Result);
    }
    
    }

Building is already no issue any more, we can run it. Oh boy, a test is failing. The framework tell us something like this :

   <filename>:<Line>: error: Failure in OurSecondTest: Expected 0 but was 1
   FAILURE: 1 out of 2 tests failed (1 failures)
   Test time: 0.00 seconds.

So we are informed of the line where the failing test occurs, next to that it tells us what it was expecting and what the actual outcome was. And it presents a resume of the total number of tests, and how many that failed. For you scripting hackers note that FAILURE != SUCCESS.

It seems we should do some more effort and implement some real logic.

LeapYear-Step4

Let's keep it taking one step at a time. Let's start by implementing the 'divisible by 4' logic. That will already solve our tests. So our LeapYear.cpp will now look like this :

  #include "LeapYear.h"
  
  namespace
  {
  
  bool IsDivisableBy4(int Year)
  {
  	return (Year%4) == 0;
  }
  
  }
  
  bool IsLeapYear(int Year)
  {
  	return IsDivisableBy4(Year);
  }

Build, run. All tests pass. Life is great.

But those changing requirements, always the change of the requirements. Years that can be divided by 100 should not be considered as a leap year.

Time for our next step.

LeapYear-Step5

We add a new test for checking for example the year 1900.

TEST(DivisableBy100)
{
	const bool Result = IsLeapYear(1900);
	CHECK_EQUAL(false, Result);
}

Build and run the tests. It will fail. So time to add the minimum code needed to make this test pass. This will change our LeapYear.cpp into :

#include "LeapYear.h"

namespace
{

bool IsDivisableBy100(int Year)
{
	return (Year%100) == 0;
}

bool IsDivisableBy4(int Year)
{
	return (Year%4) == 0;
}

}

bool IsLeapYear(int Year)
{
	return IsDivisableBy4(Year) && !IsDivisableBy100(Year);
}

Build and run the tests, yes : success. All 3 tests pass.

It seems life might be great again ...

Wrong, someone just added the following test :

TEST(DivisableBy400)
{
	const bool Result = IsLeapYear(2000);
	CHECK_EQUAL(true, Result);
}

And we once again have a failing test.

Time for the next step.

LeapYear-Step6

We should add logic to deal with years that can be divided by 400, since those are leap years. We change our LeapYear.cpp into this :

#include "LeapYear.h"

namespace
{

bool IsDivisableBy400(int Year)
{
	return (Year%400) == 0;
}

bool IsDivisableBy100(int Year)
{
	return (Year%100) == 0;
}

bool IsDivisableBy4(int Year)
{
	return (Year%4) == 0;
}

}

bool IsLeapYear(int Year)
{
	const bool LeapYear = IsDivisableBy400(Year) ||
		(IsDivisableBy4(Year) && !IsDivisableBy100(Year));
	return LeapYear;
}

And once again everything works OK. And it seems all the logical rules have been implemented. This one is ready for shipping, and till the end of time we have our tests that can be run whenever we want (more on this later, we'd prefer this to be done automatically) to ensure we never break anything.

Increase the user experience

There are a few areas where we can increase the user experience. When a unit test fails the framework tell use on which line in the the code his happens. That's excellent. BUT we see this information in a console/shell windows. So we need to find that window, read the issues, remember them and then go find our test source files and navigate manually to the offending line. This works but is very cumbersome. We want this to be a no-brainer, and have these steps being carried out for us.

Well, didn't we say life is great, Code::Blocks and UnitTest++ to the rescue. The error/warning output of the framework is in the gcc format. That means Code::Blocks can parse it. One restriction Code::Blocks can parse it during the 'build process'. But currently the build process stops after the unit test executable is built, and only then we run the test executable (manually). Solution have Code::Blocks run the test executable as a post-build step. Pre-build and post-build steps are part of the build process ! Important consequence : if you want to debug something, the debugger will only kick off after Code::Blocks was able to carry out a successful build (including the pre/post builds steps). Therefor it is not wise to have the unit test executable being carried out as a post-build step of the 'Debug' target. But as a post-build step of the Release target, our goal is met.

Adjust the target settings for the 'Release' target [Build Options -> select Release target -> Pre/Post-build steps -> Post-build steps text field] and add the following $exe_output. you can tick the 'Always execute' if you want.

Now build your Release target, and look at what shows up in the 'Build Log' tab in Code::Blocks. This is my output :

-------------- Build: Release in LeapYear ---------------

[ 25.0%] g++ -Wall -fexceptions  -O2   -Wshadow -Winit-self -Wmissing-declarations -Wmissing-include-dirs -Wswitch-default -Wmain -Wextra -Wall   -I../UnitTest++/src  -c /home/lieven/Projects/UnitTestArticle/LeapYear/LeapYear.cpp -o Deliv/Release/LeapYear.o
[ 50.0%] g++ -Wall -fexceptions  -O2   -Wshadow -Winit-self -Wmissing-declarations -Wmissing-include-dirs -Wswitch-default -Wmain -Wextra -Wall   -I../UnitTest++/src  -c /home/lieven/Projects/UnitTestArticle/LeapYear/LeapYearTest.cpp -o Deliv/Release/LeapYearTest.o
[ 75.0%] g++ -Wall -fexceptions  -O2   -Wshadow -Winit-self -Wmissing-declarations -Wmissing-include-dirs -Wswitch-default -Wmain -Wextra -Wall   -I../UnitTest++/src  -c /home/lieven/Projects/UnitTestArticle/LeapYear/main.cpp -o Deliv/Release/main.o
[100.0%] g++  -o Deliv/Release/LeapYear Deliv/Release/LeapYear.o Deliv/Release/LeapYearTest.o Deliv/Release/main.o   -s  ../UnitTest++/Deliv/Release/libUnitTest++.a 
Output size is 23.28 KB
[100.0%] Running target post-build steps
Deliv/Release/LeapYear
Success: 4 tests passed.
Test time: 0.00 seconds.
Process terminated with status 0 (0 minutes, 2 seconds)
0 errors, 0 warnings
Build log saved as: 
file:///home/lieven/Projects/UnitTestArticle/LeapYear/LeapYear_build_log.html

We see that the unit test has been carried out, automatically.

Let's demonstrate that upon a failed test, Code::Blocks will jump to the offending line. Change the latest test, the one checking on the year 2000 : change 2000 to 2001. And build : Code::Blocks will jump to the offending line, and shows an entry in the "Build messages" tab (error: Failure in DivisableBy400: Expected 1 but was 0), just like for a regular compiler warning/error. In the "Build" tab, we now find something like (red colored since it is an error) :

-------------- Build: Release in LeapYear ---------------

[ 50.0%] g++ -Wall -fexceptions  -O2   -Wshadow -Winit-self -Wmissing-declarations -Wmissing-include-dirs -Wswitch-default -Wmain -Wextra -Wall   -I../UnitTest++/src  -c /home/lieven/Projects/UnitTestArticle/LeapYear/LeapYearTest.cpp -o Deliv/Release/LeapYearTest.o
[100.0%] g++  -o Deliv/Release/LeapYear Deliv/Release/LeapYear.o Deliv/Release/LeapYearTest.o Deliv/Release/main.o   -s  ../UnitTest++/Deliv/Release/libUnitTest++.a 
Output size is 23.28 KB
[100.0%] Running target post-build steps
Deliv/Release/LeapYear
/home/lieven/Projects/UnitTestArticle/LeapYear/LeapYearTest.cpp:28: error: Failure in DivisableBy400: Expected 1 but was 0
FAILURE: 1 out of 4 tests failed (1 failures).
Test time: 0.00 seconds.
Process terminated with status 1 (0 minutes, 1 seconds)
1 errors, 0 warnings
Build log saved as: 
file:///home/lieven/Projects/UnitTestArticle/LeapYear/LeapYear_build_log.html 

Voila, we have increased the user experience. Time to readjust the final test, 2001 becomes 2000 again ;-)

Further automation

You can create a script that calls Code::Blocks on the command line and passes it our LeapYear.cbp project file, and it will build both targets (Debug/Release) and run the test, since it is a post-build step for the 'Release' target. Bye bye funky makefiles, welcome Code::Blocks as your build system.

More to come

More examples will be added, showcasing 'fixtures' (setup/teardown), some more CHECK macros of UnitTest++. In case you have some tips/ideas, drop me a PM in the forum. On the planning is a full conversion of the Money example, but all with gcc and Code::Blocks instead of the crazy Microsoft IDE.