The long way round…

One of the early things on a project to get sorted is who is going to be performing acceptance tests and how are they going to be written and executed? Just so we’re clear, acceptance tests are what the customer executes to verify what you (the team) have delivered is what they (the customer) asked for? If not, its back to the old drawing board.

FIT is a Framework for Integrated Tests that was created by Ward Cunningham and is gaining popularity. FIT simply consumes test tables, where a test table is a bunch of acceptance tests with input values and expected results. The trick is to provide test tables in tools that customers use as part of the every day life, and what is more everyday than Word and/or the Web.

Focusing on the Web side of things, FitNesse is a software testing tool that front ends FIT with a wiki. In Fitnesse the customer can write acceptance tests as simple tables that can be executed. These executable test tables call the software that you wish to be accepted by the customer.

Installing Fitnesse

Hmmm. This wasn’t so hard, simply do the following:

• Download the latest zip and unpack into a directory of your choice.

At the time of writing, the latest zip was fitnesse20060719.zip. Note that FitNesse is a wiki implemented in java. However, it does support the running of acceptance tests for .NET. Now once unpacked, step into the root directory and issue the following:

• run -p 8888

This will display a little text to say all is well. Now traverse to the FitNesse wiki at:

• http://localhost:8888/

Here are a couple of quick links you should try:

• http://localhost:8888/FitNesse [ lists all pages within the wiki ]
• http://localhost:8888/FitNesse.DotNet [ the .NET page ]
• http://localhost:8888/FitNesse.DotNet.SuiteAcceptanceTests

The last one is very interesting because in the left hand menu, you’ll see the top menu item is Suite. Click this to run all the .NET acceptance tests. Note, that you need .NET installed on your Windows machine.

I’m tired. Tomorrow I’ll step through the problems I had trying to get my own acceptance tests running against inside Fitnesse.

One of the best ways to learn a new language for me is to write a load of tests that demonstrate how particular parts of the lanugage and/or platform work. For VisualStudio 2005, I wanted to do this without paying for the priviledge, so this ruled out:

1. TestDriven.NET that is suppose to provide good test integration with VS.NET.
2. Visual Studio Team Suite (VSTS) built in test framework. See what Charlie Poole, a member of NUnit team has to say about this.

So I installed NUnit and took the following steps within VisualStudio:

1. Created a new VS Solution with a C# Library project called basics.
2. Right clicked on the basics project and set the startup external program to be NUNIT_HOME/bin/nunit-gui.exe

Once done, everytime I run in debug it fires up the nunit gui and I can select my test and run it. I am now in a position to test and debug anything within the .NET platform that I can condense down into a simple test. Nice!

Again, that wasn’t so bad…

Learning the Microsoft Platform for me is like French.  You learnt it badly when you were young, stumbled by with it year in and year out, always promising yourself that one day you’ll do it properly!  For me, that day has come!

So I dusted off my First Edition of Eric Gunnerson’s (c) 2000 A Programmer’s Introduction to C# that was lying around on my bookshelf.  It’s not a great book, but a start.  4 hours later, armed with the syntactic basics of the C# language, I fire up my newly installed Visual Studio Professional.  I’m mildly excited.

The first thing I do in any new IDE is go to their equivalent of Tools | Options and step the enormous amount of configuration options, just see what’s there.  Here’s what I found interesting:

• Environment | Help | Online - Over a slow connection, go standalone.
• I tend to separate application from data on my desktop machines, so for me:
• Change the default location for my Import and Exporting Settings
• Change the default location for my vstudio projects and templates
• Configuring the help system, msdn, C# formatting options and debugging.

Okay, I’m ready go.

I performed a full install of Visual Studio 2005 and MSDN today.  It took under an hour on my Windows XP laptop without a single reboot.  This is a marked improvement over the VS 2003 install.  So for 5Gb of HDD space what did I get?

