So off to trial and error I went and here is what I proposed.

Firstly, it is important to write a WCF service that can be consumed by a WCF client as well as a non-WCF client.  To this end, throwing SOAP faults should be done in a manner that both WCF clients and non-WCF clients can understand.  My first step was to make sure I had a standard WCF service with a WCF client that could understand the SOAP faults.  I created a DataContract for the SOAP fault I wanted to throw when certain conditions were met:

///<summary>
/// Thrown when no matching MPI is found.
/// </summary>
[DataContract(Namespace = WcfConfiguration.XmlNamespace)]
public class MpiNotFoundFault
{
	private string _mpi;

	///<summary>
	/// Gets or sets the MPI.
	///</summary>
	[DataMember]
	public string Mpi
	{
		get { return _mpi; }
		set { _mpi = value; }
	}
}

I  then specified my FaultContract on the service interface definition as follows:

[ServiceContract]
public interface IMyPinService 
{
	[OperationContract] 
	[FaultContract(typeof(MpiNotFoundFault), Name ="MpiNotFoundFault", Namespace = WcfConfiguration.XmlNamespace, Action = WcfConfiguration.XmlNamespace +"/MpiNotFoundFault")] 
	bool RequestPin(string mpi, DateTime dob);
}

So far, so good.  Now, let’s see how we might throw this SOAP fault in the service implementation.  For the WCF client to work, I threw the exception as follows:

public bool RequestPin(string mpi, DateTime dob) 
{
	// Code elided
	throw new FaultException<MpiNotFoundFault>(new MpiNotFoundFault() { Mpi = mpi });
}

Then, in the WCF client, all I have to do is this:

// With a WCF client, we can catch specific exceptions and get to each fault contract"s 
// contents by accessing the ex.Details propery.
catch (FaultException<MpiNotFoundFault> ex)
{
	Console.WriteLine(“MPI {0} was not found.“, ex.Detail.Mpi);
}

Yes, WCF does a lot of work for us.  However, when your client is not WCF, SOAP faults get a little bit more complicated.  Fortunately, there is a SOAP specification that can be referred to.  The SOAP 1.2 specification on soap faults is located here: http://www.w3.org/TR/soap12-part1/#soapfault.  Notice I am introducing you to SOAP 1.2, not SOAP 1.1.  Yet, in the .NET 2.0 framework, when you use wsdl.exe to create a proxy class, the SOAP 1.1 protocol is defaulted.  That’s somewhat of a problem because is SOAP 1.1, faults may only have a faultcode and a faultstring.  It wasn’t until SOAP 1.2 that hierarchical codes and subcodes were defined.  To see the difference between the two, see http://hadleynet.org/marc/whatsnew.html#S3.1.4.

Why is this important you ask?  Well, if in my ASP.NET client (that does not know anything about WCF) all I have is a SoapException, then I’d like to use the code and subcode of the faults to communicate detail about the exception (of course, my service consumer is a trusted source and will filter the information appropriately before passing it on to its users, but that’s another topic entirely).

Here is what I want to do. In my ASP.NET client, I want to check the code and subcode to understand what the nature of the problem was.  Here is what my ASP.NET catch statement looks like this:

// In WCF we can catch specific exceptions by using FaultException<T> where T is one of the fault contracts 
// included in the service operation. In contrast, ASP.NET web services only allow for catching SoapException. 
// To get to the detail, use the SOAP Fault Code and Subcode as shown below. 
catch (SoapException ex)
{
	// The SOAP fault code always contains the string ‘CredentialValidationRequestFailed’
	Debug.WriteLine(ex.Code.Name); // prints the string "CredentialValidationRequestFailed"
	// The SOAP fault subcode contains the actual soap fault name without the Fault suffix
	Debug.WriteLine(ex.SubCode.Code.Name); // prints the string "MpiNotFound"
}

By doing this, I can see that my call failed because of a CredentialValidationRequestFailed code.  This code could occur for any number of reasons.  In this example, it occurred because of an MpiNotFound subcode, but I have another 3 subcodes that could have been the cause of the fault.

So what do I need to do to achieve this? Well I need to use SOAP 1.2 for sure.  On the service side, I configure the service using an HttpBinding. By default, this binding uses SOAP 1.1. and it can’t be changed. To use SOAP 1.2 for message encoding, I create a custom binding. My configuration file now looks like this:

  <system.serviceModel>
    <bindings>
      <customBinding>
        <binding name="basicHttpSoap12Binding">
          <textMessageEncoding messageVersion="Soap12"/>
          <httpTransport/>
        </binding>
      </customBinding>
    </bindings>
    <services>
      <service name="MySoap12Service">
        <endpoint address="" binding="customBinding" bindingConfiguration="basicHttpSoap12Binding"
          bindingNamespace="MySoap12ServiceNamespace"
          contract="MySoap12Service">
        </endpoint>
      </service>
    </services>
  </system.serviceModel>

