The creators of typemock have recently published Test Lint. Test Lint is a free extension for Visual Studio 2010 which looks for common problems in your unit test code as you type.

Currently Test Lint finds a set of common problems:

• Missing asserts in your tests
• Multiple asserts / verifications on different objects in the same test
• Tests that invoke other test methods
• Logic inside unit tests (loops, Ifs Switches..)
  More rules will be added soon, and in upcoming versions, you will even be able to write your own rules based on our parsing infrastructure.

Test Lint will notify you on the spot about each possible issue with a visible queue right inside your editor, right next to the link where the issue appears.

Works with all major frameworks,  Test Lint will detect issues in tests written with:

• Microsoft Test Framework
• NUnit
• MbUnit
• XUnit.NET
• CsUnit

The hints provided by the plugin are extracted from Roy Osherove’s book the art of unit testing. Unfortunately this wonderful plugin is only available for Visual Studio 2010.

Test Driven Development (TDD) is often reduced to the three phases

1. Red – write a test
2. Green – make it run
3. Refactor – clean up code

There is nothing wrong about these three steps. But there is more involved in test-driving your development.

Where to Start?

Red-Green-Refactor tells you nothing about how to get started. The question is: which test should I write first?

When I start programming a new component or class then I first have to understand why I’m programming the new functionality. The very first step is to understand the problem and the desired behaviour (call it requirements if you want to).

Only after I understood what behaviour is expected, I’m able to think about a design that could solve the problem.

Hey but wait! Designing? I thought we were talking about TDD here?

It is true that we do not want to invest a lot of time in an up-front design. However, without a bit of initial design, the changes to get something functional are very low. The inital design consists of a very coarse decomposition of the problem in probably several building blocks (e.g. components, classes).

But keep in mind, this is only an initial design and will change. Sometimes this takes only a couple of minutes and happens inside my head – sometimes this takes several workshops with co-workers to get done.

The goal of this phase is to know where to start writing the first test.

One last thing before getting lost in Tests

Why wait, I know where to start? Let’s go coding then.

Unfortunately, most TDDers start with a randomly chosen first test. Followed by any test that comes to their minds next. This behaviour often results in sub-optimal designs, needing additional refactoring time afterwards.

A better approach is to first gather several tests for the behaviour to implement, and to put them on a TODO list. Side-note: I keep my TODO list as // TODO: in my unit test source code files.

Take a minute or two to write down all tests that come to your mind you probably will have to test to make sure the new functionality works as expected.

Which Test to Pick First/Next

Look at your TODO list and pick a test that you are confident of implementing and maximizes feedback for you.

Confidence

Only a test that can be fulfilled will take you step further. If there are too many open questions regarding a feature a test will check, wait until you have gathered more information with other tests.

Maximize Feedback

You should pick the test that provides maximal value. For example because it probably will have the biggest impact on the design. Or because it will rise your confidence in writing some other tests.

Huh oh! That was not was I expected!

If you’ve picked a test you were confident to get right and find out that there is more to it as expected then you may choose to step back. Either pick another (simpler) test or try to split the test into smaller sub-tests (if possible).

Adding Tests along the Way

Whenever I think of a new test then I add it to the TODO list. There may still be more “important” tests on the TODO list that I’ll pick before the test I just came up with. The TODO list makes sure that I won’t forget the new test.

Example – Bowling Kata

I assume you know Uncel Bob’s Bowling Kata (PPT).

Here are the tests and the ordering that I would take to solve the problem:

1. Throw one ball and get Score – tests basic interface and makes me confident to go to next test
2. Throw two balls (no spare/strike) and get Score – hey at least I can count something and I get even more confidence and knowledge about the problem domain
3. Strike – because a strike frame consists only of a single throw this has a bigger impact on design than a spare frame. I don’t want to get a solution that works perfectly for 2-ball-frames and then implement the special case of a single ball. The risk that my design has to be changed dramatically at that point is to high for me.
4. Spare – not much new in here after normal and strike frames
5. 10th frame – the 10th frame is special because it may consist of three balls. Test normal/spare/strike in 10th frame.
6. Optimal/worst game – make sure that the algorithm works in extreme cases

