Interestingly, he says that one’s identity is not defined by craft but by the guiding principle that you uphold. He uses Larry Tesler as an example whose guiding principle is “No person should be trapped in a mode” and Richard Stallman whose guiding principle is “Software must be free”, among others. I urge you to take the time, watch this video and find your guiding principle.

Bret Victor – Inventing on Principle from CUSEC on Vimeo.

Theory X and Theory Y

Donald McGregor identified two attitudes known as Theory X and Theory Y. In short, Theory X is someone that has an innate dislike of work and tends to avoid responsibility. They need coercion, direction and control. Theory Y, on the other hand, is someone that experience work as natural as rest or play and their commitment is typically in relation to the rewards associated with their achievements.

Each theory has a corresponding managerial approach. Theory X managers are autocratic and demand total control, managing through fear and punishment. Theory Y managers set the goal and let the person or team get on with it.  With that being said, McGregor found that staff behaviour and motivation is influenced by expectations set by the manager, i.e., if the manager assumes that you are going to produce work of excellence, you are likely to try and meet it.

Models of motivation

Taylorist model

Frederick Taylor believed that people are only motivated by money. This is not always the case, even in situations where the output can be directly related to reward. Output is often constrained through norms accepted by a work group. It’s typically unspoken rules which determine the quantity of output to produce. In a software development environment it is difficult to determine and quantify the amount of work completed by an individual – it’s a team effort. Setting an excessive financial reward between employees must be considered very carefully as it can break down morale and productivity. Bonuses are usually awarded at the end of project as a work-around to this problem.

Maslow’s hierarchy of needs

Motivation is a little more complicated than Frederick Taylor puts forward. Maslow suggests that as one motivator is satisfied, another will emerge. If you are broke, money is a fairly good motivator. When the financial need is satisfied, a higher level need will emerge. The needs hierarchy starts from the basic need of food, shelter and personal safety, to the highest level which is the feeling of fulfilling your potential or self-actualization. At different stages of life people are motivated by different things. For example, an older employee consider the quality of the job more important than a younger employee.  The younger employee considers a raise in pay more important than quality of job.

Herzberg’s two factor theory

Herzberg found that there are two factors in a job that will affect your satisfaction. The first is hygiene or maintenance factors. If working conditions are not right, it will definitely affect your level of satisfaction with the job. The other is motivators. These are typically a sense of achievement, or that the job is worthwhile.

Expectancy theory of motivation

Victor Vroom created the expectancy theory, which identifies three influences on motivation. They are expectancy, which is the belief that the harder you work the higher your performance will be; instrumentality, which is the belief that better performance will be rewarded, and finally the perceived value of that reward. If all three motivating factors are high, then motivation will be high. A zero score for any one of the three can remove motivation.

Oldham-Hackman job characteristic model

According the Oldham-Hackman model, there are five factors that influence job satisfaction. The first is the number of skills that can be exercised while doing the job; second is task identity, which refers to the degree to which your work identifies you as the author  and lastly, the degree of influence that your work has on other people i.e., the significance of your task. These three factors determines how meaningful your job is to you.  The other factors include the amount of say in the way you do your job and the feedback you receive about the work you’ve done.

There are a few simple things one can do to improve motivation, viz.,

• Set specific goals;
• Feedback on work completed;
• Tailoring tasks;
• Increase the task scope;
• Increase responsibility.

Stress

With deadlines, objectives and obstacles, life is pretty stressful as a programmer. On the other hand, some pressure is good as boredom is soul-destroying. That being said, too much pressure affects not only work quality but health too. Some major factors that cause stress is not knowing what is expected from you and what you’re responsible for. Also, being torn between responsibilities such as attending an important meeting or looking after a sick child. Research shows that productivity and quality  suffers when more than 40-hours per week is exceeded. One of the axioms of extreme programming is to work no more than 40-hours per week. In a US study it was shown that people under 45 years of age who work more than 48-hours per week had double the risk of death from coronary heart disease.

To prevent overtime, project managers can be more realistic about the effort and time needed to complete a task or project. Exercising good planning and control will help to reduce unexpected obstacles. Some managers use bullying tactics and claim to be successful at pushing projects through. They typically need to create crisis to be able to justify such tactics. On the other hand, you find professional project managers that use rational, orderly and careful methods to deliver successful projects.

