This week was short work-wise, and went by quickly. Last week was hectic and long. Me and my colleague Truls gave a seminar on NHibernate, a little ActiveRecord and some of the new MS OR stuff. Then I spent three days with another consulting company, showing them the ins and outs of NHibernate and sprinkling just a little WCF on the last day. In so doing, I caught myself serving out some code that I have used. Normally, I don't dish out any code here, but this might be useful to some:

It's a small WCF test helper that I have used to do explorative testing of WCF and even more so for integrative smoke tests of WCF services.

There is a zip attached that contains one vs.net 2005 project with a WCF hello world and one nunit test that runs that service. That test is an integration test, it cranks up the whole WCF machinery. Most of my WCF integration tests (all, in fact) do not test any concurrency issues. They are more simple smoke tests that everything seems to work as expected. What I usually want is to test the machinery but have one instance invoked, so that I can execute some assertions on the results using that instance afterwards.

Usually, you will not implement your WCF service as a singleton (although it is one of the instancing modes), for one of several reasons - scalability for example. Using the other instancing modes means that you (by default) do not control construction of your the instance that gets to serve the requests, and thus in a test situation, we do not have a reference to the instance used by WCF. One way around this is to create a custom instance provider. The instance provider in WCF (class implementing IInstanceProvider, the default being a private class in InstanceBehavior, reflect it) is responsible for supplying new service instances. I won't talk about it here, suffice it to say that my SingletonInstanceProvider simply returns one (settable) instance each time, thus making the service a singleton. It is a service behavior that we add to the servicehost description.

Why do this? Simply so that I can implement my service using an instancing mode that I want, but still run simple smoke tests on it. It is one solution, there are doubtless many others, if you have a better one, please give me a shout.

So, the testhelper or testharness that is enclosed actually does a couple of things. I won't talk about them in detail, this is roughly it:

• Provide a simple way to create and start a service host and get a client to run tests against it.
• Provide a way for tests to share services, so that the WCF machinery does not need to be restarted.
• Get the services set up using the SingletonInstanceProvider easily
• Allow test to access host before it is started to modify/further configure
  ( this is why you see castle in there, the client (a dynamic proxy wrapper) is actually a proxy that opens the service late/JIT )

You use it like so:

IMessageOfTheDay client1 = GetClient

   .For<IMessageOfTheDay>()

   .Using(new NetTcpBinding())

   .Running(serviceInstance);

This sets up a service host for the IMessageOfTheDay service contract, using the netTcpBinding (optional, default is named pipes since it is the fastest) and running the instance supplied. See the demotest.

Comments welcome. Btw, this uses my singleton implementation, I'll make a note of that tomorrow, but it's simple.

Questions: Has anyone seen another wcf test harness like this? I usually do all my network integration testing using some thread harness with synchronization between, and did my WCF testing in a similar (not the same) way. This harness simplified things quite a bit.

BTW: Most of the code is in one file; TestHelper.cs. It's a bit unwieldly, sorry, but easier to copy - you still need the singleton.cs though. I may update later if I get time.

Again, the download is here.

Øredev 2006 is over, and it was pretty great - despite several last minute  (quite literally last day) cancellations from some high profile speakers. I talked to alot of people and many agree with me that the social atmosphere was very good. The panel on the last day rounded off the whole event nicely. In the picture you see Martin Fowler, Erik Doernenburg and James Coplien.

My presentation went pretty well, it seems alot of people enjoyed it. Here is the slidedeck for it.

I forgot a couple of things: First, I forgot to announce the next SNUG meeting, which is December 6th in Malmö - sorry chris. I also forgot to underline the steps after vou've got the code you're interested in under test. I managed to cover alot, but there are so many important ideas that I did not have time to cover.

The last thing I missed was the resources slide, you will find it in the download. I have also put out an older version of this talk in an older blog entry, look for it. As you probably noticed, the sessions where recorded, and I hear that there are plans to make them available to all attendees. Time will tell.

• "Continuous integration", good article by Martin Fowler.
  There is actually a new and an old version.
  
• "The agile difference for SCM" Very nice agile overview with SCM focus by Appleton et al.
  
• From some XP summaries by Don Wells (this one has some links to interesting discussions on c2 wiki) and Ron Jeffries
• "Continuous Integration – just another buzzword?", nice overview by Appleton et al
• "Codeline Merging and Locking: Continuous Updates and Two-Phased Commits" , good info on 2-p commit pattern (Brad Appleton, Steve Konieczka, Steve Berczuk, same gang as above)
• "Agile SCM - Build Management for an agile team"

If you are migrating to VS.NET 2005 and converting projects, the VS.NET conversion wizard will do that for you. Then you can use MSBee to compile into both 1.1 and 2.0 assemblies.

However, if you are migrating the build process perhaps before all projects in your organization have migrated, people will still be developing in VS.NET 2003 for some time, yet you want to have a standardized build process, around MSBuild.

This little MSBuild task will convert a VS.NET 2003 project on the fly so that you can use MSBuild to compile it.

Pretty niche scenario, yet since I found myself there, others probably will too.

It is easy to use, you just slap a Using element and then use the task, giving it the projects name. Thats it. Installation is xcopy. The readme gives step-by-step instructions. Happy building!