• .NET Framework 2.0
• .NET Compact Framework 
• SQL Server Mobile and Express Editions
• Visual Studio for C#, VB, J# and C++
• MSDN Full Install
• MSXML 6.0
• MSBuild
• And stuff I simply don’t want to know about…

This is not really a bad trade.  Looking at some of the new directories on my machine, I think its time to delve a little deeper into MSBuild and Microsoft.NET.

What a can of worms!

In Java this is what you tend to do:

• Get yourself an J2EE application server to host your business objects.
• Implement your business objects with Spring (or EJB 3.0 and above).
• Persist your objects with Hibernate (or suitable ORM technology or JBDC)
• Job done!

On the Microsoft Platform, the story is a lot fuzzier. Basically, the proposed solution is not here yet. People are waiting for, (well keeping an eye on), Windows Communication Foundation (WCF) that will replace all the legacy (can you believe that) distributed applicaton environments that are used today, namely, COM+, DCOM, .NET Remoting (boy this has only just come out) and MSMQ. The problem is, WCF is Beta and so hard for a client to swallow and have faith in today.  But you can see what is waiting for you in the future…

…but…

…working in the here and now, what are the recommendations for delivering distributed applications on the Microsoft Platform. Well at my previous placement, we found that you have to pretty much roll your own framework to make up for glaring errors and/or omissions in the Microsoft Platform. Simple things like service discovery for .NET Remoting endpoints. Not there. So if your system requires its backend services to seamlessly failover/failback on behalf of its clients, you need to write this yourself. This takes time. Furthermore, .NET Remoting is not the quickest, where the most common recommendation is for the HTTP channel and BinaryFormatters for encoding the payload. Of course, you can distribute your services using Web Services, but speed is a concern here.

I hear you say Enterprise Services and ServicedComponents over DCOM. Yep, that is a possibility, but if your services are behind a firewall, problems! Remember CORBA. Now I’m not complaining here, but more trying to get a clear story on common architectural patterns for distributed applications on the Microsoft Platform. So I take my hat of to Rockford Lhokta and his write up on Middle Tier Hosting. Then sprinkle in some .NET Remoting Use Cases and Best Practices from ThinkTecture and I’m starting to see the light. Unfortunately, it ain’t pretty.

Basically, it boils down to what Rockford explains as layers and tiers. Layers being the logical application groupings (presentation, business and data ) and tiers being the phyiscal. The rules are thus:

• layers cannot span tiers.
• mulitple tiers leads to tears.
• a host provides an environment for tier(s).
• your choice of host (Enterprise Services, IIS or Custom) depends upon the protocols you plan to use.
• The available protocols are DCOM, Web Services and Remoting.

So let’s just whittle down the possibilities here. For the most general cases in application development for customers that I’ve built systems for, the following holds:

1. I need my clients to access business services through a firewall and I don’t want every client machine to have to register our server COM components on their local boxes. Rollout nightmare. Yuk. Yuk. Yuk. DCOM is out.
2. I have no time to invest in writing a Custom environment to host my application services. This is costly and you have only yourself really to sort out the problems.

These two simple requirements have made me realise the following:

1. It rules out Enterprise Services and Custom as possible hosts.
2. Why the majority of .NET server applications involve IIS - there is simple no other alternative that I can think of. Please if someone has one, I would love to hear from you.
3. The importance of standing firm and implementing clear layers of responsibility, given that the recommendation is really to stick to a single tier unless to want to take on the complexity of multi-tier application development. It’s possible, but its just damned hard.

Back to the story. So with IIS as the host environment and Web Services and/or Remoting as the protocol, we can implement our business services using .NET assemblies, ServicedComponents, SWC (Services Without Components), and take advantages of some of the neat .NET 2.0 Enterprise Service APIs, namely distributed application transactions (you need SQL 2005 in place for this).

Okay, I’m happier knowing this. But will also keep my eye on WCF and the migration path it proposes for code that I’m about to write that is already deemed legacy…