References

1. Hughes, B. & Cotterell, M. 2009. Software Project Management, 5e. Berkshire: McGraw-Hill Education.

Quality in software systems

Businesses are relying more and more on software for running critical business operations. Naturally, every business owner wants his software stable and reliable. Consider other critical systems such as aircraft control systems. I’m pretty sure that you’d want a quality flight control system on board your next flight. Would you board the aircraft if your software was running on the aeroplane?

Another reason we want to ensure quality from an early stage is that bugs and defects accumulate over time. If we fail to correct quality issues from the beginning of the project, there is simply no easy way that we are going to make up for it in the end. Quality must be considered right from the start.

What is software quality?

The quality of a system is partly determined by the user-experience of a system. If it’s user-friendly, stable and reliable it’s quality is perceived as high. If it fails often and produce incorrect information then the system will be perceived as of poor quality. This is known as external quality.

As important as external quality is, internal quality is just as important. Internal quality is about the maintainability and extensibility of the source code. A system that is very difficult to extend and maintain will not be perceived as high quality.

Measuring software quality is tricky and there are two ways in which it is measured, viz.,

• Direct where the quality is measured directly or observed directly;
• Indirect where the quality is measured by some indicator of the underlying quality.

Quality factors

Before writing a software system it is necessary to decide on some quality factors. It is the only way to know if we succeeded in delivering a system that is of a specified and agreed quality. We specify the quality factors in terms of the following:

• Definition of the quality characteristic;
• Scale of units in which the quality is measured;
• Test that will be conducted to measure the quality;
• Minimum acceptable which is the absolute minimum for this quality characteristic to pass;
• Target range which is the quality number we expect to reach;
• Now which is the current quality number.

For example, reliability can be made up the following quality factors, viz., availability, mean time between failures, failure on demand and support activity. Related to this is maintainability of which “changeability” and “analysability” are key components.

ISO 9126

According to this standard there are three parties who are interested in the quality of the software, viz.,

• Acquirers who are the people obtaining the software;
• Developers who are the people making the software;
• Independent evaluators who assess the quality of the software.

ISO 9126 defines six external software quality measures, viz.,

• Functionality is the functions that the software need to offer to satisfy user needs;
• Reliability is the ability of the software to keep up its level of performance;
• Usability is the effort needed to use the software;
• Efficiency is the physical resources used when executing the software;
• Maintainability is the effort required to make changes to the software;
• Portability is the ability to transfer the software between environments.

In order to measure the quality between different software systems we have to judge the importance of each quality measure for the application in question. We then select the external quality measures that are relevant to the selected quality measures and create a mapping for the measurements indicating the quality rating, such as:

After that we identify the relevant internal measurements and the intermediate products in which they appear. In other words, the source code must be evaluated and rated according to the set out quality measurements. To derive the final quality number for the systems, we combine the ratings for each system and compare them.

References

1. Hughes, B. & Cotterell, M. 2009. Software Project Management, 5e. Berkshire: McGraw-Hill Education.

To create a project schedule, we have to model the project’s activities and their dependencies. Or, if you prefer, their relationships. A project schedule is typically drawn as a graph — arrows joining circles. The fancy way saying this is, edges for the arrows (a.k.a links) and vertices for the circles (a.k.a nodes). This type of graph is typically drawn from left to right, with the project’s starting date on the left.

So, what do the circles and arrows mean? Well, it depends.

Activity-on-node

This is a simple graph where the circles represent the activities and the arrows the dependencies. It is also known as a precedence network. We call it a precedence network because a node, or activity, cannot be executed until all of its preceding activities executed.

To draw an activity-on-node graph, we have to follow some rules:

• only one starting node;
• only one ending node;
• each activity has a duration;
• links have no durations;
• time moves from left to right;
• the graph may not contain any loops;
• the graph may not contain any dangles – a node that just stops in the middle of nowhere.

By the way, this activity label is based on British Standard BS 4335.

Critical Path applied to Activity-on-node

A critical path is the order in which we should execute activities, so that we can get the project done as fast as possible. Not only that, it also shows us which activities will cause us to miss the end date, if they are delayed. How do we determine the critical path?

Well, for each activity we need to have some idea of, how long it will take to do, what is the earliest we can start and complete the activity as well as the latest we can start and complete it. That is the Duration, Early Start, Early Finish, Late Start and Late Finish parts of the activity label.

