csUnit 2.6 Released

csUnit 2.6 has been released and is available for download. More information is available here. The major points of interest are:

• csUnit is now based on .NET 3.5 SP 1
• Parameterized testing moved out of experimental
• Basic support for Microsoft unit testing.
• Several bug fixes.

csUnit 2.6 supports the following unit testing frameworks:

• csUnit (no surprise!)
• NUnit 2.4.7 (.NET 2.0)
• Microsoft Unit Testing (basic support)

When executing MSFT based tests no files (except the XML results file were applicable) is generated. This means improved performance in some cases and reduced disk space requirements. Please note, that csUnit does not ship with the framework assemblies for NUnit and MSFT Unit Testing. csUnit, however does not require any of those assemblies to run. So if you use only the csUnit testing framework you can safely ignore that csUnit supports other framework as well. There is increasing interest in a 64 bit version and we are looking into that option. We have also some more ideas with regards to integrating csUnit with other tools. In addition we are taking a very tough look at the usability of the tool since we feel that there are opportunities for improvement in this area as well.

"Failed to create a service in configuration file"

You may encounter this error message when you try to add a WCF base service to your web service project. The additional text of this error message is: A child element named 'service' with same key already exists at the same configuration scope. Collection elements must be unique within the same configuration scope (e.g. the same application.config file). Duplicate key value: 'FooProject.BarService'. The cause for this error message might be that you added a service to your project with the same name previously, then deleted it again. The remnants of that deleted service prevent the new service with the same name to be created. To resolve the problem do this:

1. In the web.config file locate the XML node within the node . For instance in the above example locate the node that describes the 'BarService'. Delete that node but leave in the file.
2. In the same file locate the node with an attribute 'behaviorConfiguration' and an attribute value of 'BarService'. This node also contains the endpoints for the service. Remove this node.
3. Try again, and this time it should work.

This is not a major problem but shows that a wizard for adding a service isn't necessarily coupled with an according wizard to remove the service in case you changed your mind. Removing means deleting the BarService.svc and its implementation file, e.g. BarService.svc.cs. It doesn't, however, delete the related entries from the web.config file.

Updating Silverlight User Interface From Timer

Updating a Silverlight based user interface from a timer may not work as expected. The reason is that the timer thread is different from the user interface thread. Only the user interface thread can update a Silverlight based user interface. So for instance the following code will not work in a Silverlight application:

// _statusMessage is a System.Windows.Controls.TextBlock object
// _statusMessageTime is a System.Threading.Timer object
private void DisplayStatusMessage(string message) {
  _statusMessage.Text = message;
  _statusMessageTimer = new Timer(ResetStatusMessageCallback,
                            /* params left out for brevity */);
}

private void ResetStatusMessageCallback(object stateInfo) {
  _statusMessage.Text = "";
}

When the timer fires the callback is executed on a thread different to the user interface thread. The UI will not update. In my installation the Silverlight interface would then simply disappear! To fix this you need a way to execute the actual update on the user interface thread. One way is to use the Dispatcher object (Namespace: System.Windows.Threading) of the XAML page. Then the code of the callback implementation looks as follows:

private void ResetStatusMessageCallback(object stateInfo) {
  Dispatcher.BeginInvoke(() => {
                         _statusMessage.Text = "";
                         });
}

Another solution would be to use the DispatcherTimer. I spare you the details but you can check here for an example.

ClassInitialize Method Can Be 'static'

A few days ago I wrote about adding support for MS Unit Testing to csUnit (see here). Since I am also using ReSharper it sometimes suggests declaring methods as 'static' when the code of the method doesn't access any instance variables. So just now it happened that a method marked with the 'ClassInitializeAttribute' was marked as static as well. When executing the set of tests in this class the method with the 'ClassInitializeAttribute' wasn't executed at all because apparently csUnit wasn't picking it up. So I went and checked the csUnit code and found that the equivalent FixtureSetupAttribute was found only for non-static methods as well. So at least that was consistent. Giving it a second thought I decided that it definitely makes sense to allow the FixtureSetupAttribute (and consequentially the 'ClassInitializeAttribute') to be on static methods as well. However, that isn't quite that straight forward the way the scanners in csUnit are implemented. So I'll have to do some refactoring before support for static fixture setup methods becomes available in trunk (let alone in a future release). So that would bring the list of supported MS Unit Testing attributes to the following:

• TestClassAttribute
• TestMethodAttribute
• ExpectedExceptionAttribute
• ClassInitializeAttribute

Assertions are supported anyways. The support of MS Unit Testing in csUnit is making progress.

Implicit Typing Can Make TDD Harder