What is your TDD strategy? Write a comment! Thanks in advance.

Dani and me have started to keep a list of software development and presentation skills related books that we have read.

Check it out here.

Finally the latest news about Windows Phone 7 is arrived and it seems that Microsoft has ultimately learned its lessons. Windows Phone 7 has a totally news concept regarding what we are used to have with the Windows Mobile editions. But the Windows Phone 7 concept is not only new for “Microsoftish” phones it is also totally new for all smart phone operating systems on the market (including iPhone).

Windows Phone 7 incorporates content services from various sources into a unique phone concept. The core operating system automatically updates live content from these services. Third party vendors have the possibility to provide their own service content. The synchronisation of the smart phone will in Windows Phone 7 take place with the Zune Player software and not with Active Sync/Mobile Device Center.

More information and various screen shots can be found here:

http://www.microsoft.com/presspass/presskits/windowsphone/imageGallery.aspx

http://www.windowsphone7series.com/

Windows Phone 7 is definitely worth looking at!

When I talk with fellow developers new to Scrum, I often hear a fundamental misunderstanding about Sprints. These colleagues  are normally used to Waterfall or RUP methodologies. As a consequence, they think of Sprints as very short repetitions of the following phases: requirements (planning meeting), design, implementation, test (sprint review as acceptance).

And this is completely wrong!

Let me tell you why.

This misbelief has its root in a mixture of Waterfall and RUP.

In Waterfall there exist the following phases:

And in RUP there exist iterations as follows:

In Scrum however, there are neither phases following each other, nor iterations. There exists no hand-off from one phase to another (considered waste in lean software development). Everything is evolved continuously. The tester start testing on the same day the developers start coding. Of course, the requirements engineering has to be a little bit in front of the rest (otherwise, how would the team know what to build in the current Sprint). But the requirements analysis, as well as the architecture analysis, the design, the user interface usability engineering, the database schema modeller and so on are just a step in front of the rest of the team. And for sure, there is nobody limping behind.

That’s (one of ) the big difference(s) between agile and non-agile software development: continuum of work – everything is done always (sometimes a bit more, sometimes a bit less).

• Requirements are groomed throughout the project
• Architecture and Design evolve together with working code
• Testing happens from line one of code (Test Driven Development, Acceptance Test Driven Development, Test Automation, …)

Please let me know what you think…

I found a promising community on agile software development created by Kelly Waters.

If you are interested in agile development then check it out (click on banner):

Visit Agile Community

I’m heavily experimenting with git using github.com. Just in case you’ll ever receive the following error message:

failed to push some refs

Don’t panic as I did! Just need to make a pull request first because there might be changes that we need to pull in. Afterwards it is easy possible to push your changes to github.com. Have fun!

Updated: Something went wrong with the code snippets. Now it’s okay.

Today, we”l have a look at nested views in my series on agile UI development in .NET using an extended MVVM pattern (table of contents).

There are two kinds of nested views:

• contextually nested views and
• hierarchically nested views (master-detail scenarios)

ProCollEE

As always in this series, I use ProCollEE as sample application. Note that ProCollEE is currently only an architectural prototype.

The UI looks like this:

Contextually Nested Views

The first form of nesting is a view containing another view as its child:

In the above example, you can see that the main view (light green) contains the message entry view (blue) and the dashboard (gold). And the message entry view contains the channel selection view beside its own controls to enter the message to send.

ViewModel

public class MessageEntryViewModel : ViewModelBase, IMessageEntryViewModel
{
    private readonly IChannelSelectionViewModel channelSelectionViewModel;

    public MessageEntryViewModel()
    {}

    public MessageEntryViewModel(IChannelSelectionViewModel channelSelectionViewModel)
    {
        this.channelSelectionViewModel = channelSelectionViewModel;
    }