To calculate the earliest dates, we need to do something called a forward pass. That is, we look at every activity and calculate its early start and early finish dates. The first activity’s early start values always starts at zero.

In the network graph above, we see that Task A and Task C can start immediately. However, Task B must wait until Task A and Task C completes (it’s predecessors). Since Task C has the longest duration (10 days) between Task A and Task C, Task B can only start in 10 days and will complete on day 13. The earliest that Task D can start is in 2 days time, after Task A completed. With this in mind, the earliest that the project can complete is in 13 days time.

Next, we need to do a backward pass on the same network to calculate the Late Start and Late Finish values. This gives us the latest date at which an activity must start and complete without delaying the end date of the project. The late finish date for the project is the same as the early finish date.

In this example, we see that the project will complete in 13 days. So, we work from the end date backwards. Starting at 13 days, we can see that Task B will take 3 days to complete and so the latest start date is 10 days (13-3). Task D also needs to finish on day 13.  This task takes 4 days to complete and so the latest date to start this task is in 9 days time (13-4). Task C on the other hand must finish within 10 days and has to start immediately (10-10). Since Task A will take 2 days to complete and we know that the latest finish date is only in 9 days time, we only have to start this task on day 7 (9-2).

To find the critical path in the graph, we find the sequence of tasks that will move the end date, if there is a delay in any of its activities.

If there is a delay in Task C so that it only completes on day 11, it will delay Task B and ultimately the end date. We have to pay special attention to the critical path throughout the project so that we can handle any delays as soon as possible. The critical path sets the activity span. That is, the shortest time in which we can complete the project. If we want to shorten the time of the project, we have to cut the time of the activities in the critical path.

Activity-on-arrow

In activity-on-arrow networks, the arrows, or links, represent the activities. The nodes represent events of activities starting or finishing. Just like the activity-on-node graph, so too activity-on-arrow graphs have rules when it comes to drawing the network graph. They are:

• only one starting node;
• only one ending node;
• duration is on the link;
• nodes have no duration;
• time moves from left to right;
• nodes are numbered sequentially;
• graph may not contain any loops;
• graph may not contain any dangles.

Critical Path applied to Activity-on-arrow

Before we can find the critical path in an Activity-on-arrow graph, we need to do a forward pass. It follows the same principles as activity-on-node. The only exception is that in activity-on-arrow we use the events and not the activity start and end dates.

Let’s look at an example (Hughes and Cotterell, 2009):

The earliest date when an event can start is the date when all the events that it depends on is complete. In the example above, activities A, B and F can start immediately. So, the earliest date for event 1 is zero. Since activity A takes 6 weeks to complete, we can only start activity 2 in 6 weeks time at the earliest. Activity B takes 4 weeks to complete and so event 3 can only be achieved in week 4. Activity F is dependent on the ending date of activity E and so we only know that activity F will complete in 10 weeks. Activity E can start in 4 weeks time and will take 3 weeks to complete. From that we know that activity E will only end in 7 weeks time. We then take the longer of the two ending dates (between E and F) and find that event 5 will only be achieved in 10 weeks time. Event 4 can only start in week 9 (6 + 3) > (4 + 4).  We now see that the project will only finish at the end of week 13, at the earliest.

Next, we do a backward pass on the same graph to calculate the latest date at which each event should be achieved. It follows the same principles as the backward pass for activity-on-node.

To find the critical path, we make use of slack. Slack is the difference between the earliest date and latest date. It tells us how late an event can be without affecting the end date of the project. The critical path is that path with all the nodes having a zero slack.

References

1. Hughes, B. & Cotterell, M. 2009. Software Project Management, 5e. Berkshire: McGraw-Hill Education.

How then do you estimate the effort of a project with such uncertainties?

At the start of the project we should be able to get some idea of what the end-product will look like. From that, we can start estimating how long the bits and pieces will take to develop. Now that seems easy, but estimating how long the bits and pieces will take is not as simple as it seems.

Over- and under-estimating effort

Let’s look at Parkinson’s Law. It says that “Work expands so as to fill the time available for its completion.” If the task ends up being easy, then we will waste time and work less hard.