Starting with C# 3.0 the language supports the concept of implicit typing at the method level using 'var'. While on one hand this new keyword has its benefits such the possibility to change return types of methods without having to change the type of all local variables that the return value is assign to, there is also a draw back of this new language feature. If you are using strict TDD, you write your tests to drive your design. That means it is not uncommon that a new method on a class doesn't exist yet, though you can write your test including assertions on the return type. Example:

public class Result {
   public long Status { get; set; }
}

public class Foo {
}

Given this starting point you may want to write the following unit test to ensure that class Foo requires a method 'Result NewMethod()':

[TestMethod]
public void TestNewMethod() {
   var foo = new Foo();
   var result = foo.NewMethod();
   Assert.AreEqual(0, result.Status);
}

As you type you will notice that when you have typed the dot after 'result' you will not be offered the member list of Result. It's not possible to implicitly type the variable 'result' since the method 'NewMethod()' doesn't exist yet. As a result writing tests in a TDD approach is slowed down when using 'var' instead of explicit types. Here is another view you may take: Writing tests for 'NewMethod()' should include all specifications, including the type of the return value. If you agree with that view you may want to avoid using 'var' in your unit tests. This certainly doesn't apply to people who create their unit tests after the method has been added to the class. I personally wouldn't call this test-first development, let alone test-driven development (or test-driven design as some people argue). Bottom line it depends on where you are coming from. 'var' might not always be the best choice even if it is a new 'cool' feature in C# 3.0.

Passing Serialized Exceptions as Service Faults

One way to pass errors from methods back to a caller is using Exceptions. Unfortunately that doesn't work with services since a caller might be anything and so you shouldn't assume that the client understands the .NET platform (and in particular WCF) as well. Therefore in a service oriented world operations return faults. When implementing a service with WCF you could use the FaultContract() on your service operation. In addition you can also use the ExceptionShielding Attribute on your service implementation. However, ExceptionShielding along with includeExceptionDetailInFaults in the service configuration covers unknown and unhandled exceptions only. Other exceptions are mapped to faults, and that's where your responsibility comes in. Whatever you return to a caller, provide as little information about what happened as possible. For instance you may log an exception to a log file on the server hosting the service and attach a case id to it. Then return that case id as part of the service fault. To get more details about a fault this case id can be used to locate the detailed information in the log file. One thing you definitely shouldn't do is passing the entire exception including call stack in a textual or serialized format to the caller. You don't want to add that additional security risk. The reason you don't want to include too much information in the fault is that an attacker might be able to use the details for future attacks. You don't want to present that information on a SilverPlatter. So for instance you could use the following class for representing faults:

using System.Runtime.Serialization;

namespace AgileTraxx.Services {
 [DataContract]
 public class ServiceResult {
    public ServiceResult(string message, long incidentId) {
       Message = message;
       IncidentId = incidentId;
    }

    [DataMember]
    public string Message { get; set; }

    [DataMember]
    public long IncidentId { get; set; }
 }
}

This class would just take the incident id plus a message. The message could contain information about how to contact support and to note down the incident id. As you can see there is a lot to consider when designing a service interface, including security related factors.

Service Reference for method returning void and out parameter

