Teknologika

Mono is getting very mature these days. I still wouldn’t want to run a real production application on it, but it just keeps getting better and better.

I was having a quick look through the windows forms page on the mono site, and I noticed that they now support :”a driver for native Mac OS X support (no X11 required).” Wohoo. Let’s give it a whirl.

The first thing you need to do is get the latest mono binary for Mac OS X. At the time of writing this was version 1.8.1.1, which is available here.

Once mono is installed, you should be able to create a new file called HelloWorld.cs which contains the following code hello world snippet from Charles Petzold’s: Programming Microsoft Windows with c#.

using System.Windows.Forms;

class HelloWorld
{
    public static void Main()
    {
	MessageBox.Show("Hello Windows Forms on Mac os X");
    }
}

Once you have saved the file you can compile it with the following:

mcs /t:winexe /r:system.drawing.dll /r:system.windows.forms.dll HelloWorld.cs

This will produce an exe called HelloWorld.exe. Once you have the exe then you need to wrap it up so it can execute on the macintosh. To wrap the exe you neeed to use the macpac utility to turn it into a stand alone Macintosh application. To wrap the main.exe we just built you need to use the following command:

macpack -a:Main.exe -o:. -m:1 -n:Main

If all goes well you should be able to click on the new main.app that was generated and enjoy the following.

Cool.

Rob Caron has blogged about the much anticipated download of a fully installed & configured Visual Studio 2005 Team System Beta 2. The 2.8GB VPC image is now available for download from MSDN Subscriber Downloads.



I must say that I think this is definitely the preferred way to release beta software. Sure you still need to have access to the installation, but the sheer amount of time required to install beta 2 has prevented me (and many of the guys at work), from kicking the tyres in our spare time.

I regularly get asked how to approach the insertion and subsequent removal of test data when unit testing against a database. Roy Osherove has written an article for MSDN which is a must read if you have a need to test anything that writes data into a SQL Server database.

According to the SEI, “Cyclomatic complexity is the most widely used member of a class of static software metrics. Cyclomatic complexity may be considered a broad measure of soundness and confidence for a program. Introduced by Thomas McCabe in 1976, it measures the number of linearly-independent paths through a program module.”

Technically, cyclomatic complexity is calculated by the number of edges, less the number of nodes plus the number of connected components of a control flow graph of the program being measured. (Aren’t you glad you asked!)

Ok, that’s fine, but how does that relate to testing?

Interestingly, the complexity measure of a method is also the exact number of tests that is needed to achieve 100% path coverage through an application. The measure of complexity also is a great indicator of the testability, or “de-testability” of a particular method. The SEI present the following table as a basis for common complexity threshold values.

Structured basis testing is a testing approach based on cyclomatic complexity. Simplistically, to build tests based on complexity, you should start at the first line of a method, and count the straight through path as 1, that is your first test. Then, manually calculate the complexity for the method and as you go, add a corresponding test each time you add to the complexity count.

An example

In The art of software testing, Glenford Myers uses a simple self assessment test, for the reader to work out how many test cases you need for a simple program. The program in his example accepts three integers, one for each side of a triangle, and determines whether the triange is scalene, isosceles or equilateral.

string CheckTriangle (int SideA, int SideB, int SideC)

In case you were wondering, A scalene triangle is one where no two sides are equal, an equilateral triangle is one where all the sides are equal and an isosceles triangle has two equal sides.

My implementation of the CheckTriangle method, results in a simple, yet quite complex piece of code, which has a cyclomatic complexity of 12.

 1  public static string CheckTriangle (int a, int b, int c)
 2  {
 3      if (a <= 0 || b <= 0 || c <= 0)
 4      {
 5         return "Illegal Triangle";
 6      }
 7
 8      if ((a > b + c || b > a + c || c > a + b))
 9      {
10         return "Illegal Triangle";
11      }
12
13      if (a == b && b == c)
14      {
15         return "Equilateral Triangle";
16      }
17
18      if (a == b || b == c || a == c)
19      {
20         return "Isosceles Triangle";
21      }
22
23      return "Scalene Triangle";
24  }

So how did I calculate the complexity?

There are several free tools on the market for .net developers to calculate the cyclomatic complexity of a given piece of code, including Sourcemonitor, Reflector with the Codemetrics add-in developed by Jonathan De Halleux, and CodeRush with the metrics add-in.

Manually calculating the complexity, and writing tests as we go.

You can also calculate complexity manually quite easily, for example:

Ok so I know the complexity, how many tests do I need?

To achieve 100% statement coverage, we need the following test cases:

That’s where most developers would stop, highlighting again why developers should never test their own code. We need some additional cases to ensure that we cover all the conditionals, so let’s add to and the following tests.

Ok so we now have 12 tests that cover all possible paths through the application, however we do have some duplication, like test 12, and some of the descriptions are a bit messy, so let’s refactor.

We now have a set of tests that has 100% path coverage, but are we done? Well the tester in me still can think of a couple of tests to add to cover the boundary conditions on line 3.

Like most testing techniques using cyclomatic complexity is not a testing silver bullet that writes your test for you. It is however a useful technique for white box testing to guide you as to which tests need to be written for a specific function or method that has already been written. Now if only Visual Studio 2005 could programatically create these test cases for you when you generate the tests for an existing method.

Microsoft have almost finally released a version of MSF for CMMI