On the other hand, under-estimating effort will result in an unreliable and poor quality system. This is a manifestation of Weinberg’s Zeroth Law of Unreliability which says that “If a system doesn’t have to be reliable, it can meet any other objective.” Many people will make this sacrifice simply to complete the product before the deadline.

When a project starts falling behind, project managers will typically add more people to the project. Brook’s Law explains that “Putting more people on a late job makes it later.” Why is that?

Let’s look at an example. In a team of three members we have 3 “communication channels”. Add two more people and we have a team of five. This means that we now have 10 “communication channels” between people. We calculate it using [n * (n - 1)] / 2 where n is the number of people. Frederick P. Brooks covers this in his book The Mythical Man-Month.

Estimation techniques

In his book Software Engineering Economics by Barry Boehm he suggests a few ways in which effort estimates can be derived.

Bottom-up breaks the project into it’s components and those components into it’s components and so on. Take each of the components and estimate the lines of code and multiply this with some factor that adds fat for complexity. Based on that number, calculate the number of days it will take using a ratio between lines of code and effort. [It is called bottom-up because the effort accumulates upward.]

Top-down is based on two parameters, size and productivity. Effort is then calculated as effort = size * productivity. Where size is an estimate of the number of lines of code and productivity is the time spent by the developer doing the work. The productivity parameter is scaled according the developers experience. There is a more advanced calculation. It uses the least squares regression model which is calculated as effort = constant1 + (size * constant2).

Expert judgement relies on the knowledge and experience of someone who is already involved in the project. This estimation doesn’t only rely on the person but also takes into account similar projects and supplemented by the bottom-up approach.

Case-based reasoning finds the differences and similarities between completed projects, or source cases, with the new project, the target case. Take the similarities and differences and adjust the source cases so that you get an estimate for the target case. There’s a fancy way of doing this by using the Euclidean distance between the cases. This technique is also called estimation by analogy.

Function point analysis assigns a complexity value to each instance for each of the following components, which is then summed to get the function point processing size:

• External input types – inputs that change the internal data;
• External output types – outputs from the system, such as reports;
• External inquiry types – inputs that point the system to information without modifying it;
• Logical internal file types – the information system’s data store;
• External interface file types – input and output exchanged by the information system.

Function points MarkII is an improvement on the original Allan Albrecht function point analysis technique. Create three weightings, one for input (Wi=0.58), one for entity types (We=1.66) and one for output (Wo=0.26). Then, multiply the weightings with the number of elements corresponding to each of the weightings and calculate the proportions of effort. [The values for the variables Wi, We and Wo have been set based on industry averages.]

COSMIC full function points is used for sizing real-time and embedded systems. Typically, these systems are made up of component layers which may communicate with each other. Assign a value to each data group and sum the counts to calculate the functional size units.

There are four data groups which are the  inputs and outputs of these components:

• Entries – moves the data group into the component;
• Exits – moved the data group from the component;
• Reads – moves data from storage into the component;
• Writes – moves data to storage from the component.

COCOMO II is a constructive cost model where effort is calculated as person-months based on 152 hours and it’s size is measured in lines of code. Effort is calculated using the formula effort = c(size) ^ k where the constants c and k are dependent on the nature of the product and the development environment:

• Organic mode (small system developed in-house) [c=2.4, k=1 .05];
• Embedded mode (tight constraints, expensive to change) [c=3.0, k=1.12];
• Semi-detached mode (hybrid of organic and embedded) [c=3.6, k=1.20].

The way in which we calculate the effort is dependent on where we are in the development process. During application composition (user interface design) we use the number of physical features of the product such as screens, reports and so on. This is known as object points.

At the early design stage (architecture) we use function points to estimate the size of the system. There is a neat little trick here to convert the function points to the equivalent number of lines of code. To do that, we multiply the function points by a factor for the programming language used.

After we have gathered all the data we can now calculate the effort in person-months using the formula pm = 2.94(size) ^ (sf) * (e1) *…* (en)† where size is the number of lines of code in thousands (kdsi) and sf is the scale factor which is calculated by sf = 0.91 + 0.01 * Σ(exponent driver ratings)†. Exponent driver ratings are there so that we can compensate for the loss of productivity on large projects.

Determine the scale factor (sf) by assigning points from the table below to each of the following exponent drivers:

• Precedentedness - how novel is the system? The more novel, the more uncertainty, the higher the exponent;
• Development flexibility – how easy is it to meet the requirements? If it’s tough assign a higher exponent value;
• Architecture/risk resolution – how likely are the requirements to change? Very likely, up the exponent;
• Team cohesion – are your team members friends? If not, up the exponent;
• Process maturity – do you know what you are doing? If you do, go low on the exponent.

Here’s a table to help you out on the exponent driver values:

†Pssst… I changed the formula’s a little. There are variables which have been set for many years and so the formulas should really be pm = A(size) ^ (sf) * (e1)*…*(en) and sf = B + 0.01 * Σ(exponent driver ratings).
References

1. Hughes, B. & Cotterell, M. 2009. Software Project Management, 5e. Berkshire: McGraw-Hill Education.

It is a very simple script that:

1. Formats each flash drive to FAT32;
2. Copies the contents of the specified directory recursively onto the flash drive;
3. Dismounts the volume.

The script finds all removable drives between 1gb and 64gb in size. We don’t want to slip up here, now do we?

At the top of the script, a default directory is specified from where all files will be copied if an alternative directory was not specified on the command line.

Write-Host "MassFlash - Version 1.0"
Write-Host "Author: SS du Plooy"
Write-Host "-----------------------"

If($args.Length -eq 0)
{
    $DirectoryToCopy = "c:\DefaultFromCopyLocation"
}
Else
{
    $DirectoryToCopy = $args[0]
}

Write-Host "Preparing flash disks with files from" $DirectoryToCopy
$drives = Get-WmiObject Win32_LogicalDisk -filter "DriveType=2"

Foreach($drive in $drives)
{
    [int] $driveSize = $drive.Size/1073741824 #convert to gigabytes

    If($driveSize -ge 1 -and $driveSize -le 64)
    {
        $driveLetter = $drive.DeviceID
        $volume = Get-WmiObject -Class Win32_Volume -Filter "DriveLetter = '$driveLetter'"
        $label = "TKP"+$(get-date -f ssfff)

        Write-Host Formatting drive $driveLetter [$label] [$driveSize GB]
        $volume.Format("FAT32", $true, 4096, $label, $false)
        Write-Host "Copying $DirectoryToCopy to $driveLetter"
        Copy-Item $DirectoryToCopy $driveLetter -recurse
        Write-Host Dismounting drive $driveLetter
        $volume.Dismount($true, $false)
    }
}
Write-Host "Done."

Now you can put your time and mind to better use instead of preparing flash drives all day long.

Note: The script must be run with Administrator privileges.

So, I knocked up a little Powershell script that can be scheduled to email a disk space report everyday. Currently the script is written to send a report on a single drive only. There are many other variations of this type of script that reports on all the drives on a server.

$disk = Get-WmiObject -ComputerName $env:COMPUTERNAME Win32_LogicalDisk | Where-Object {$_.DriveType -eq 3} | Where-Object {$_.DeviceID -eq ":"}

[float]$totalSize = [Math]::Round($disk.Size / 1073740824, 2)
[float]$freeSpace = [Math]::Round($disk.FreeSpace / 1073740824, 2)
$deviceID = $disk.DeviceID
$percentFree = [Math]::Round(($freeSpace / $totalSize) * 100, 2);

$smtpServer = ""
$smtp = New-Object Net.Mail.SmtpClient($smtpServer)
$emailFrom = "$env:COMPUTERNAME"
$emailTo = ""
$subject = "$env:COMPUTERNAME - Disk space report"
$body = "$deviceID | Total: $totalSize GB | Available: $freeSpace GB | $percentFree % disk space available"
$smtp.Send($EmailFrom,$emailTo,$subject,$body)

When it comes to management, you might just as well only print the precentage of free disk space and perhaps add that to the subject of the email. That will give all the relevant information in one look. The script can be extended to report on multiple servers and multiple drives.

Have fun!

Fit: Framework for Integrated Test

Great software requires collaboration and communication. Fit is a tool for enhancing collaboration in software development. It’s an invaluable way to collaborate on complicated problems–and get them right– early in development.

Fit allows customers, testers, and programmers to learn what their software should do and what it does do. It automatically compares customers’ expectations to actual results. [Cunn 07]

Read an introduction to FitNesse.

Installing FitNesse

