Doogle provides Nunit testing and Jenkins Continuous Integration for a client - an how-to guide

NEWS ARCHIVE

Doogle provides Nunit testing and Jenkins Continuous Integration for a client - an how-to guide (23rd October 2012)

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.

0

 

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:
image2
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:
image3
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:
 
  
 
    
<Project  DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="4.0">
  <PropertyGroup>
    <AssemblyName>XMLValidation</AssemblyName>
    <OutputPath>Bin</OutputPath>
    
  </PropertyGroup>
  <ItemGroup>
    <Compile Include="helloworld.cs"></Compile>
  </ItemGroup>
  <Target Name="Build">
    
    <MakeDir Directories="$(OutputPath)" Condition="!Exists('$(OutputPath)')" />
    <Csc References="C:Program Files (x86)NUnit 2.6.1inframework unit.framework.dll" Sources ="@(Compile)" OutputAssembly="$(OutputPath)$(AssemblyName).dll" />
  </Target>
  <Target Name="Test" DependsOnTargets="Build">
    <Exec Command="&quot;C:Program Files (x86)NUnit 2.6.1in unit-console&quot; /xml:.outputoutput.xml /nologo .inXMLValidation.dll">
    </Exec>
  </Target>
   
</Project>
    
 
 
   
 
 
    
   
   
 
 
   
   
 
   
    
For our builds to work on the build box, we installed Nunit (from http://www.nunit.org/index.php?p=download) to C:Program Files (x86)NUnit 2.6.1
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):
image4
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).
image5
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 SVN.
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.