The title is quite lengthy but I couldn't find a better one. In essence I'd like to make describe a little catch you might experience when generating a service reference within Visual Studio 2008 (it might apply to other versions as well). Suppose you have a service implemented in WCF (Windows Communication Foundation). The services exposes an operation as follows: void UpdateItem(ItemData data, out ServiceFault fault); (Yes, I know that faults should be handled differently but if you want to support Silverlight there are not too many alternatives at present since we are running inside a browser. I wrote about this before so won't go into details here.) Note that the class ServiceFault is a very simple class. The details are not relevant here. The point I want to make here is this. When you create a service reference to the service that provides the above the operation Visual Studio will generate the signature in the service client as follows: public ServiceFault UpdateItem(ItemData data); You will notice that the return value has change from void to ServiceFault, and that the new operation takes only one parameter and has no out parameter. While generally it is probably a smart assumption that for a void operation the first (or only) out parameter is turned into the return value you may not want this in all cases. For some users this behavior might even be surprising. It might make sense to argue that this is a violation of the principle of least surprise. In my particular case I wanted the signature to be consistent with other signatures from other operations in the same service. So I changed the service interface to: long UpdateItem(ItemData data, out ServiceFault fault); The implementation always returns 0 as a result. And now, when I update the service reference I get the expected matching signature generated, and all signatures for the operations within my service are now consistent. On second thought, though, I might actually try a different approach. What if the return value becomes of type ServiceResult? And if I actually have to return some values these can always become an out paramter. I'll give that thought a try and keep you posted.

Domain Objects with Validation in Fluent NHibernate

Here is an issue that took me quite some time to figure out how to resolve it. I am experimenting with Fluent NHibernate. My starting point was that I wanted the code of my domain classes squeaky clean: Not a single hint that they may become persistent. Why? I wanted to have the domain free from anything that has nothing to do with the domain. At the same time I wanted the domain model to contain the validation code. Ok, I know the way I implemented validation is not necessarily in line with the usual approach in NHibernate. But let's have a look at my domain class:

   internal class WorkItem {
      public WorkItem () {
      }

      public virtual long Id {
         get {
            return _id;
         }
         set {
            _id = value;
         }
      }

      public virtual string Title {
         get {
            return _title;
         }
         set {
            _title = Validation.EnsureNonEmptyString(value, "Title");
         }
      }

      private long _id;
      private string _title = "";
   }

I left most of it out. For now let's look at just the id and the title since those two demonstrate sufficiently the issue. What you will notice is that the setter for the title contains validation code ("Validation.EnsureNonEmptyString(...)"). The problem starts when you query for one or more WorkItem's. Then NHibernate will use the property setters to initialize the instance of WorkItem. For strings the default value is null (nothing in VB.NET). With the given code, however, the validation will throw an exception since that is what it is designed to do. It doesn't care whether the setter is called by NHibernate or anything else. So next I tried to figure out what alternatives I would have for validation and I found NHibernate.Validator. Although a step in the right direction I didn't like that the client code for the domain objects would have to explicitly call the validation. Alternatively the validation would have to be invoke via the event call backs from NHibernate. In both cases the domain class would only work properly if something else would collaborate. I didn't like that concept and started to look for an alternative. And there is a quite simple solution to this: Change the configuration for NHibernate so that it doesn't use the properties to initialize the domain objects. This configuration change can be done via Fluent NHibernate as follows:

       _hibernateConfig = new Configuration();
         AutoPersistenceModel persistenceModel = 
            AutoPersistenceModel
            .MapEntitiesFromAssemblyOf()
            .Where(TypeIsIncluded)
            .ForTypesThatDeriveFrom(
               map => map
                  .DefaultAccess
                  .AsCamelCaseField(Prefix.Underscore));
         persistenceModel.Configure(_hibernateConfig);

Depending on your naming conventions you may want to use a different access strategy or a different Prefix value. In my case it was Camel Casing with an underscore as a prefix. After I finally found this solution I was able to keep the domain classes squeaky clean and at the same time stay with using the Fluent NHibernate interface and avoiding exception during the initialization of instances of domain classes. Of course I'm not sure whether this is the only and/or best option. If you have other options that are even better, please drop me a note. I'm always keen to learn more!

Executing MS Unit Tests in csUnit

I have made a little progress on the MS Unit Test support in csUnit. So far I managed to create support for:

• TestClass
• TestMethod
• ExpectedException

Admittedly, these are just the most basic ones but it is a start. Next, I'll have to do some refactoring to clean up the code. As of now, csUnit can execute tests implemented using the unit testing frameworks of either csUnit, NUnit, or MS Unit Test. (Note: This is in trunk as of now. No release is available yet.)

Another Tool for Silverlight Unit Testing

Just came across another unit testing tool for Silverlight. It's called SilverUnit. I haven't tried it out but I certainly will have a closer look. It will be interesting to see how this compares to Jeff Wilcox's approach and how it integrates with established unit testing tools. I'll keep you posted.

csUnit migrated to .NET 3.5 and VS 2008

Finally I have found some time again to do a few things on csUnit. Actually the main driver was that I tried out the unit testing features that come out of the box with Visual Studio 2008 and I found them a little bit too cumbersome for my taste. I'm sure there are scenarios, teams, and people who are looking exactly for what VS's unit testing provides, including the ability to look at old test runs. But overall it felt a little bit too heavy. One example. A test fails. The result's view lists all tests and you can click on the one that failed. But it doesn't bring you straight to the failed test. That was my expectation. Instead it brings you to a page with the result details of that test. And only there you find a link to the actual implementation of the test. Conceptually that's probably what MSFT wanted. For me it felt like being slowed down. So now I've moved csUnit to .NET 3.5 and migrated the solution and all projects within it to VS 2008. And I'm looking into making it possible for csUnit to run tests implemented using MSFT's unit testing framework. Let's see how that goes. One difficulty I already discovered: Counting assertions. I don't have a good solution for that yet but if you do, please let me know!