To start using FitNesse with .net, you’ll need to download FitNesse and fitSharp. Once downloaded, place the fitnesse.jar file in a directory, for example c:\FitNesse. Extract the files from the fitSharp archive into a subdirectory in the same folder as fitnesse.jar called fitSharp.

Start FitNesse using java -jar fitnesse.jar -p 8080 where -p is the port number. FitNesse installs in a directory called FitNesseRoot. Browse to http://localhost:8080 and you should see the FitNesse front-end.

Creating a test fixture

To use FitNesse you’ll need to give a test fixture that FitNesse can execute. A test fixture is derived from one of the classes provided by the Fit framework. For this example, derive a test fixture from ColumnFixture. This will allow us to run the test case using a decision table with input and output values. Add a reference to both fit.dll and fitSharp.dll in your project.

namespace Humanresources.Domain
{
  public class EmployeeTests : fit.ColumnFixture
  {
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public string FullName { get { return string.Concat(FirstName, " ", LastName); }
  }
}

Setting up the test case

To setup the test case, you will need to create a wiki-page. On the front page of FitNesse, click on Edit and enter a wiki-word with the name of the test case. A wiki-word is a word written in Pascal-case surrounded by square brackets, i.e. [EmployeeTests]. Click Save and then click on the question mark to go to the page and click on Edit.

To setup the test, you ‘ll need to define a couple of variables, they are

1. location of the assembly under test;
2. how to invoke the test runner;
3. location of the test runner.

!path C:\Projects\Experiments\HumanResources\HumanResources.Domain\bin\Debug\HumanResources.Domain.dll
!define COMMAND_PATTERN {%m -r fitnesse.fitserver.FitServer,c:\FitNesse\FitSharp\fit.dll %p}
!define TEST_RUNNER {c:\FitNesse\FitSharp\Runner.exe}

|humanresources.domain.employeetests|
|firstname|lastname|fullname?  |
|John     |Lidin   |John Lidin |
|Joshua   |Cohen   |J Cohen    |
|Allan    |Butler  |A Butler   |

The tests can also be executed from the command line, are you thinking what I’m thinking?

Troubleshooting

• Fit.dll file load exception

System.IO.FileLoadException: Could not load file or assembly 'file:///c:\FitNesse\FitSharp\fit.dll'
or one of its dependencies. Operation is not supported. (Exception from HRESULT: 0x80131515)
File name: 'file:///c:\FitNesse\FitSharp\fit.dll' ---> System.NotSupportedException: An attempt was
made to load an assembly from a network location which would have caused the assembly to be sandboxed
in previous versions of the .NET Framework. This release of the .NET Framework does not enable CAS policy
by default, so this load may be dangerous. If this load is not intended to sandbox the assembly, please
enable the loadFromRemoteSources switch. See http://go.microsoft.com/fwlink/?LinkId=155569 for more information.

To solve this issue, simply add a configuration file to the runner that you’re using. If you are using runner.exe then create a file called runner.exe.config and add the following text into runner.exe.config:

<configuration>
   <runtime>
      <loadFromRemoteSources enabled="true"/>
   </runtime>
</configuration>

• If you encounter any other issues you can do the test run using a debugger.

References

[Cunn 07] Cunningham, Ward. Making Fixtures. Framework for Integrated Test. October 12, 2007. http://fit.c2.com/search.cgi?search=WelcomeVisitors

When buying programming books, there are a few considerations. Do you need them at work and home? What about when you are travelling? They tend to get heavy. For this reason, I decided to buy a Kindle. Well, that was a nice idea. It is comfortable and has the same weight no matter how many books you load on it. Great for travelling. Well, that only lasted for a short while until I had to read source code which is justified by the Kindle. It’s just ugly. Diagrams are not great and tend to be small and not very readable.  I decided that I will only buy them in paper form. Some publishers will let you have the e-book for free when you purchase the paper version.

Most of these books are applicable to object-oriented programming, while others are simply timeless practices that are bound to stick for a long time. This is not a definitive list but merely what influenced my thoughts, concepts and styles.

• Patterns of Enterprise Application Architecture
  
• Design Patterns: Elements of Reusable Object-Oriented Software

• Domain-Driven Design: Tackling Complexity in the Heart of Software
• Code Complete: A Practical Handbook of Software Construction
• The Design of Everyday Things

• Data Structures Using C++

• Expert .NET 2.0 IL Assembler

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…