Unittesting third-party libraries

In Uncle Bob's Clean Code, which I can dearly recommend, he's writing about unit tests and TDD. Nothing new under the sun here.
What was new for me, was the part where he points out it can be a good idea to unittest a third party library. As I'm used to only put the public methods under test and mock out third party calls the idea made me frown at first.

It’s not our job to test the third-party code, but it may be in our best interest to write tests for the third-party code we use.

Of course one shouldn't adopt everything he reads without putting some thought in it first, even coming from a renowned author such as Robert Martin.
Nonetheless there are some strong arguments in favor:

• When you have to learn a new library you have to play with it to get acquainted to it, doing this in unittests instead of production code lets you focus on the library itself.
• When upgrading the library to a new version you at least know the methods under test still behave the same way.
• You get a documentation that's always up to date with it as well.

And all this comes at the same cost you already had to pay learning the library.

Recently I had to implement a report functionality which generated a pdf. The choice was made to use the iTextSharp library so this was an ideal moment to put theory into practice.
The first problem I encountered was the assertion of my tests. How could I verify if a correct pdf was created? I needed to be able to parse a pdf file to achieve this. Looking further into the iTextSharp library I discovered it was more or less possible using the same library.
But would that make any sense? Although the assert-logic wouldn't use the same methods of the library, the question arose if it was a good idea to write tests where the assert uses the same library as the act part.

Writing following kind of tests would be quite ridiculous.

[TestFixture]
public class WhenSomeAction
{
    private int result;

    [SetUp]
    public void SetUp()
    {
        //arrange
        var sut = new SystemUnderTest();
        //act
        result = sut.SomeAction();

    }

    [Test]
    public void ShouldResultIntoSomething()
    {
        var sut = new SystemUnderTest();
        var expectedResult = sut.SomeAction();
        Assert.AreEqual(expectedResult, result);
    }
}

