The arguments against multiple asserts are multiple, a main one being that if one assert fails the rest will not be executed, which means that the state of the code under unit test is really unknown. Another argument is that if you find a need for having multiple asserts, it is probably because you are testing multiple things in a single unit test method. This will break the principle of single responsibility and maintainability will suffer.

I am a great believer in having maintainable and readable unit tests and I have always tried to follow the single assert advise myself. I am also a great believer in the principle of single responsibility, although I am often forced to be pragmatic when working on legacy code. When I want to test several outcomes from a single object I can choose to implement Equals, or maybe ToString in order to do direct comparisons of whole objects. Sometimes I will try to make a utility method or class that will allow me to compare several values in a way that will fit a single assert. While some people do not like adding to the code base for unit testing purposes only, most people object to having too many utilities creeping up in the unit test projects.

Recently I had discussions on unit testing with my colleagues and the reasoning behind single asserts came up – and also some arguments against it.

Let’s have a look at one of Roy’s examples,

[TestMethod]
public void CheckVariousSumResults()
{
    Assert.AreEqual(3, this.Sum(1001, 1, 2));
    Assert.AreEqual(3, this.Sum(1, 1001, 2));
    Assert.AreEqual(3, this.Sum(1, 2, 1001));
}

The problem here is that if one assertion fails, the rest will not be run and we do not know if they would fail if run.

There are a number of solutions to this.

The first solution: Create a separate test for each assert

This is easy and it only takes a few seconds to write those unit tests,

[TestMethod]
public void Sum_1001AsFirstParam_Returns3()
{
    Assert.AreEqual(3, this.Sum(1001, 1, 2));
}
[TestMethod]
public void Sum_1001AsMiddleParam_Returns3()
{
    Assert.AreEqual(3, this.Sum(1, 1001, 2));
}
[TestMethod]
public void Sum_1001AsThirdParam_Returns3()
{
    Assert.AreEqual(3, this.Sum(1, 2, 1001));
}

What is the problem with this solution?

Well, although the example may be slightly contrived it is easy to imagine that the three cases are somewhat correlated. By putting all three asserts in a single method we have signaled that these must be considered as a whole in order to be understood, while if we create separate unit test we have lost this information. And imagine that there were more than three cases, say 42? If a fundamental bug in the Sum method creeps in so that all 42 unit tests fail, would you prefer to have 42 unit tests fail or would you prefer to have a single unit test fail?

Another problem is maintainability. It is correct that it only takes a few seconds to write these three unit tests, but someone needs to maintain them in all future and the task can become daunting due to the sheer number of unit tests.

Both problems can to a certain extend be overcome with proper naming and with true single responsibility of units under test as well as each unit test method, but that is not always the reality – especially when you try to put legacy code under unit test.

The Second Solution: Use Parameterized Tests

In many cases I would prefer to use parameterized tests. However, currently my unit testing environment is Visual Studio 2010 and it does not support such a feature!

The Third Solution: Use try-catch

Since an assertion failure means that an exception is thrown, at least in the unit test frameworks I have used so far, we can simply catch such exceptions, do some intelligent processing, and then allow the next assertion to fail or succeed. That solves our problem with having multiple asserts.

Even though Roy is my unit testing hero, I think he is a bit too hasty to simply abandon the try-catch solution with a statement like "Some people think it’s a good idea to use a try-catch block [...] I think using parameterized tests is a far better way of achieving the same thing."

A Simple Solution Using try-catch

Since I cannot write parameterized unit tests with my unit testing environment, I had to come up with an alternative solution. My solution is to introduce a new MultiAssert class which will accept delegates to multiple assert statements but only fail at most once. This new class seems to be a logical addition to the existing family of assert classes along with e.g. CollectionAssert and StringAssert.

Here is the above example in a single unit test with a single assertion,

[TestMethod]
public void CheckVariousSumResults()
{
    MultiAssert.Aggregate(
        () => Assert.AreEqual(3, this.Sum(1001, 1, 2)),
        () => Assert.AreEqual(3, this.Sum(1, 1001, 2)),
        () => Assert.AreEqual(3, this.Sum(1, 2, 1001)));
}

MultiAssert.Aggregate can even be used in situations that do not fit parameterized unit tests easily.

Here is the implementation of MultiAssert.

public static class MultiAssert
{
    public static void Aggregate(params Action[] actions)
    {
        var exceptions = new List<AssertFailedException>();

        foreach (var action in actions)
        {
            try
            {
                action();
            }
            catch (AssertFailedException ex)
            {
                exceptions.Add(ex);
            }
        }

        var assertionTexts =
            exceptions.Select(assertFailedException => assertFailedException.Message);
        if (0 != assertionTexts.Count())
        {
            throw new
                AssertFailedException(
                assertionTexts.Aggregate(
                    (aggregatedMessage, next) => aggregatedMessage + Environment.NewLine + next));
        }
    }
}

