Unit testing with Jenkins
Continuing to setup a build for the first time with Jenkins there is, uh, another challenge. For some reason, I thought it clever to make use of MsTest. This works wonderfully on the development machine. But, of course, when it comes to the build server, you can expect all sorts of weirdness. For example, error CS0246: The type or namespace name ‘TestMethodAttribute’ could not be found…
We’re sorry, but our testing tools don’t come standard with the .NET Framework, or in any other way, except TFS and Visual Studio, unless you are willing to follow this brave soul. I share Derik Whittaker’s sentiment on the MsTest and build server issue.
This is another issue to me because MSTest is the ONLY test framework (for .Net) that I know of that does not run with a single DLL placed into the bin (or any other output directory). I just have to ask the genius’ over in Redmond what the hell were they smoking when they decided to build MSTest. It is pretty clear they had no prior knowledge of how to use the other tools such as NUnit, MBUnit or xUnit (I know, xUnit was not out yet). I know this because of all the various testing frameworks MSTest is the one that does everything different. You could argue they were on the cutting edge and were innovating, but I call BS on that.
This can be solved. So long MsTest… Hello NUnit!
Converting from MsTest to NUnit
Converting from MsTest is a simple case of find and replace of attributes. NUnit has the nifty Assert.Catch<T> which beats MbUnit, MsTest and xUnit. xUnit comes with Assert.Throws<T> but cannot assert the exception message whereas NUnit can. No more [ExpectedException] attributes.
Integrating NUnit with the build file (which is MsBuild) is pretty easy:
<Exec Command=”$(NUnitFolder)\nunit-console-x86.exe [TestAssembly] /framework=net-4.0 /xml=$(TestResultsFolder)\TestResults.xml” />
A single Exec statement and out comes an Xml file. To keep the build server clean, I decided to add all the necessary files for unit testing into source control along with the project. The bare minimum files for running NUnit from the command line comes down to the following files:
- nunit.core.dll
- nunit.core.interfaces.dll
- nunit.framework.dll
- nunit.util.dll
- nunit.console-runner.dll
- nunit-console-x86.exe
- nunit-agent-x86.exe
- nunit-agent-x86.exe.config
To make it work on .Net Framework 4.0, you have to include the /framework=net-4.0 switch on the command line.
Setting up Jenkins with NUnit
Install the NUnit plugin for Jenkins, point it to your test results file and after a build you’ll get the summarised test results. It’s a neat table with all the classes and their respective timings and so on.
Finally, I have a working build with unit testing. If only it had an installer…
Building a .NET application with Jenkins
Building a .NET project using Jenkins CI is a true breeze…
Jenkins configuration
The first thing is to install the MsBuild Jenkins plugin. After that, it is a quick pointing to the msbuild executable and we’re off to a good start…
Project configuration
Next, configure the project to use the MsBuild version we setup. Point it to your build file and we are ready to build…
The fairy tale
In theory, of course, that is how simple it should have been. At least, that’s how the fairy tale goes. Having a look at the console output and bam, back to the cruel world where I find myself with a couple of challenges:
- warning MSB3644: The reference assemblies for framework “.NETFramework,Version=v4.0″ were not found. To resolve this, install the SDK or Targeting Pack for this framework version or retarget your application to a version of the framework for which you have the SDK or Targeting Pack installed. Note that assemblies will be resolved from the Global Assembly Cache (GAC) and will be used in place of reference assemblies. Therefore your assembly may not be correctly targeted for the framework you intend.
- error MSB4019: The imported project “C:\Program Files\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets” was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
- error CS0234: The type or namespace name ‘Mvc’ does not exist in the namespace ‘System.Web’ (are you missing an assembly reference?)
The fixing
The first issue is relatively simple to fix. It requires that you download and install the small (~500MB) Windows SDK for Windows 7 and .NET Framework 4. You don’t need all of it. Only select the .NET Development components in the installation options. Install this on the server and the warnings be gone!
The second, yeah, the second issue is where the Caption Hook catches something unmentionable. To fix this; you’ll feel the hook… Two choices; either create the folders and copy the missing file from your development machine or install Visual Studio on the build server. The purist rants and raves. Go with the lesser of the two evils, create the folder structure and copy the file. That wasn’t that painful; I feel dirty.
The third issue is that ASP.NET MVC 3 is not found anywhere on the server. Easy fix, download and install ASP.NET MVC 3.
Finally, the project builds and all is well. For now.
Mocking multiple interfaces using Rhino Mocks
A while back on StackOverflow I asked a question on how to create a mock object with Rhino Mocks that implements multiple interfaces. In other words, I want to generate a mock that implements more than one interface. This baffled me for a while and I was shown the light by one of my colleagues.
A multi-mock is created like so:
var mocker = new MockRepository(); var mock = mocker.CreateMultiMock<IPrimaryInterface>(typeof(IFoo), typeof(IBar)); mock.Expect(x => x.AnswerToUniverse()).Return(42); mocker.ReplayAll();
Note the call to ReplayAll. Without this call the mock will not be setup with the intended values.
Unit test deployment issue when file is untrusted
Recently, I decided to use NHibernate in a project so that I could achieve database affinity. That provided me with another benefit and that was the ability to create a database in-memory for testing purposes. Sounded great, but while trying to run the unit tests using MsTest and SQLite, I received the following error: “Test Run deployment issue: The location of the file or directory ‘C:\projects\myproject\SQLite\sqlite3.dll’ is not trusted.“.
That problem was easily solved by simply unblocking the file. Below are the steps on how to unblock the file:
- Right-click the blocked file (sqlite3.dll), and then click Properties.
- This will open the properties dialog:
- In the General tab, click Unblock.
- Click on OK.
That’s it, the file is now trusted and the runtime should be able to load the file successfully.
XML Intellisense for NHibernate
Using NHibernate requires the writing of some tedious XML-based configuration mapping files. Remembering all the tags and attributes can sometimes be overwhelming. Thankfully the contributors decided to include intellisense hints, which are in nhibernate-configuration.xsd and nhibernate-mapping.xsd.
In order to have the hints available in Visual Studio 2008 copy the files into C:\Program Files\Microsoft Visual Studio 9.0\XML\Schemas and restart Visual Studio.
Customising Work Item Templates
Making use of either Team System Web Access or Team Explorer you might find it necessary to edit some of the work item templates. At first it might seem very confusing but is quite straight forward.
When editing work item templates there are two tools that you need to know about, witimport and witexport. They are used to import and export specific work item templates from an existing Team Foundation Server project.
First, you need to export the bug work item template by using the following command line:
witexport /f <work item templates folder>
/t <tfs server>:8080 /p <project name> /n bug
This will create a bug.xml template file in the work item templates folder specified, which could be any folder that you have access to.
The first part of the XML file defines the fields (indicated by the fields tag) that describe the bug. A workflow process (indicated by the workflow tag) is described in the middle of the file and the bottom part of the file describes the layout (indicated by the form tag) of the bug submission form.
Let’s add an environment field to the template that will indicate the environment where the bug occurred with the following values, tip, pre-stage, stage and live:
<field name="Environment" refname="TfsProject.Environment" type="String"> <required /> <helptext>Was the bug found in tip, pre-stage, stage or live?</helptext> <allowedvalues> <listitem value="Tip"/> <listitem value="Pre-stage"/> <listitem value="Stage"/> <listitem value="Live"/> </allowedvalues> <default from="value" value="Pre-Stage"/> </field>
The above piece of XML can be put anywhere after a closing field tag or the opening fields tag and must be somewhere before the workflow opening tag.
Name is obviously the name of the field that we are giving the additional piece of information. RefName is the name of this field that we are going to use to refer to when setting up the control in the layout section of the file. The presence of required tag says that a value must be specified for this field and will be validated automatically when a new bug is submitted. Next, we supply a list of values that will appear in the drop down list. Finally we provide a default value that will automatically be selected for each bug submission.
We now have to specify the new look of the form with our additional field and is done with the following XML definition:
<group>
<column PercentWidth="50">
<control Type="FieldControl" FieldName="TfsProject.Environment" Label="&Environment:" LabelPosition="Left" />
</column>
<column PercentWidth="50">
...
</column>
</group>
A group defines a collection of controls that are related. The column tag has an attribute that states the percentage space that the control should occupy. Each group should add up to to 100% but do not have to. The fieldname should be set to the field that we have just created in the fields section of the template. The label attribute is set to the label that we want to show in front of the control. In this case it is “Environment:”.
After placing the control, all that is left is to save the bug.xml file and import it back into Team Foundation Server. This is accomplished by the following command line:
witimport /f <work item templates folder>\bug.xml
/t <tfs server>:8080 /p <project name>
After a successful import the changes should be visible from both TSWA (Team System Web Access) and Team explorer, by double clicking on the Bug work item template.
Go customise those work item templates!
Essential Add-ins for Visual Studio 2008
I present to you a list of essential add-ins for Visual Studio 2008. I have found these add-ins very handy and I hope that they will help you improve your productivity as well.
- Power Commands Adds additional functionality to the IDE, which includes, collapsing the projects in a loaded solution, open command prompt where the highlighted project resides and the ability to remove and sort the using clauses.
- GhostDoc 2008 Automatically generates XML comments either by inheriting the comments from a base class or interface. It is also able to infer comments from method names and properties.
- Regionerate Lets you apply layout rules for regions and code, based on a highly customizable configuration file.
- Mvp.Xml XPathMania lets you write XPath queries against an XML document that is currently open in the Visual Studio IDE.
Note: This is by no means the ultimate list of add-ins for Visual Studio, but is merely the ones that I personally use on a day-to-day basis.
Update Code Analysis Settings on all Projects
On solutions with many projects (typically, more than 20), it is a rather tedious task to update and keep all the Static Code Analysis settings in Visual Studio the same across all projects. Recently, I found myself faced with the same problem and set out hunting once more.
This time Daniel Fisher (lennybacon) wrote a small macro that can be updated to enable or disable specific rules for Static Code Analysis. This macro is compatible with Visual Studio 2008.
I replicated the macro here for your ease:
Imports System
Imports System.Diagnostics
Imports System.Text
Imports System.Windows.Forms
Imports EnvDTE
Imports EnvDTE80
Public Module CodeAnalysis
Public Sub EnableFxCop()
Dim objProj As Object()
Dim proj As Project
For i As Integer = 1 To DTE.Solution.Projects.Count
proj = DTE.Solution.Projects.Item(i)
EnableFxCop(proj)
Next
End Sub
Private Sub EnableFxCop(ByVal project As Project)
If project.Kind = "{66A26720-8FB5-11D2-AA7E-00C04F688DDE}" Then
'Filter Project Folders
For Each subProject As ProjectItem In project.ProjectItems
EnableFxCop(subProject.SubProject)
Next
Else
project.ConfigurationManager.ActiveConfiguration.Properties.Item( _
"RunCodeAnalysis").Value = "True"
project.ConfigurationManager.ActiveConfiguration.Properties.Item( _
"CodeAnalysisRules").Value = String.Concat( _
"-Microsoft.Design#CA2210;", _
"-Microsoft.Design#CA1020;", _
"-Microsoft.Naming#CA1705;", _
"-Microsoft.Naming#CA1709")
project.Save()
End If
End Sub
End Module
Update Projects to Target .NET 3.5
Having two solutions that total 98 projects is not my kind of a joke to update manually to target .NET Framework 3.5. With my rifle in hand, I decided to hunt down a utility / macro / script that would let me do this with relative ease. Behold the grass blades opened and there it was. A macro that will update all the projects in a solution to the .NET Framework 3.5.
Scott Dorman was kind enough to spend some time to write a macro that can be found here. To install it simply copy the macro to: <UserProfile>\Documents\Visual Studio 2008\Projects\VSMacros80\MyMacros. Open the Visual Studio Macro IDE (Alt-F11) and add it as an existing item to the “MyMacros” project.
Click the play button in the Macro IDE and all your projects will be updated to target the .NET Framework 3.5.
Thank you Scott!
Disable AuthoringTests.txt
Creating a new test project in Visual Studio 2005 and 2008, Microsoft automatically generates a file in the test project called “AuthoringTests.txt”. After creating a dozen or so test projects, this file really starts getting in the way. Fortunately there is an easy way to disable Visual Studio from including this file in any new test project.
It is fairly simple. Click on Tools>Options>Test Tools>Test Project and uncheck the checkbox that reads “About Test Projects” introduction file and voila, no more AuthoringTests.txt!
Below is a screen shot of the setting:
This setting is found in the same location for Visual Studio 2005 and 2008.
leave a comment