Given my asserts didn't use the same logic of the library I proceeded this way. In the end I wasn't going to include another pdf library just for testing purposes and definitely wasn't going to write one myself.
Finally I ended up with a couple of unittests (the pdf's that had to be created were rather simple) for creating a document, a footer, a header and a table.

I'm curious about the day we decide to upgrade the iTextSharp library. Unfortunately it's probable that I'll have to modify the assert logic of my tests once the library changes.

Silverlight datepicker in a MVVM master-detail setup

Working on my pet project where the UI is developed in Silverligth 4 I had a bit of a problem last day. The setup was simple. A master-detail where the master is a listbox and the detail a bunch of textboxes. To maintain the separation of concerns we use the MVVM pattern. Now the problem occured when adding a silverlight datepicker control to the detail control. Nothing special one would think. Here's my simplified xaml.

<Grid x:Name="LayoutRoot" Background="White">
        <StackPanel Width="300" Margin="25">
            <ListBox x:Name="theListBox" ItemsSource="{Binding Dates}" SelectedItem="{Binding SelectedDate,Mode=TwoWay}" >
                <ListBox.ItemTemplate>
                    <DataTemplate>
                        <TextBlock Text="{Binding Date}"/>
                    </DataTemplate>
                </ListBox.ItemTemplate>
            </ListBox>

            <StackPanel DataContext="{Binding SelectedDate, Mode=TwoWay}">
                <sdk:DatePicker x:Name="theDatePicker" SelectedDate="{Binding Date, Mode=TwoWay}" />                
            </StackPanel>
            
        </StackPanel>
    </Grid>

The master viewmodel contains a list of childviewmodels, called "Dates", and a selected childviewmodel, called "SelectedDate", as you may deduct from the xaml. The childviewmodel contains one property called "Date" which returns a DateTime.

To reproduce the problem, select a date in the listbox. Change the value in the datepicker by typing the new value (not with the calendar control) and now, before triggering a lostfocus event on the datepicker, select another date in the listbox. Much to my surprise I noticed it was not the listbox item first selected but the second one that was changed.

To illustrate to problem more vividly you can have a try on here

The problem seemed to be that the binding operation of the datepicker is only triggering after the selectd item of the listbox is changed when losing focus. Thus updating the newly selected item and not the previous one.

After trying a lot of possible solutions I figured, if silverlight won't do the binding update correctly I guess I had to do it myself. This implied setting the UpdateSourceTrigger from my datepicker and listbox to explicit. So I can decide myself when to trigger the binding operation. Furthermore I had to create a custom datepicker and a custom listbox so that I could attach the appropriate handlers to the events.

You can download the source here.

I find it peculiar that such a simple thing requires that much work. Or perhaps I'm missing something, no actually I hope I'm missing something. I'm calling out to anyone who has a better solution here. I've got it to work but I'm not glad with the imo hacked solution. Luckily the "dirt" stays in the codebehind of the view.

One of the strengths of Silverlight and WPF is the ease to bind your view with your viewmodel. Losing that makes it a much less attractive choice.

Listing files without server side code

Last day I had a request from a client to make a webpage for his company. No big deal, 5 or 6 static pages with a little css would do the deal. Then he asked me if it would be possible to create a side menu which contained links to files in pdf format. He also wanted to be able to manage those pdf's independently.

A whole other story for me at that point. I needed server side code to create the links to the pdf's and also a private "members" area with authentication for managing the files. Still no problem but I was wondering if I realy needed server side code.

Applying the most valuable progamming skill (KISS) I came up with a solution where I

• enabled folder browsing on a folder that contained the pdf's
• fetched the page that my webserver (IIS in my case) created when browsing to the folder with a jquery ajax call
• distilled the links to <a> tags with a href ending in ".pdf"
• parsed this into some format I liked and added them to an existing div
• created a ftp user for the client so he could manage the pdf's

Here's the javascript code

$(function(){
   $.ajax({
      url: "./newsletters/", 
      success: function(data, textStatus, jqXHR){   
         $('a[href$=".pdf"]',data).each(function(){
            $("#latestpdf").append(this);
         });        
      } 
   });
});

Anything that solves my problem in about 2 lines of code deserves a post.

Lazy loading WCF services.

Last day I had a discussion with Peter who works on an application that uses NHibernate as ORM and WCF as means of communication between client and server. The problem he was confronted with, in short, was a parent-child relation in his domain where the NHibernate mapping for the parent had a one-to-many relation to it's children but the child mapping didn't reference the parent. Now he needed to fetch all the children from a certain parent id, in a different WCF call for that matter, without first fecthing the parent. If you want the more elaborate version see here and for the solution he used see here and here.

Although he solved it quite nicely a different discussion sprouted from it. How would you develop a WCF service that returns a datacontract on which some members are lazy loaded over WCF and would you actually do this?
I remembered working on a project where they had some kind of mechanism that resembled it but the experience was rather unpleasant as they used their entities as DTO's which was ugly and caused all kinds of problems. Ah ... I think I just found the topic of my next post.

To answer the first question, how would you do it, well here's how I would do it.
The gist of it is to have your datacontract use a servicelocator or perhaps better an IoC containter to resolve the interface of the service contract that fetches the children. On the server the implementation of this interface could for example fetch the children from the database. On the client it would call the service responsable for fetching the children.

So let's have a look at the datacontract from the parent.

[DataContract]
    public class Parent
    {
        [DataMember]
         private IList<child> _children;

        public IChildServices ChildService

        {
            get { return ServiceLocator.SillyServiceLocator.GetInstance<ichildservices>(); }
        }

        [DataMember]
        public int Id { get; set; }

        [DataMember]
        public String Name { get; set; }

        public IList<child> Children
        {
            get
            {
                if (_children == null)
                {
                    _children = ChildService.GetChildren(Id);
                }
                return _children;
            }
        }
    }

Note the "Children"-getter where we check if the children still have to be loaded and if so the service locator is queried for the implementation of the IChildServices and the GetChildren method is executed on it.

The implentation of the IChildServices on the client would look as folows.

public class ChildServicesProxy : ClientBase<ichildservices>, IChildServices
    {
        public ChildServicesProxy() : base("ChildService")
        {          
        }
        
        public IList<child> GetChildren(int parentId)
        {
            return Channel.GetChildren(parentId);
        }
    }

Here we see the GetChildren method calls the GetChildren wcf call.

The IChildServices is also implemented on the server

public class ChildServices : IChildServices
    {
        #region IChildServices Members

        public IList<child> GetChildren(int parentId)
        {
//hardcoded but could fetch the children from the database
            if(parentId == 1)
            {
                return new List<child>
                       {
                           new Child
                               {
                                   Name = "Parent 1 - Child 1"
                               },
                           new Child
                               {
                                   Name = "Parent 1 - Child 2"
                               }
                       };    
            }
            if(parentId == 3)
            {
                return new List<child>
                       {
                           new Child
                               {
                                   Name = "Parent 3 - Child 1"
                               }                           
                       };
            }
            return new List<child>();
        }
        #endregion
    }

Here the actual fetching of the data happens. In this case the data is hardcoded but a call to some persistent store could be called here.

The only thing we have to do now is register the implentation of each IChildServices on to the serviceloactor of the client and the server at startup of the applications.

Perhaps more interesting, at least for me, are the pros and cons of using such an approach.
I definitely wouldn't use it by default and it should be very obvious for the consumer he's using a lazy loaded contract as it obviously does imply a major performance hit that one would not immediately link to dereferencing a property.
On the other hand if, at the client side, you map your datacontract on a client-domain I guess it makes more sense to fetch all the data you need at once before mapping it.

Anyway my conclusion is that I would only use this in very specific cases while making more than obvious that the datacontract is a lazy loaded one.

You can find a working version of it here. Please note that it has been stripped down for simplicity reasons.

What are the pros and cons according to you? Would you use this approach and if so in which cases?