Using or Abusing Multiple Asserts

MultiAssert can be abused, it is not meant as a universal excuse for cramming a lot of assertions into any unit test method. Remember that maintainability and readability of unit tests must still be a top priority and you should only use MultiAssert when this can be achieved.

One situation in which I recommend the use of MultiAssert is when it makes sense to assert both pre- and post-conditions in a unit test method. In this context, a post-condition is simply a (single) assert that states something about the state of the world after the Act part of the unit test method. However, if you assert that something has the value 42, how do you know that this was not already true right after the Arrange part of the unit test? After all, the Assert part of your unit test must assert what was supposed to happen as a consequence of the Act part of the unit test method.

So one nice usage of MultiAssert is to assert both pre- and post-conditions in unit tests.

[TestMethod]
public void Foo()
{
    // Arrange
    var underTest = …;
    bool preCondition = underTest.TheFoo() != 42;

    // Act
    underTest.Foo();
    int actual = underTest.TheFoo();

    // Assert
    MultiAssert.Aggregate(
        () => Assert.IsTrue(preCondition),
        () => Assert.AreEqual(42, actual));
}

I am a happy user of Samsung’s hardware as well as Microsoft’s software, including the new Metro user interface, My Phone’s ability to locate my phone, the Zune software etc. And I am thrilled about the developer story – that apps can be developed using Silverlight and C# with Visual Studio and other familiar tools.

I intend to blog about developing apps as soon as I get proper hands-on experience.

One end-user problem struck me immediately when I tried to setup the phone. I use a hosted email solution which I can use to read my email through POP3/IMAP and I can send email through SMTP, all of which WP7 supports nicely.

Well, except that there seems to be no way to specify the SMTP port to be used, which is odd since it is quite common to have the default port 25 blocked?

As usual, there is a simple solution to this problem – simply specify the port after the SMTP server name. For example, if the server name is ‘myServer.com’ and the port to use is 42, specify this as ‘myServer.com:42:0’.

The Problem

The problem is simple to state. Create a combo box and bind to the SelectedIndex and ItemsSource properties and you get an out of bounds error when a value is selected.

<ComboBox SelectedIndex="{Binding Path=IndexOfCurrentValue}" ItemsSource="{Binding Values}">

One of the sources that describe the problem is http://www.lhotka.net/weblog/SilverlightComboBoxControlAndDataBinding.aspx. This post includes a work around but I wanted to find a simpler solution.

I asked the Silverlight product team and the answer was that this bug is very unfortunate, but that it may not be trivial to fix.

In my repro project, I bound SelectedIndex before binding ItemsSource, so when the binding engine sets the SelectedIndex property, items are not set yet and the value 0 is not correct.

The Solution

The workaround is simple; simply switch the order of bindings in XAML and bind ItemsSource before binding SelectedIndex.

This is a reported bug and it is still open at the time of writing this. I hope it will be fixed by Silverlight 4.

At first I did not know if it was possible at all, but I knew one thing – the differences in usage of namespaces look like something very annoying for which there must be an elegant solution.

The Problem

The first issue was with the standard controls which are in WPF 4.0 but not in Silverlight 3.0 (only in the toolkit), e.g. the Expander is declared like this in WPF,

<Expander … />

But it is declared like this in Silverlight,

… xmlns:Controls1="clr-namespace:System.Windows.Controls;assembly=System.Windows.Controls.Toolkit" …
<Controls1:Expander … />

What I really did not understand was that there is a similar problem when the standard controls which are in WPF 4.0 also are in Silverlight 3.0; for example, the HierarchicalDataTemplate is declared like this in WPF,

<HierarchicalDataTemplate … />

But it is declared like this in Silverlight,

… xmlns:Windows="clr-namespace:System.Windows;assembly=System.Windows.Controls" …
<Windows:HierarchicalDataTemplate … />

Clearly the rules for defaulting and declaring namespaces are different.

The First Solution

I searched the Internet and found a few suggestions. One suggestion is to have two sets of name space references. This works because you are allowed to use name spaces on WPF although it is not mandatory. I did not like it because it still meant maintaining different files since XAML does not allow #IFDEF-like constructs.

My colleague David Anson found a surprisingly simple solution which he describes in a blog post (see the last bullet in the notes at the end of the post). The main idea is to subclass standard controls, effectively bringing them into the same namespace across Silverlight and WPF.