    public IEnumerable Channels
    {
        get
        {
            return this.channelSelectionViewModel.SelectedChannels;
        }
    }
}

The ViewModel takes its child ViewModel as a paramter in the constructor. The call to the selected channels is delegated to the child ViewModel.

View

public partial class MessageEntryView : IMessageEntryView
{
    // other stuff ...

    public void Initialize(IMessageEntryViewModel viewModel, IChannelSelectionView channelSelectionView)
    {
        this.DataContext = viewModel;

        this.channelSelection.Content = channelSelectionView.AsUserControl;
    }
}

<UserControl x:Class="ProCollEE.WpfClient.MessageEntry.MessageEntryView"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:local="clr-namespace:ProCollEE.WpfClient.MessageEntry">
    <UserControl.DataContext>
        <local:MessageEntryViewModel Text="Hello ProCollEE World"/>
    </UserControl.DataContext>

    <StackPanel>
        <ContentControl Name="channelSelection"></ContentControl>
         <Grid Margin="4,4,4,8">
            <Grid.ColumnDefinitions>
                <ColumnDefinition Width="*"/>
                <ColumnDefinition Width="Auto" MinWidth="47" />
            </Grid.ColumnDefinitions>
            <TextBox AutomationProperties.AutomationId="message" Text="{Binding Path=Text, UpdateSourceTrigger=PropertyChanged, Mode=TwoWay}" Margin="0.001,0,8,0" AutoWordSelection="True" TextWrapping="WrapWithOverflow" />
            <Button AutomationProperties.AutomationId="sendButton" Grid.Column="1"  HorizontalAlignment="Right" Padding="8,0,8,0" Width="Auto" Command="{Binding SendMessageCommand}" IsDefault="True">Send</Button>
        </Grid>
    </StackPanel>

</UserControl>

The view gets access to its child view by the parameter passed in the Initialize method (injected by Ninject – for those you have read the post about Ninject). The child view is set as the content of the ContentControl that is used as a placeholder.

Presenter

public class MessageEntryPresenter : IMessageEntryPresenter
{
    // ...

    private readonly IChannelSelectionPresenter channelSelectionPresenter;

    public MessageEntryPresenter(
        IMessageEntryViewModel messageEntryViewModel,
        IChannelSelectionPresenter channelSelectionPresenter)
    {
        // ...

        this.channelSelectionPresenter = channelSelectionPresenter;
    }

    public void Show()
    {
        this.channelSelectionPresenter.Show();
    }
}

The presenter gets the presenter of the child view injected and relays the Show method to it.

Hierarchically Nested Views (Master-Detail)

Above, you can see that the dashboard (green) is the master of the individual messages (red). And a message is the master of a list of channels the message was sent on (blue).

Dashboar Message ViewModel

public class DashboardMessageViewModel : ViewModelBase, IDashboardMessageViewModel
{
    private readonly ObservableCollection channels;

    public DashboardMessageViewModel()
    {
        this.channels = new ObservableCollection();
    }

    // ... other properties ...

    public ObservableCollection Channels
    {
         get { return this.channels; } }
    }

The ViewModel provides an ObservableCollection of its ViewModel children.

Dashboard View

