Doogle provides Nunit testing and Jenkins Continuous Integration for a client - an how-to guide (23rd
We configured Jenkins Continuous Integration to run on a client's build server - when accessed it looked like
the screen shot below - it is accessed via http://localhost:8080. If you don't see something like
this, you need to check that the Jenkins service is running.
The following instructions describe how we set up Jenkins and also how to use it:
First of all we needed to install Jenkins. The latest download is found here:
http://jenkins-ci.org/. Simply download the windows zip file, extract it and install with the
windows installer. It is very easy and installs out of the box.
If we explore Jenkins->Manage Jenkins->Configure System we see something like this:
Things of particular note are:
The MSBuild path and name which we will use later and also the email server and email address Jenkins
will send emails from.
For our system, we needed to make sure a couple of plugins were installed. From the
Jenkins->Manage Jenikins->Manage Plugins links, we see this screen:
We needed the Jenkins MSBuild Plugin and the Subversion Plugin.
Then we needed to configure Jenkins. In order to do this, we need an msbuild file to point
to. Jenkins will run this build file - the sorts of things the build file will do are; compile
the code and run Nunit tests.
Here is a stripped down very simple build file:
<Csc References="C:Program Files (x86)NUnit 2.6.1inframework
unit.framework.dll" Sources ="@(Compile)"
<Target Name="Test" DependsOnTargets="Build">
<Exec Command=""C:Program Files (x86)NUnit 2.6.1in
unit-console" /xml:.outputoutput.xml /nologo .inXMLValidation.dll">
The very first screen shot above shows Jenkins building 3 projects - the top 2 are failing, whereas
the 3rd one is currently passing. It is this 3rd one we will look at - it is running an Nunit
test which takes some xml files generated by the client's staff and tests that it validates against
an xsd/schema. This 3rd project (ValidateXML) is pointing to the above build file.
Jenkins runs this build file - so helloworld.cs is compiled and then the Test target is run -
the test Target runs the NUnit tests in XMLValidation.dll (which is the compiled helloworld.cs).
Jenkins is triggered to run the build file whenever someone checks in code to the client's svn
repository trunk or when someone requests a build by clicking on Build Now - which can be seen on
the below screen shot (we get to this screen shot by clicking on the ValidateXML project link):
OK, so how did we configure Jenkins to do all this for us?
Below is a screen shot of a lot of the configuration - this is found if you click on the
ValidateXML project and click on Configure (if setting up from scratch, one would click on New
Job->Build a free-style software project, name it and click OK).
From top to bottom let's go through the configuration:
The first thing of note really is the Source Code configuration. We point to the
client's SVN repository and we provide a username and password for Jenkins to check out from
Next we tell Jenkins when a build is triggered. We tell it to poll SVN every 5
minutes using the usual cron job syntax.
The Build section is where we tell Jenkins how to build our project. We tell it to
use .NET 4.0 and we give the path to the msbuild file. We also tell Jenkins to run the
Test target. The Test target we saw earlier depends on the Build target, so that will
get run first. We saw earlier how the .NET 4.0 option was configured.
Finally, we see the post build actions - here we configure Jenkins to send an email to
various recipients (here it is just me) and when to send the emails - here it is a build
failure. A failure will occur if for example the file(s) fail to compile or if there
are unit test failures.
Below is the code which is currently being compiled and the Nunit test which is being run:
As it states in the comment, if we uncomment the validateXML(invalidXml) call and check
into SVN, Jenkins will poll the SCM and a build will be triggered. It will check out
the new code and compile it and run the Tests - and now, the tests will fail. An email
will be sent to tell us of this fact. More usually, a unit test or system test would
be written in Nunit and if changes to the SUT are made and checked in, the unit test would
alert us to errors that had been made in the coding of the SUT. The ethos of CI is
that the sooner the project team is alerted to the bug which has been introduced, the
quicker and easier it will be to fix the bug, as it should be more obvious where the error
has been introduced and the code in question should be fresh in peoples' minds.