It looks like magic – and ReSharper also claims that this is not valid – but it works. Well, it almost works.

The Problem with the First Solution

So far I have found one problem with the first solution – the HierarchicalDataTemplate.

If I used David’s trick,

public class HierarchicalDataTemplate : System.Windows.HierarchicalDataTemplate { }

xmlns:Std="clr-namespace:Microsoft.Dynamics.Ax.Frameworks.Controls.StandardControls"

41: <Std:HierarchicalDataTemplate x:Key="hierarchicalDataTemplate" ItemsSource="{Binding Path=Subcomponents}">
42:    <StackPanel Orientation="Horizontal">
43:        <Image Source="{Binding Path=TreeIcon}"/>
44:        <TextBlock Text="{Binding Path=Name}"/>
45:    </StackPanel>
46: </Std:HierarchicalDataTemplate>

Then it compiled in Silverlight and WPF but the StackPanel caused problems at run-time in WPF. The error was

‘StackPanel’ object cannot be added to ‘HierarchicalDataTemplate’. Object of type ‘System.Windows.Controls.StackPanel’ cannot be converted to type ‘System.Windows.FrameworkElementFactory’.  Error at object ‘System.Windows.Controls.StackPanel’ in markup file ‘Microsoft.Dynamics.Ax.Frameworks.Controls;component/singlesourcetest.xaml’ Line 42 Position 26.

It did not help to use David’s trick again and add StackPanel to the Std namespace.

This is a WPF bug. It has not been fixed in the WPF 4.0 beta I am using but I hope it will be fixed eventually in the RTM.

The Second Solution

David worked hard on this problem and got another brilliant idea; if this is a problem with WPF only then why not subclass in Silverlight only? This requires a little trick that left David "a little slimy" – see his blog post for the details – but it works. Well, it almost works.

The Problem with the Second Solution

I took the sample project from the blog post for a spin and found that it would not work if I added x:Name="myTreeview" to the TreeView in XAML. This is the error I got,

The type ‘System.Windows.Controls.TreeView’ exists in both ‘c:\Program Files\Microsoft SDKs\Silverlight\v3.0\Libraries\Client\System.Windows.Controls.dll’ and ‘e: \SharingXamlSilverlightWpf\PresentationFramework\Bin\Debug\PresentationFramework.dll’                e:\enlistments\axmain6\source\frameworks\controls\sharingxamlsilverlightwpf\sharingxamlsilverlightwpf-sl\obj\debug\mainpage.g.cs      38           42           SharingXamlSilverlightWpf-SL

Clearly there is a problem with disambiguating identical names across assemblies.

I needed to reference the name of the tree from a details view so I could not use the second solution for at least the controls that I needed to name.

But since the second solution seemed to only be needed for HierarchicalDataTemplate anyway, I am now using the first solution for everything but the HierarchicalDataTemplate.

And this works. Well, it almost works. But the remaining problems seem to be unrelated to this single-sourcing approach so I will defer blogging about it till later.

The visual clue I had in mind was a red squiggly line, similar to the way MS Word underlines my typos.

Why this particular visual clue? Because this is how it is done in MS Dynamics AX,

This left me with two tasks,

1. How to trigger the actual validation.

2. How to change the default WPF visual clue (a red border around the control) to the desired red squiggly line.

How to trigger validation

I thought about using validation rules similar to what Nigel Spencer blogged about. But validation is only triggered when the binding value has changed, while I wanted the visual clue to work even at start-up.

I was not alone with this problem. Willem Meints blogged about this as well as about several other validation problems. He actually wrote a complete validation framework that I found would be too much of a good thing for me. He also wrote that he did not use IDataErrorInfo as it does not provide enough flexibility.

I like to keep things simple, so I opted to use IDataErrorInfo.

Basically, I let the business object I bind to report an error if it is not happy about what the user typed so far. It can be augmented by validation rules, e.g. a user defined NumberRangeValue.

For the simple case, meaning the check for mandatory fields having a value, I use code similar to the following,

public string this[string columnName]
{
    get
    {
        if (string.IsNullOrEmpty(columnName))
        {
            return string.Empty;
        }

        if (<this is a mandatory field and has no value>)
        {
            // This is never shown in the UI and does not
            // have to be localized; but if we ever choose
            // to show this text it must be localized!
            return "This field is mandatory.";
        }

        return string.Empty;
    }
}

Now I need to figure out how to trick the visual of controls to show a squiggly red line instead of the default red border.

How to get the red squiggly line

The TextBlock control can actually do the trick with the red squiggly line with its built-in spell checker. Alas, there is no API to trigger this at will.