<UserControl x:Class="ProCollEE.WpfClient.Dashboard.Dashboard"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:local="clr-namespace:ProCollEE.WpfClient.Dashboard"
    HorizontalAlignment="Stretch" VerticalAlignment="Top" AutomationProperties.AutomationId="DashboardUserControl">

    <Grid HorizontalAlignment="Stretch">

        <StackPanel HorizontalAlignment="Stretch">
            <ListView ItemsSource="{Binding Path=Messages}" VerticalContentAlignment="Top" AutomationProperties.AutomationId="DashBoardListView">
                <ListView.ItemContainerStyle>
                    <Style TargetType="ListViewItem">
                        <Setter Property="VerticalContentAlignment" Value="Top" />
                    </Style>
                </ListView.ItemContainerStyle>
                <ListView.View>
                    <GridView>
                        <GridViewColumn Header="Poster" DisplayMemberBinding="{Binding Path=Poster}" />
                        <GridViewColumn Header="Text">
                            <GridViewColumn.CellTemplate>
                                <DataTemplate>
                                    <TextBlock Text="{Binding Path=Text}" TextWrapping="WrapWithOverflow" />
                                </DataTemplate>
                            </GridViewColumn.CellTemplate>
                        </GridViewColumn>
                        <GridViewColumn Header="Time" DisplayMemberBinding="{Binding Path=SentTime}"/>
                        <GridViewColumn Header="Channels">
                            <GridViewColumn.CellTemplate>
                                <DataTemplate>
                                    <ListBox ItemsSource="{Binding Path=Channels}" BorderThickness="0" Background="Transparent">
                                        <ListBox.ItemTemplate>
                                            <DataTemplate>
                                                <Label Content="{Binding Path=ChannelName}" />
                                            </DataTemplate>
                                        </ListBox.ItemTemplate>
                                    </ListBox>
                                </DataTemplate>
                            </GridViewColumn.CellTemplate>
                        </GridViewColumn>
                    </GridView>
                </ListView.View>
            </ListView>
        </StackPanel>
    </Grid>

</UserControl>

The XAML uses the DashboardViewModel as its DataContext and can now use data binding and data templates to visualize the hierarchical data.

Conclusions

This post contains a lot of code and little comment. We have seen the differences between contextual and hierarchical nesting:

• contextual nesting: presenter-view-viewModel tripples are nested together
• hierarchical nesting: a single presneter and view use several nested viewModels

And how to achieve nesting in code.

Just a quick announcement. I wrote together with Alain Baumeler from bbv Software Services AG an article about hybrid application development targeting both .NET and .NET compact framework. The article is written in German and published in the .NET Magazin.

Here is the quick overview of the article:

Hybride Softwareentwicklung in .NET – Einführung in die Vorteile und Patterns der hybriden Softwareentwicklung für .NET Compact und .NET Framework

Mobile Geräte mit Windows Mobile sind trotz zunehmender Konkurrenz bei Businessapplikationen vielfach die erste Wahl. Dieser Artikel führt in die Thematik der hybriden Softwareentwicklung ein und zeigt deren Vorteile und etablierte Patterns anhand von Praxisbeispielen in .NET.
von Daniel Marbach und Alain Baumeler

For those who are interested in mobile application development and fluent in reading German language I really recommend our article! Buy the magazine Thanks for your support.

http://it-republik.de/dotnet/dotnet-magazin-ausgaben/Parallel-Programming-000333.html

I’m also happy about feedback. Leave comments either by email or by posting your comment on planetgeek!

We got the following geek question from Henrik:

Hi,

Thanks for sharing this preview of the MockStyle.Stub feature!
Its exactly was I was looking for when I googled this page,
so now I just can't wait for a release with this included  

I tried to find some information on futre release plans but could not find any.
Could anybody help me out? When could we3 expect a new NUnit
supporting MockStyle.Stub?

Cheers!

Henrik

The answer to this question is a bit complicated. Let me tell you why:

The current development team of NMock2 (Thomas, Peter and me) will not actively continue to develop NMock2. We’ll still provide basic support (bug fixes) but no new features. However, we have planned to make one last release (including the Stub feature) when we are sure that it works in our projects. This will be soon because we didn’t have a new defect in the last two months or so.

The reason why we have lost interest is that Moq has gained a lot of momentum and has a much broader community support. Furthermore, Moq provides some basic improvements that we cannot simply add to NMock2: besides the type safe, refactoring friendlier syntax, it allows very clean AAA (Arrange, Act, Assert) unit tests.

On the other side, there exists the NMock3 project on CodePlex that adds a type-safe syntax wrapper around NMock2. Check it out, when you already use NMock2 in your project.

So for short: the release including the Stub feature will be available soon, but it will also be the last release.

If you can’t wait until the official release then get the code from the subversion repository and start the build.release.cmd, et voila!

Happy mocking (whatever framework you use)

Urs