On the client side, I use wsdl.exe to generate the proxy class; instead of letting the default SOAP 1.1 protocol apply, I pass in the protocol switch to specify the SOAP 1.2 protocol should be used as follows:  wsdl.exe /protocol:SOAP12. This causes the generated proxy to specify the SOAP 1.2 protocol in its constructor:

public partial class MyService : System.Web.Services.Protocols.SoapHttpClientProtocol {
    // code elided
        
    public MyService() {
        this.SoapVersion = System.Web.Services.Protocols.SoapProtocolVersion.Soap12;
        // code elided
    }
    
    // code elided

Then, I need to throw my SOAP faults with a bit more information.  Here is the revised code snippet for throwing a SOAP fault that can now be understood by non-WCF clients:

throw new FaultException<MpiNotFoundFault>(new MpiNotFoundFault() { Mpi = mpi },
	String.Format(CultureInfo.InvariantCulture, “MPI ‘{0}’ not found.“, mpi),
	new FaultCode(“CredentialValidationRequestFailed“, new FaultCode(“MpiNotFound“, WcfConfiguration.XmlNamespace)));

That’s it.  I throw the FaultException<MpiNotFoundFault> exception, passing in a new MpiNotFoundFault object into the constructor, then I pass in the reason as the “MPI ‘xyz’ not found” string, and then I create my code and subcodes.  And voila, I have happy WCF clients and happy non-WCF clients.

On the wire, the SOAP fault looks like this:

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope">
  <s:Header />
  <s:Body>
    <s:Fault>
      <s:Code>
        <s:Value>s:CredentialValidationRequestFailed</s:Value>
        <s:Subcode>
          <s:Value xmlns:a="MyNamespace">a:MpiNotFound</s:Value>
        </s:Subcode>
      </s:Code>
      <s:Reason>
        <s:Text xml:lang="en-US">MPI '123123' not found.</s:Text>
      </s:Reason>
      <s:Detail>
        <MpiNotFoundFault xmlns="MyNamespace" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
          <Mpi>123123</Mpi>
        </MpiNotFoundFault>
      </s:Detail>
    </s:Fault>
  </s:Body>
</s:Envelope>

Table Of Contents

• What? Who? Why?
• Deciding what to test…
• …and more importantly, when to write the tests.
• Popular unit testing frameworks available to .NET
• Unit test prototype
• Writing your first unit tests

What Is Unit Testing? Who Writes The Tests? Why Do It?

The consensus is that Kent Beck introduced unit testing.  There are a number of definitions of unit testing – personally I like the definition from the book Pragmatic Unit Testing: “unit tests are performed to prove that a piece of code does what the developer thinks it should do.”  The key word is “developer.”  The developers get to write the unit test code.

This leads me to my next point.  Unit Testing isn’t a testing activity; in fact, RUP clearly identifies unit testing as belonging to the implementation discipline (see http://en.wikipedia.org/wiki/RUP).

So if this is an activity that is performed as the source code is being developed, then what are some of the benefits that developers get from writing unit tests?

• They get living documentation of how the code works.
• They get the ability to refactor code quickly and safely through automated regression tests.
• It improves the low-level design of their classes.
• It reduces risk. Writing tests helps drive the code quality up, thus reducing the number of bugs found much later in the software development lifecycle (SDLC).

In fact, unit tests are such a part of development that Michael Feathers defined legacy code as any code that does not have tests (see http://www.objectmentor.com/resources/articles/WorkingEffectivelyWithLegacyCode.pdf)

Deciding What To Test…

“What should I test?”  This is an interesting question I get often enough from developers and managers who are new to unit testing.  The question in itself is disconcerting because it reveals just how little is understood about unit testing and often stands as a euphemism for “What is the minimal amount of testing that I can get away with?”

I don’t have a real easy answer to this question.  There are no hard and fast rules that I can provide someone with.  Rather, I prefer to remind developers that the more they write unit tests, the more they improve their design abilities and the better the software they write.

Would I test a class without behaviors?  Probably not.  But what if I have an entity on which I add validation attributes (using the EntLib Validation Block or Data Annotations)?  I would definitely test the validations to ensure that the validators attached to properties are behaving as expected.

So my general rule is to write unit test that focus on behaviors and where there is value in performing this activity.

…And More Importantly, When To Write The Tests.

This is definitely the more important question.

As a developer, you get the most value from creating the unit tests when creating the code.  In fact, rarely does it make sense to go back and write unit tests after the code has been written.  Instead, you should write your tests as you write the source code.  Do I sometime s write my test before the code?  Yes – when I have a good idea what I’d like the API to look like.  Sometimes I write the test after creating the initial source code.  Most often, I find that writing source code and unit tests is a bit of the chicken and the egg problem – which one came first?

When dealing with bugs identified by testing teams or customers, you should definitely write tests before fixing the bugs.  The reason for this is twofold:

• It helps reproduce the issue
• It creates a test for a missing scenario

Popular Unit Testing Frameworks On The .NET Platform

I often get the question: “Which unit testing framework do you use?”  There are a number of frameworks specifically for .NET – most are open source and one is Microsoft’s very own.  They are all fairly similar, and I think which one you use comes down to personal preference.

The more important point is not to confuse the tests runners and the testing framework.  For example, I can run MbUnit tests (part of Gallio) from within Microsoft Visual Studio, and vice versa, I can run Microsoft unit tests from the Gallio Icarius runner.

This being said, here is a list of unit testing frameworks.  It includes, but is not limited to:

• csUnit. http://www.csunit.org/
• MbUnit (V3 is part of Gallio). http://www.gallio.org/
• Nunit. http://www.nunit.org/
• Visual Studio Unit Testing Framework (Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll).
• xUnit.net. http://xunit.codeplex.com/

Qualities of Unit Tests

In preparing this course, I researched a few sites that would help establish a guideline as to what a good unit test should look like.  I ended up settling on a set of quality attributes that unit tests should have.  These quality attributes were presented by Peli De Halleux in an advanced unit testing session in Spain (see http://channel9.msdn.com/blogs/channel9spain/microsoft-pexmoles–advanced-unit-testing-aspects-13).  Of course, my own experience also shaped this list.

Unit tests should have the following quality attributes:

• Atomic.
  • No dependencies between tests.  If test[i] must be run after test[j], you have an issue.  With some unit test frameworks (e.g. MbUnit), you can specify the order in which you want to run tests.  Still, it is something you should avoid.
  • Tests can be run in any order.
  • Tests can be run repeatedly.  I can’t tell you how many times I’ve seen tests that only work the second time and on subsequent runs.  That usually points to some initialization issues.  Fix them!
  • Tests can be run concurrently.  If you have thousands of tests and you are running a continuous integration process, this is rather important.  In general, when a test fails unless it is run on its own, there is some sort of shared state issue.  Fix it!
• Trustworthy.
  • Tests should run every time on any machine.  “It works on my machine” is a team development killer.  The tests should run on any machine.  I have seen tests where a local resource from the user’s folder is used!!!  If doing a Get Latest on the solution does not get me all required dependencies, this is not going to work.   If there is one or more failing tests at any point in time, how can the tests be trusted?  What if you make some changes to the source code and there were 50 breaking tests before you started?  You make the change, run the tests, and there are still 50 breaking changes (which tests failed?  are they still the same ones?).  The fact is, you don’t know.  But when all tests pass and you make a change that leads to one or more failing tests, you can evaluate the impact of your changes and either fix the source or fix the tests.
  • Beware “integration” tests and separate them into their own projects with the word “integration” in them.  Unit tests have to run fast – tests that have dependencies on databases or are otherwise not self-contained should be separated out.  My personal preference is to put them into their own test projects.  I expect these tests will take longer.  At the same time, I expect that unit tests will run very fast.  This is really critical for continuous integration to be efficient.
• Maintainable.
  • Test code is code also.  The same design principles we apply to source code should be applied to test code.  This is important because tests change over time to adjust for changing source code, so it is important that the tests be maintainable too.
  • Avoid repeating code.  You can use fixture setup and test setup methods to refactor otherwise repeating code.  You can also create helper classes to set up test data.
• Readable.
  • This is really important.  I should be able to open any tests and understand them.  Otherwise, it is difficult to maintain the tests.
  • There are many ways to name the test methods.  I really like the suggestion I’d heard on a Podcast and explained here: http://osherove.com/blog/2005/4/3/naming-standards-for-unit-tests.html.  It follows this pattern: <Method_Being_Tested>_<Scenario>_<Expected Behavior>.  It works pretty well for me; I encourage you to try it.

A Unit Test Prototype

I have been testing for many years, and I found a pattern repeated over and over.  I did not have a name for it, but once I started working with RhinoMocks (a mocking framework – I will introduce this in the 201 or 301 course), I learned a name that I thought described well what I’d seen in my tests and other people’s tests.

The pattern is named the Arrange-Act-Assert (AAA) pattern.

• Arrange.  Populate any objects and/or create any necessary Mocks or Stubs required by your test.
• Act. Execute the code being tested.
• Assert.  Verify that expectations were met or report failure.

Asserting is the critical step in any unit tests.  If you are not making an assertion, then you are not really unit testing.  How many assertions should there be you might ask?  Preferably one and only one.  On occasion I may have a couple of assertions is they are strongly related and it does not make sense to slit the test into two tests.  The problem with having too many assertions in a test is that when a test fails, it can be difficult to understand right away what the problem is (remember the single responsibility principle?).

Writing Your First Unit Tests

While I was teaching the class, I showed the students samples I’d put together in Visual Studio.  For the readers of this blog post, I encourage you to try the tutorials provided by the unit testing frameworks.  In particular, I find NUnit to be a good place to start because the tutorial is well written and easy to follow.  But that does not mean you can’t work through other tutorials.

Coming next, Unit Testing 201 and 301.

Until then, happy unit testing!

When asked to put a webinar together, I decided to break it down into 3 separate classes. My first one is called Unit Testing 101 and covers the fundamentals of unit testing. Though it focuses on concepts primarily, it also shows a basic unit test so as to get a flavor. I then created the second course: Unit Testing 201 – Intermediate Unit Testing. In this course, I look at techniques for handling dependencies and introduce basic concepts of test doubles and mocking frameworks. Finally, I reserved the most advanced techniques for Unit Testing 301 – Advanced Unit Testing: I cover topics on compiler techniques in Visual Studio to access members that aren’t public, how to address dependencies without necessarily resorting to using an IOC container, techniques for faking out the HttpContext, employing last-resort frameworks like Microsoft’s Moles to stub out System.DateTime for example, how to manipulate the configuration file, how to host WCF in process (I know, this is bordering on integration tests ), and a basic overview of Microsoft Pex’s framework.

Yes, it sounds like there is a lot to know to write good unit tests. In fact, just like anything else – practice makes perfect.

In my next post, I will go through the contents of Unit Testing 101.

1. Right-click on a project and select rename (or simple select a project, wait 1 second, and click it again or press F2).
2. Don’t change the name, simply select another project with your mouse.

This will cause Visual Studio to resort the projects.

I also highly recommend the PowerCommands for Visual Studio 2008 because it allows you to collapse all the projects in a solution with a single click.

Here is how you can find those pesky references in your build output directory.  From a command line in the path of your build’s binaries, type in the following command:

(FOR %i IN (*.dll) DO ILDASM /TEXT /PUBONLY /ITEM=Assembly %i | FINDSTR /L System.Windows.Forms) > Output.txt

Then, open the Output.txt and search “.assembly extern System.Windows.Forms.” This will show you which assemblies are referencing System.Windows.Forms, if any.

• Convention over configuration allows default endpoint configurations to be created by the framework.  Those default endpoints will be very helpful for simple scenarios where you want to get going quickly without the overhead of the configuration.
• Empty binding names are defaults at the top of the config hierarchy.  Nice!
• Behaviors now follow config inheritance rules, just like ASP.NET configuration.
• Config-based activation.  SVC files are no longer required and can be replaced by config entries.  This is really cool if you have a lot of SVC files to manage.  As a result, you can replace 20 SVC files for example with a single config file.

Monitoring WCF Apps.

• AppFabric is integral to monitoring.  Search for Windows AppFabric to get an overview of this new product from Microsoft.  A dashboard is integrated into the IIS 7 console.  This is really nice and makes it easier to visualize than monitoring WCF performance counters in perfmon.  This does not replace specialty tools like Avicode Intercept Studio or BMC AppSight, but is better than nothing.

Message Pump as a Service.

• RoutingService is a new feature.  You host it like any other service.  It supports RequestReply, sessionful RequestReply, One Way, sessionful , and sessionful Duplex.  You build a message filter table that get evaluated at runtime.  The RoutingService then performs the actions as specified by matching filters.
• The filter table can be replaced at runtime to respond to network changes for example.
• Using a Routing Service enables scenarios like:
• Protocol bridging. Examples: net.tcp to basic http; soap 1.1. to soap 1.2.
• Security bridging.
• Alternate endpoints.  You can use this for failover routing.   This one got applauses.  Very cool!

Discovery

• Ad-hoc discovery.  Clients can multicast probe messages to discover services on the network.  Probe match messages are sent to the client in multicast.  The scale is limited by the transport being used.
• Managed discovery.  A discovery proxy receives unicast hello messages from clients.  Probe multicast messages are intercepted by the discovery proxy.  Disco proxy sends unicast messages to the clients that send out probes, at which points those clients now switch to unicast messages to the proxy. 
• New classes to look for.  ContractDescription, DynamicEndpoint, ServiceDiscoveryBehavior, AnnouncementService, UdpAnnouncementEndpoint, FindCriteria, and EndpointDiscoveryMetadata.
• Demo.  Client was able to respond to a service being taken down and re-discover where else it could go and start using a backup service that was brought online before taking down the primary service.  This was really cool!

It seems to me that managed discovery is the better model for enterprise discovery of services.  I can see applicability of discovery in the projects I am currently working on and simply the hub-and-spoke model we are currently using.

It is interesting to me that this functionality is similar to what BizTalk can perform with some ESB toolkit.   I can’t wait to see what models are going to emerge and what role BizTalk will play in a WCF 4 environment.

The demos on this got many applauses from the audience. 

Now on to my favorite talk.  Scott Guthrie spoke and showed Silverlight 4.  I no longer have an excuse to delay getting up to speed on Silverlight.  As far as business applications are concerned, there is a concerted effort to address typical concerns of business applications in Silverlight 4.  It is now available as a beta, and was announced as planned on being released first half of 2010.  Silverlight 4, here I come!

• Scott Henselman’s session (TL49 Microsoft .NET Framework: Overview and Applications for Babies).   This session was based on a set of demos centered around the BabySmash application; it ties into the current food court offerings of the .NET framework, and also included some elements of upcoming .NET 4.0 features.  OK - so what was so likeable about Scott’s delivery?  Well, he is used to speaking to audiences; after all, he hosts the Henselminutes podcast.  The other thing I really liked: he comes from the point of view that he is a develop who knows C#, but he is not an expert on Silverlight 2, the MS surface, or WPF for that matter.  And it is with this premise that he makes a convincing point that these technologies are not that hard to pick up.  Granted, he had some “insider” help.  Still, I could not help but think that he was rather convincing and effectively acting as an evangelist.  Great demos tying in a number of technologies, from WPF to Silverlight, and yes, even the Surface with its touch capabilities.  Thanks a bunch, Scott.
• Phil Haack on the ASP.NET MVC framework, with a segment on StackOverflow.com by Jeff Atwood (PC21 ASP.NET MVC: A New Framework for Building Web Applications).  This was a real good session too.  I have to admit I had not gotten a chance to look into ASP.NET MVC much, and this session filled my knowledge gap in no time.  I came to appreciate the ASP.NET MVC framework as another food vendor in the cafeteria; yes, it does not intend to replace the web form model, it only intends on providing an alternative model.  Effectively, this is an additional tool in the toolbox.  Use the Phillips head when you need a Phillips head.
  • Here is what I liked about it:
    • The developer has to know how HTTP works.  Not a bad thing in my book.  I have seen too many developers make mistakes in web forms because of their lack of understanding of HTTP.
    • It is naturally “search engine optimized” because of its alignment on REST principles.
    • Developers have to embrace HTML and in fact have complete control over the HTML being emitted.  I think Phil Haack’s analogy about transmissions is not bad at all.  Think of web forms as an automatic transmission, and think of ASP.NET MVC as a manual transmission.  Not a bad analogy indeed.
  • Here is where I think it falls short today:
  • Lack of support for bi-directional data binding.  In my experience, developers spend too much time pushing data into the UI and coding the events for the changes made to the data by the user.  Better bi-directional data binding is needed.  So it’s not there in ASP.NET MVC, but it is there in ASP.NET 2.0 and is also there in Spring.net.  As far as I understood during the session, however, bi-directional data binding is planned in future versions of the ASP.NET MVC framework.

Well, that’s it for day 1.

Here I am at my third PDC (I attended PDC03 and PDC05), and I have to say that the mood at the keynote was the most lukewarm I have seen in the last 3 PDCs.  Perhaps it had to do with the topic: cloud computing.  Not that developers don’t care about it, but I think it tends not to be foremost in developers’ minds.  Now I think of the operations people I work with, and I think they would be impressed in the advances that are being made in manageability within the Microsoft platform.

It’s eratly in this PDC, but my take on this so far is that we are in a transition PDC.  Developers are still absorbing or getting educated on a large number of technologies like ASP.NET MVC, LINQ, Silverlight 2.0, etc… This PDC might jsut be incremental, showing a glimpse of the direction in which Microsoft is heading, with opportunities for feedback from the developer community.

The rest of this week will tell.