Instead I found that the following XAML placed in a Resources section would do the trick,

<DrawingBrush x:Key="squiggleBrush" TileMode="Tile"
        Viewbox="0,0,4,4" ViewboxUnits="Absolute"
        Viewport="0,0,4,4" ViewportUnits="Absolute">
    <DrawingBrush.Drawing>
        <GeometryDrawing Geometry="M 0,2 L 1,1 3,3 4,2">
            <GeometryDrawing.Pen>
                <Pen Brush="Red" Thickness="1"
                StartLineCap="Square" EndLineCap="Square"/>
            </GeometryDrawing.Pen>
        </GeometryDrawing>
    </DrawingBrush.Drawing>
</DrawingBrush>
<ControlTemplate x:Key="SquiggleError">
<StackPanel HorizontalAlignment="Center" VerticalAlignment=
        "Center">
        <AdornedElementPlaceholder/>
        <Rectangle Height="4" Fill=
            "{StaticResource squiggleBrush}"/>
    </StackPanel>
</ControlTemplate>

The problem

I tried various ways to make my data bound combo box items disabled. I found that binding the ComboboxItem.IsEnabled to a property that indicates whether the item should be enabled did the trick.

But this did not work when I selected items using the keyboard. I also tried to make these not focusable but with the same result.

What worked: Click the combo down with the mouse and see that items that must be disabled can in fact not be selected.

What not worked: Use tab and arrow down to select items. They are not disabled and I can select them just fine with keyboard keys. Funny enough, if I click the combo down with the mouse, then the items are in fact disabled and cannot be selected with the keyboard keys.

Here is the XAML (I set up the data, meaning the properties FieldDomainValues, IsSelectable and ValueAsString, in constructers in code-behind):

<ComboBox x:Name="cmbx_test" ItemsSource="{Binding Path=FieldDomainValues}">
    <ComboBox.ItemContainerStyle>
        <Style>
            <Style.Triggers>
                <DataTrigger Binding ="{Binding IsSelectable}" Value="False">
                    <Setter Property="ComboBoxItem.Focusable" Value="False"/>
                    <Setter Property="ComboBoxItem.IsEnabled" Value="False"/>
                </DataTrigger>
            </Style.Triggers>
        </Style>
    </ComboBox.ItemContainerStyle>
    <ComboBox.ItemTemplate>
        <DataTemplate>
            <StackPanel Orientation="Horizontal">
                <TextBlock Text="{Binding Path=ValueAsString }"></TextBlock>
            </StackPanel>
        </DataTemplate>
    </ComboBox.ItemTemplate>
</ComboBox>

What did I do wrong here?

The workaround

Before we dig into the core reason for this problem, let’s have a look at a simple work-around that Parag Bhand suggested,

We also faced similar issues while dealing with binding in combobox. Once we open the dropdown every thing works fine (even from keyboard) then onwards. I guess it has something to do with ItemsContainerGenerator because item containers are not generated until dropdown is opened at least once.

In fact if we open the drop down and close it again programmatically in window’s loaded event handler then also it works fine.

cmbx_test.IsDropDownOpen = true;
cmbx_test.IsDropDownOpen = false;

This is what I do now and it works.

The explanation

Dwayne Need, found the explanation,

ComboBox.SelectItemHelper has logic to determine if the item and its corresponding container allow selection. When there is no container, this logic always returns True. The containers (ComboBoxItems) aren’t created until the dropdown box is measured, which doesn’t happen until the user causes the dropdown to appear, typically by clicking on its down-arrow button.

If you followed that, it’ll be clear why the workaround works. It causes a measure on the dropdown, which generates the containers. After that, SelectItemHelper’s logic picks up the state the app has declared for the containers. It should also be clear why we don’t do that for you automatically – the workaround creates UI that is never displayed.

This looks like a scenario bug to me. While the technical details make sense, the end-to-end scenario is broken.

Please file a bug.

This has now been filed as a bug (750993: Unable to disable combo-box items when selected with the keyboard).

Unfortunately the fix for this bug will not make it into .NET 4.0 so we must try and get around with the workaround for now.

Why? I did it for two reasons.

Firstly, because I am a passionate software developer so I will mainly write about code; but I also have a life; and I tend to have opinions on my own so I refuse to restrict myself too narrowly, hence everything.

Secondly, because I found that Life, universe and software development with focus on simplicity, quality and maintainability was a bit too long, although it is more to the point of what I intend to write about.

Thirdly, because it is a reference to certain literature that has left a lasting impression on me.

That was three reasons, not two? Well, how can a trilogy consist of more than three books?