Brian Button - One Agile Coder

Test Driving a WPF App – Part 3: Switching to new window

Brian Button — Mon, 24 Aug 2009 06:15:00 GMT

This is the third part in what I hope to be a four-part series about creating a WPF application using TDD to drive the functionality and MVVM to keep everything testable as we go. The idea is to use view models to split away functionality from the view and have it available for testing while not losing any capabilities along the way. If you haven’t read the first two parts, you may want to do that.

In this part, we’ll see what it takes to have a user gesture, in our case, either a double-click on a row in our ListView or clicking a button, take us to a different page in our application.We’ll write the code to get you to the other window in this post and leave the corresponding code to get back for readers as an exercise, should they want to confirm they understand how this all works. So, here we go.

The end result

At the conclusion of this process, we’re going to be able to start from the opening page, showing players and their numbers:

and navigate to this second page:

About this time, I’m feeling pretty good about my screen design abilities as well, as these pages are beautiful! (One thing I’ve learned about myself over the years is that I have very little taste when it comes to designing UIs :))

Step 1 – Writing the command logic to command the pages to switch

As before, when we’re adding new behavior based on a user gesture, we start by writing the ICommand class. We do this because it fleshes out both the details of that class, but also because it drives us down the road of creating the interface that the command class is going to use. This interface is going to be eventually implemented by the view model class, the TeamStatControlViewModel in our case. We don’t “officially” know that at this point, though, so we work through this interface, which represents one of the growing number of roles our view model fulfills. Fo more information on this style of development, read this paper by Steve Freeman.

Let’s begin by writing our first test for the command class. This is the test that invokes the behavior that the role we’re collaborating with makes available to us. In keeping with my experiment of creating lots of little fixtures, each of which represents a complete, but individual, behavior of my system, I’ve created a fixture called InterPageNavigationFixtures. My idea is that this fixture will hold all tests that document how navigating between pages works. Our first test:

   1: [Fact]

   2: public void SwitchToPlayerViewStartedWhenViewPlayerCommandExecutes()

   3: {

   4:     var viewPlayerSwitcher = new Mock<IViewPlayerModeSwitcher>();

   5:     ViewPlayerModeSwitchCommand cmd = new ViewPlayerModeSwitchCommand(viewPlayerSwitcher.Object);

6:

   7:     cmd.Execute(null);

8:

   9:     viewPlayerSwitcher.Verify(s => s.SwitchToPlayerViewMode());

  10: }

Like the other test we created for a command, we define the interface that represents the role we’re going to use, IViewPlayerModeSwitcher, and then our command class. The rest of the test ensures that the correct behavior happens when we invoke the command’s Execute method.

To make this test compile, we have to create some things, including the interface, the command, and some very minimal method signatures in both.

In the ViewModels project, we add the interface:

   1: namespace ViewModels

   2: {

   3:     public interface IViewPlayerModeSwitcher

   4:     {

   5:         void SwitchToPlayerViewMode();

   6:     }

   7: }

as well as the skeleton of the command:

   1: namespace ViewModels

   2: {

   3:     public class ViewPlayerModeSwitchCommand

   4:     {

   5:         public ViewPlayerModeSwitchCommand(IViewPlayerModeSwitcher modeSwitcher)

   6:         {

   7:         }

8:

   9:         public void Execute(object parameter)

  10:         {

  11:         }

  12:     }

  13: }

Run test, test fails, implement minimal behavior to make test pass:

   1: public class ViewPlayerModeSwitchCommand

   2: {

   3:     private readonly IViewPlayerModeSwitcher modeSwitcher;

4:

   5:     public ViewPlayerModeSwitchCommand(IViewPlayerModeSwitcher modeSwitcher)

   6:     {

   7:         this.modeSwitcher = modeSwitcher;

   8:     }

9:

  10:     public void Execute(object parameter)

  11:     {

  12:         modeSwitcher.SwitchToPlayerViewMode();

  13:     }

  14: }

At this point, the test passes, and we can invoke the switching behavior that will be implemented in our view model shortly.

The last thing I was to do here before moving on is to expose the command through the view model so the view can bind to it. A simple test, much like others we’ve seen before:

   1: [Fact]

   2: public void ViewModelExposesSwitchToPlayerViewModeCommandAsICommand()

   3: {

   4:     TeamStatControlViewModel viewModel = new TeamStatControlViewModel(null, null, null);

5:

   6:     Assert.IsAssignableFrom<ViewPlayerModeSwitchCommand>(viewModel.PlayerViewMode);

   7: }

8:

and we implement this by simply adding an auto-property to our view model called PlayerViewMode.

Part 2 – Making the view model change application modes

In this next, the view model will begin to switch modes in the application between the Player Summary mode and View Player mode. I’m intentionally calling these modes here because I don’t want the view model to know about windows and views and other UI-ish specifics. As far as it is concerned, the application has two modes in which it can work, and someone else is going to be able to translate from the information about modes and transitions to swapping out views and controls. This is purely an example of separating concerns, where the view model only cares about the modes of the application and another class, more than likely in the same assembly as the view logic, will know how to act upon modes switching.

Starting down this road, we’ll write a test that drives out the interface for how we’ll tell something outside of the view model that a mode is changing. We’ll be talking to a role I chose to call the ModeController, commanding it through its PlayerViewMode. Here is the test:

   1: [Fact]

   2: public void ModeControllerCommandedToSwitchToPlayerViewByViewModel()

   3: {

   4:     var modeController = new Mock<IModeController>();

   5:     TeamStatControlViewModel viewModel = new TeamStatControlViewModel(null, modeController.Object, null);

6:

   7:     viewModel.SwitchToPlayerViewMode();

8:

   9:     modeController.Verify(nc => nc.PlayerViewMode(It.IsAny<Player>()));

  10: }

Since the TeamStatControlViewModel needs access to the mode controller, we had to modify its constructor to take an argument of that type. We call the method we’re trying to drive through the tests, SwitchToPlayerViewMode, and then comes our assertion. Our assertion is a bit interesting here – maybe I’m thinking too far ahead, but I’m considering how the view that is going to eventually be rendered is going to work. Its going to need to know about the player that was selected, so it can show it. In fact, that player is probably going to become its DataContext. To give the new view, which will be rendered by someone else at some other time, access to the player, I’m passing it along here. I’m not writing the code that will actually cause it to be passed yet, as you can see by the It.IsAny<Player> argument in the Verify statement, but I’m declaring that an object of that type is going to be passed to it when the system runs for real. Let’s implement this small step:

First, the IModeController, which sits in the ViewModel sassembly:

   1: namespace ViewModels

   2: {

   3:     public interface IModeController

   4:     {

   5:         void PlayerViewMode(Player player);

   6:     }

   7: }

and then the minimal code in the view model:

   1: public class TeamStatControlViewModel: IApplicationExitAdapter, IViewPlayerModeSwitcher

   2: {

   3:     private readonly IApplicationController applicationController;

   4:     private readonly IModeController modeController;

   5:     private readonly IPlayerRepository playerRepository;

6:

   7:     public TeamStatControlViewModel(

   8:         IApplicationController applicationController,

   9:         IModeController modeController,

  10:         IPlayerRepository playerRepository)

  11:     {

  12:         this.applicationController = applicationController;

  13:         this.modeController = modeController;

  14:         this.playerRepository = playerRepository;

  15:         ApplicationExit = new ApplicationExitCommand(this);

  16:         PlayerViewMode = new ViewPlayerModeSwitchCommand(this);

  17:     }

18:

  19:     public void SwitchToPlayerViewMode()

  20:     {

  21:         modeController.PlayerViewMode(new Player());

  22:     }

  23: }

Please not that I’m only showing the interesting bits here, and removing code that didn’t change from the last time we looked at this class. The bits that did change are an additional parameter to the constructor of this class and the addition of the SwitchToPlayerMode method. Since that method came from the IViewPlayerModeSwitcher, I also went ahead and implemented the interface here. (Note – Since this isn’t a lesson in TDD, I skipped the step of how I used the AddMethodParameter refactoring to slowly add the new constructor and move away from the old one. I didn’t do this in one big step, I did it in small steps, using the tests to guide me to what to change next.)

The next step is to get the player that is selected in the ListView and pass that along in the call, instead of passing an empty player. Here is the test used to drive that:

   1: [Fact]

   2: public void SamePlayerPassedToModeControllerAsSetInViewModel()

   3: {

   4:     var modeController = new Mock<IModeController>();

   5:     TeamStatControlViewModel viewModel = new TeamStatControlViewModel(null, modeController.Object, null);

   6:     Player player = new Player();

   7:     viewModel.SelectedPlayer = player;

8:

   9:     viewModel.SwitchToPlayerViewMode();

10:

  11:     modeController.Verify(nc => nc.PlayerViewMode(player));

  12: }

There are only small differences between this test and the one before it. The main one is that I’m defining a new property on the view model, SelectedPlayer. A ListView sets this property every time the selected item changes in its view, and this property will allow our view model to be informed about which player is selected at any time. Now we can pass along that player in the PlayerViewMode call, and all is well. Here are the minor changes in TeamStatControlViewModel:

   1: public Player SelectedPlayer { get; set; }

2:

   3: public void SwitchToPlayerViewMode()

   4: {

   5:     modeController.PlayerViewMode(SelectedPlayer);

   6: }

Part 3 – Hooking up what we have

Despite the fact that I write a lot of tests for my code, I still like to see it work every now and then! This would be one of those times. We’re at the point now where we should be able to wire up everything we have and get to the point where the mode controller would be able to swap out controls, were we to have implemented that last piece of functionality. Let’s hook up what we got and see what works.

Let’s start by making a couple of quick changes in the XAML. We’ll add a SelectedItem attribute and binding in the ListView and we’ll hook up the ViewPlayer button to the command:

   1: <ListView IsSynchronizedWithCurrentItem="True" Grid.Row="1" VerticalAlignment="Stretch"

   2:     SelectedItem="{Binding SelectedPlayer}" ItemsSource="{Binding Players}">

   1: <Button Command="{Binding PlayerViewMode}" Grid.Column="0" Content="View Player Stats"

   2:         HorizontalAlignment="Right" Style="{StaticResource NormalButton}"/>

That should be enough to have the user gestures be sent to our view model.

The view model itself is complete, but we need to make some class implement the IModeController. Again, I think the best place, at least for now, is the App class, so we’ll put that interface there – I do suspect that we’ll eventually pull that out of the App class and make it its own class, so that we can test it, but we haven’t had that need yet. Someday, maybe…

That leaves some very minor changes in App.xaml.cs. We add the interface to the class definition, implement the PlayerViewMode method, and tell the container that App implements the IModeController interface (line 8), which allows it to pass an object of that type to the view model’s constructor.

   1: public partial class App : Application, IApplicationController, IModeController

   2: {

   3:     private readonly IUnityContainer container = new UnityContainer();

4:

   5:     private void Application_Startup(object sender, StartupEventArgs e)

   6:     {

   7:         container.RegisterInstance<IApplicationController>(this);

   8:         container.RegisterInstance<IModeController>(this);

9:

  10:         container.RegisterType<IPlayerRepository, PlayerRepository>(new ContainerControlledLifetimeManager());

  11:         container.RegisterType<TeamStatControlViewModel>(new ContainerControlledLifetimeManager());

  12:         container.RegisterType<TeamStatControl>(new ContainerControlledLifetimeManager());

13:

  14:         container.RegisterType<MainWindow>(new ContainerControlledLifetimeManager());

15:

  16:         Current.MainWindow = container.Resolve<MainWindow>();

  17:         Current.MainWindow.Content = container.Resolve<TeamStatControl>();

  18:         Current.MainWindow.Show();

  19:     }

20:

  21:     public void ExitApplication()

  22:     {

  23:         Current.Shutdown();

  24:     }

25:

  26:     public void PlayerViewMode(Player player)

  27:     {

  28:         ;

  29:     }

  30: }

At this point, we’re good to try it out, so start up the application, click on a name, press View Player, and… OK, still nothing happens because we don’t have another window yet. I tested this by putting a breakpoint on line 28 and debugging it to see that I made it to here, which I did, and that the correct player was being sent here. I know my tests told me that this should work, but in the immortal words of Ronald Reagan, “Trust, but verify”.

Part 4 – Showing the other view

We’re in the home stretch now. Let’s show the other view. First, let’s just assume that I created another view. You can see it way back at the top – its the second window you see, with a big name and number in it. Once you’re at this point, all you need to do to enable the app to switch between the main view and this view is to implement the App.PlayerViewMode method correctly. I couldn’t find a way to test this, since I’m manipulating the UI directly, so I just wrote the code:

   1: public void PlayerViewMode(Player player)

   2: {

   3:     Current.MainWindow.Content = null;

4:

   5:     Current.MainWindow.Content = container.Resolve<PlayerDetailControl>();

   6:     ((PlayerDetailControl) Current.MainWindow.Content).DataContext = player;

   7: }

A couple things to note here. First, I didn’t register the type, PlayerDetailControl, with the container. The Unity container will do its best to create any object that hasn’t been registered with it by calling whatever constructor it can find that matches up with arguments it knows how to build. In our case, the class has a default constructor, so it knew how to build it. Since we didn’t register it, Unity will just create a new instance of the control for me every time I ask for it. I can then assign the player to be its DataContext, and we’re done. That turned out to be very easy :)

At this point, we should be able to select a player, click on the View Player button, and the other view should appear. Success! But we’re not quite finished yet… sorry! Two more points to make

Part 5 – Double clicking and CanExecute for the command

Before we finish, I want to cover two other things. The first is how to enable double click behavior for the ListView. There isn’t a simple way to attach a command behavior to the ListView in the version of WPF I’m using. I know that AttachedBehaviors are part of the new WPF version that’s in development now, but I don’t have that, so you’re stuck with this explanation :)

Since there wasn’t a way to attach a command to the double-click event, I had to put code into the code-behind page, which is the first time I’ve had to do that yet! I wired up an event handler to the double-click event through a small change in the XAML for the ListView:

   1: <ListView IsSynchronizedWithCurrentItem="True" Grid.Row="1" VerticalAlignment="Stretch"

   2:     MouseDoubleClick="ListView_MouseDoubleClick"  SelectedItem="{Binding SelectedPlayer}" ItemsSource="{Binding Players}">

and added a trivial handler in the TeamStatControl.xaml.cs file:

   1: private void ListView_MouseDoubleClick(object sender, MouseButtonEventArgs e)

   2: {

   3:     TeamStatControlViewModel viewModel = (TeamStatControlViewModel) DataContext;

   4:     viewModel.PlayerViewMode.Execute(null);

   5: }

All this method does is to call the Execute method of the same command that the button runs. Trivial code. So now we can double-click on a player in the list and the right thing happens.

But what happens if no player is selected (OK, I couldn’t figure out a way to make this happen for the real list view, but it seemed like an interesting example and thought experiment!). We need to implement the CanExecute behavior for the ViewPlayerModeSwitchCommand. As usual, we do this through tests.

In our first test, we confirm that the command cannot execute if no player is selected:

   1: [Fact]

   2: public void ViewModelFunctionalityIsNotOnlyAvailableWhenNoPlayerIsSelected()

   3: {

   4:     TeamStatControlViewModel viewModel = new TeamStatControlViewModel(null, null, null);

   5:     ICommand playerViewModeCommand = viewModel.PlayerViewMode;

6:

   7:     Assert.False(playerViewModeCommand.CanExecute(null));

   8: }

and we implement CanExecute as simply as we can to make the test pass:

   1: public bool CanExecute(object parameter)

   2: {

   3:     return false;

   4: }

Our next test is a little more interesting, as it requires that the CanExecute returns true if a player is selected:

   1: [Fact]

   2: public void ViewModelFunctionalityIsAvailableWhenPlayerIsSelected()

   3: {

   4:     TeamStatControlViewModel viewModel = new TeamStatControlViewModel(null, null, null);

   5:     ICommand playerViewModeCommand = viewModel.PlayerViewMode;

   6:     viewModel.SelectedPlayer = new Player();

7:

   8:     Assert.True(playerViewModeCommand.CanExecute(null));

   9: }

The only real modification here is that we use the SelectedPlayer method of the view model to set the player that would be selected through the real view. We expect that the command class is able to query this SelectedPlayer property through its reference to the view model using the IViewPlayerModeSwitcher interface. Well, that’s what we’d expect, anyhow…

   1: public bool CanExecute(object parameter)

   2: {

   3:     return modeSwitcher.SelectedPlayer != null;

   4: }

The SelectedPlayer property isn’t available through that interface, so as our final step along this long and tortuous path, we add it to the interface, our implementation code compiles, our tests all run, and we celebrate by going home early for the day.

Conclusion

I hope people are finding this case study to be useful. I found a lot of different resources on the web about doing bits and pieces of your WPF/MVVM application test-first, but I still had a lot of unanswered questions. First and foremost on that list was how to do simple navigation like I’m doing. By putting together most of a whole application, I hope its more clear to readers how the different pieces fit together.

I do plan on doing one more step along the way, probably posted tomorrow morning (8/25/2009). I want to show how to handle pop-up windows, including windows dialog boxes as well as custom WPF windows. I had to deal with this on my own project, and it took a bit of thinking to figure out how to do it in a testable way.

Until tomorrow!

-- bab

Test driving a WPF App – Part 2: Adding some data

Brian Button — Sun, 23 Aug 2009 16:33:00 GMT

This is part two of the blog series about creating a WPF application using TDD to drive the functionality and MVVM to split that functionality away from the view into something more testable. You may want to read part one if you haven’t already.

In this part, we’ll see what it takes to display data on the front page about each player on the softball team. We’re not going to display all their stats, since we don’t need to for the example, but it would be very easy to extend this to do so. (N.B. I have a more full version of this that I’ll post that includes a database backend with more data in it than what I’m going to show here. The data backend is irrelevant to the layer being discussed here, so I’m going to ignore those details.)

The end result

At the end of this process, what we’re going to have is a list of players and their numbers. We could easily extend it to total stats for each of them, but that’s outside the point of the example, and is left as an exercise for the reader (I hated when college textbooks said that!).

So anyhow, you can see the 4 players listed and their numbers. This data came from the data repository that I created behind the view, in a class called PlayerRepository. I’m not going to go into the details of how this repository class was created, as the database layer is outside the scope of this article, so we’ll just assume that we created it when it was needed, and I won’t include discussion or tests for it. The important part of us to think about is how the data got into the view model and how it got from there onto the view. And that begins our (short) story.

Step 1 – Get data to the view

In order to get data to the view, the view model needs to expose an ObservableCollection that the view can bind to. I decided to create a property called Players on the TeamStatControlViewModel, driving it through tests. I created a test fixture in the ViewModelFixtures assembly called TeamStatControlPlayersDataBindingFixture, and I put my test into there (as an aside, I’m trying a different style of fixtures here, where I’m naming fixtures after behaviors or features and putting all the tests for those features in that fixture. I’m intentionally trying to break out of the app class <-> fixture class model and create tests around the behaviors of the system, regardless of where those behaviors may lie. Let me know if you like it, please.)

   1: [Fact]

   2: public void ViewModelExposesObservableCollectionOfPlayers()

   3: {

   4:     TeamStatControlViewModel viewModel = new TeamStatControlViewModel(null);

5:

   6:     Assert.IsType<ObservableCollection<Player>>(viewModel.Players);

   7: }

We have to add the Players property to the view model and create an empty Player class in our Model assembly to get this test to compile. Once it runs and fails, we implement the property in the view model to return an empty ObservableCollection<Player> collection. Run again, and the test passes.

   1: public ObservableCollection<Player> Players

   2: {

   3:     get { return new ObservableCollection<Player>(); }

   4: }

Step 2 – Get the data to the view model

Now that we have the data available to be shown on the view, we need to provide that data to the view model. We do this by giving the view model access to the PlayerRepository we spoke of earlier and letting it query the repository for the data as needed. Again, very simple. Here is the test in that same test fixture:

   1: [Fact]

   2: public void DataIsPulledFromModelWhenRetrievingPlayersFromViewModel()

   3: {

   4:     var playerRepository = new Mock<IPlayerRepository>();

   5:     TeamStatControlViewModel viewModel = new TeamStatControlViewModel(null, playerRepository.Object);

   6:     playerRepository.Setup(pr => pr.GetAllPlayers()).Returns(new List<Player>());

7:

   8:     ObservableCollection<Player> players = viewModel.Players;

9:

  10:     playerRepository.Verify(pr => pr.GetAllPlayers());

  11: }

The test start driving to define the behavior our system is going to need. We already know that the view model is going to need a reference to the repository, so we add the repository to the constructor arguments for the view model on line 5. (I like working backwards in a situation like this to discover the objects needed. I’ll write the constructor signature first and use that to drive object creation on previous lines, like you see here.) This forces us to create a mock version of the repository, which we do in line 4 by discovering an IPlayerRepository interface, details to be fleshed out. On line 6, we set up the behavior that we want the view model to invoke on the repository, which is the GetAllPlayers method, which for our purposes needs to return an empty collection of the appropriate type. Finally, we invoke the Players property and verify that the repository’s GetAllPlayers method is indeed called.

In getting this to compile, we create the IPlayerRepository interface and modify the signature of TeamStatControlViewModel to take the new IPlayerRepository parameter. Run test, test fails, and we finally implement:

   1: public interface IPlayerRepository

   2:     {

   3:         IList<Player> GetAllPlayers();

   4:     }

and

   1: public class TeamStatControlViewModel: IApplicationExitAdapter

   2: {

   3:     private readonly IApplicationController applicationController;

   4:     private readonly IPlayerRepository playerRepository;

5:

   6:     public TeamStatControlViewModel(IApplicationController applicationController, IPlayerRepository playerRepository)

   7:     {

   8:         this.applicationController = applicationController;

   9:         this.playerRepository = playerRepository;

  10:         ApplicationExit = new ApplicationExitCommand(this);

  11:     }

12:

  13:     public void ExitApplication()

  14:     {

  15:         applicationController.ExitApplication();

  16:     }

17:

  18:     public ICommand ApplicationExit { get; set; }

19:

  20:     public ObservableCollection<Player> Players

  21:     {

  22:         get { return new ObservableCollection<Player>(playerRepository.GetAllPlayers()); }

  23:     }

  24: }

At this point, we have data coming from the repository and available to the view. All that’s left is to hook up to the view.

Step 3 - Hooking up to the real view

I’m going to cheat a bit and not define a DataTemplate for this and just directly bind to the two columns I’m going to define, Name and Number. I have a ListView in the middle of my window, as you can see in the screencapture at the top if this post. I define a couple GridViewColumns in it and bind them to Name and Number:

   1: <ListView IsSynchronizedWithCurrentItem="True" Grid.Row="1" VerticalAlignment="Stretch" ItemsSource="{Binding Players}">

   2:     <ListView.View>

   3:         <GridView>

   4:             <GridViewColumn Header="Player" DisplayMemberBinding="{Binding Name}"/>

   5:             <GridViewColumn Header="Number" DisplayMemberBinding="{Binding Number}" />

   6:         </GridView>

   7:     </ListView.View>

   8: </ListView>

Obviously I wouldn’t do this on a real project, I’d use a DataTemplate. But for now, this will do. The ItemSource is set to the Players property, and the two columns are set to the fields I want to show.

We don’t have a real instance of our IPlayerRepository yet, so lets build a really simple one. In real life, this would be a repository over the top of a database, but we don’t need to go that far for now. Let’s just create the simplest repository we can for now:

   1: public class PlayerRepository : IPlayerRepository

   2:     {

   3:         public IList<Player> GetAllPlayers()

   4:         {

   5:             return new List<Player>

   6:                        {

   7:                            new Player

   8:                                {

   9:                                    Name = "Linsey",

  10:                                    Number = "42"

  11:                                },

  12:                            new Player

  13:                                {

  14:                                    Name = "Michelle",

  15:                                    Number = "31"

  16:                                },

  17:                            new Player

  18:                                {

  19:                                    Name = "Susan",

  20:                                    Number = "17"

  21:                                },

  22:                            new Player

  23:                                {

  24:                                    Name = "Joan",

  25:                                    Number = "26"

  26:                                }

  27:                        };

  28:         }

  29:     }

One thing we’re still doing is exposing the Player class to the view. This is not necessarily the best practice that has evolved, since the Player class is defined in the Model layer. The danger is that we may end up needing to add INotifyPropertyChanged behavior to the Player class, which would pollute our domain model with view-specific code. If that were to happen, it would force us to refactor the view model to return an observable collection of something else, like an ObservableCollection<PlayerViewModel>, so that we would have a place to put our view-specific code. We don’t need to yet, so we’re not going to bother. This is a potential refactoring to come, though.

And our final change is to add the PlayerRepository type into our Application_Startup method, so that Unity knows how to build the repository and pass it into the TeamStatControlViewModel:

   1: private void Application_Startup(object sender, StartupEventArgs e)

   2: {

   3:     container.RegisterInstance<IApplicationController>(this);

4:

   5:     container.RegisterType<IPlayerRepository, PlayerRepository>(new ContainerControlledLifetimeManager());

   6:     container.RegisterType<TeamStatControlViewModel>(new ContainerControlledLifetimeManager());

   7:     container.RegisterType<TeamStatControl>(new ContainerControlledLifetimeManager());

8:

   9:     container.RegisterType<MainWindow>(new ContainerControlledLifetimeManager());

10:

  11:     Current.MainWindow = container.Resolve<MainWindow>();

  12:     Current.MainWindow.Content = container.Resolve<TeamStatControl>();

  13:     Current.MainWindow.Show();

  14: }

Compile and run, and all should work.

Conclusion

This was a fairly easy step to take. We exposed a property on our view model to let our view see the data we want to publish. Our view model has a repository injected into it to let it get the data as needed. That was really all there was to it. Two tests, and we got to where we needed to be.

The next step along the way will involve navigating from the front page to a player detail page. Stay tuned for the next installment, coming right up!

-- bab

Using Unity to make Singleton-ness an implementation detail

Brian Button — Sun, 23 Aug 2009 05:27:00 GMT

The most common, canonical use of the Singleton pattern irritates me. Every time I see it, I think, “The singleton-ness of a class is an implementation detail, and shouldn’t leak out through that class’s interface.” Yet, that’s what it always does.

In the usual implementation, someone decides that some new class they’ve written is so resource critical, or so standalone, or so useful that they can have only one instance of that class and that instance has to be visible everywhere. Ignoring the intricacies of threading and so on, a Singleton usually looks exactly like this:

   1: public class MyImportantResource

   2: {

   3:     private static MyImportantResource instance;

4:

   5:     private MyImportantResource()

   6:     {

   7:         // ...

   8:     }

9:

  10:     public static MyImportantResource Instance()

  11:     {

  12:         if (instance == null) instance = new MyImportantResource();

  13:         return instance;

  14:     }

  15: }

And it gets used everywhere like this:

   1: public class Consumer

   2:     {

   3:         public Consumer()

   4:         {

   5:             var importantResource = MyImportantResource.Instance();

   6:             importantResource.FooTheBar();

   7:         }

   8:     }

Now what happens when I decide I want two of these? Or I decide that I want to let people create as many of these resources as possible? Or, even more commonly, what happens when I want my Consumer class to use a mocked out version of MyImportantResource? I’m scre^h^h^h^hin trouble.

The trouble comes from the fact that Consumer is reaching out into the ether and grabbing the resource it needs on its own. It isn’t giving me, the developer, control over what type of ImportantResource to use or where the ImportantResource is coming from. The Inversion of Control principle is being violated by having the class gather its own resources rather than having its creator decide and pass resources to it.

My typical solution

What I typically have been telling people is that it is OK to have a singleton, treat it as a singleton, and love the singleton pattern… within reason. At the point in your code where you’re creating all your objects and wiring them up, you should feel perfectly free to use singletons. But no layer beneath that should have any knowledge of the singleton-ness of a class. Grab that singleton and pass it into whoever needs it, preferably as an interface, and you’ve restored order and testability to your system by again returning to the Inversion of Control principle.

My DI solution

Dependency Inversion containers solve this problem for you automatically. I’ve been using Unity lately, and I’ve grown to really like it. One of the things I really like about it, and I’m sure all DI containers have this property, is that I can register a type with the container and tell it that I only want it to create a single instance of this type and pass it around whenever someone asks for that type. Bam! I have a singleton again, but I’ve completely separated the singleton-ness of the class from its singleton-like usage. Major win. Here is the code that lets me do that.

First, the interface over the important resource:

   1: public interface IImportantResource

   2: {

   3:     void FooTheBar();

   4: }

Now the changes in the MyImportantResource class to bring it back to being a regular class. Note that all mention of singleton-ness is gone from this class. Its just a plain, old class again, which is how we like it.

   1: public class MyImportantResource : IImportantResource

   2: {

   3:     public MyImportantResource()

   4:     {

   5:         // ...

   6:     }

7:

   8:     public void FooTheBar()

   9:     {

  10:         throw new NotImplementedException();

  11:     }

  12: }

Next, the changes in the Consumer class that promote the loose coupling encouraged by Inversion of Control, by injecting an IImportantResource at construction:

   1: public class Consumer

   2: {

   3:     public Consumer(IImportantResource importantResource)

   4:     {

   5:         importantResource.FooTheBar();

   6:     }

   7: }

And finally, the object construction code I can write:

   1: public static class Configurator

   2: {

   3:     private static IUnityContainer container;

4:

   5:     public static void Main(string[] args)

   6:     {

   7:         container = new UnityContainer();

8:

   9:         container.RegisterType<IImportantResource, MyImportantResource>(new ContainerControlledLifetimeManager());

10:

  11:         Consumer consumer = container.Resolve<Consumer>();

  12:     }

  13: }

The interesting bit of code here is on line 9, where I register MyImportantResource. I’m telling the container that whenever someone asks for an IImportantResource, it should give them a MyImportantResource object, and that it should give it the same instance every time (that what the new ContainerControlledLifetimeManager()) says. I’ve magically turned my MyImportantResource into a singleton class without polluting the code of that class with statics and instance methods.

Conclusion

Operationally nothing has changed. Assuming people always go to the container for their object instances, MyImportantResource is still a singleton. I will only have one instance of it, it is still accessible from a single place. Should I ever decide to allow 4 instances of it, I can create my own lifetime manager class that will create up to four instances and manage them for me. But now all of my classes are just that, classes. The design decision of how many instances of the resource is separated from the operation of the resource, which allows the two different design issues to evolve separately. And I’ve applied Dependency Inversion to the Consumer class, which allows it to have mock versions of the resource injected to enable testing scenarios that were more difficult when it was using the singleton.

-- bab

Test Driving a WPF application using MVVM and TDD

Brian Button — Mon, 17 Aug 2009 05:31:00 GMT

This is a preview of the material I’m going to be presenting at the St. Louis Day of Dot Net in a couple weeks.

Introduction

For those of you who are reading this blog for the first time, I’m pretty much the St. Louis Agile Zealot. Long hair, flowing robes… you get the picture :) I’ve been advocating Agile and XP in St. Louis since around 2000, through speaking at various user groups and local conferences, teaching at local companies, giving talks in the park, dropping leaflets from airplanes, and so on. I live Agile in my day job at Asynchrony Solutions, where I lead their Agile training and mentoring group. I am totally sold on Test Driven Development as the best way for me to write my code, and I’ve been occasionally known to share that opinion with others.

As far as WPF experience goes, I’m still pretty new in my learning curve. I’ve been playing with a project on my own for a few months, trying new things, reading, and experimenting. When I first started out, I completely wrote a Winforms app in WPF. I used a full-on MVP/MVC architecture, had my button click methods in my window classes, etc. A complete mess… Then I started reading about MVVM and that sparked something inside me that realized that this finally made sense. This was something that gave me a lot of the advantages of the MVP-like architectures, such as being able to test my UI without actually running the UI, but without the overhead of wiring all that junk up myself.

What follows are the lessons I’ve learned in the process of rethinking my original app and in writing this sample app for my talk.

The Application

My daughter plays select softball for one of the organizations here in St. Louis. They have a web site that lists all their stats throughout the year, and I thought it would be fun to mimic that site as a desktop app. The application would list all the girls’ total stats on the front page and give you the ability to drill down into detailed stats for each game on subsequent pages. For fun, I wanted to be able to add stats for new games, and add and delete players. With that set of features, it seemed that I’d be able to drive out a lot of interesting opportunities to change around the design to let me write the code in a TDD manner.

Here is the main page of the application, in all its glory. Remember that I am but a poor developer, with a developer’s eye for style :)

The display of stats isn’t complete yet, but it was enough to validate that my data binding was working. Let’s look at what it took to get this far…

Note: If you want to skip the setup stuff and get right to the parts where behavior is added, jump ahead to Step 3.

Our Roadmap

As a quick review, before we dive in, here is an overview of the MVVM design pattern and the players involved.

The View represents the surface that the user interacts with. It is the WPF code, the UI, and XAML… all that stuff that users see and that is hard to test in an automated fashion. Our goal is to take as much logic out of there as possible, to allow us to have the highest amount of confidence and the greatest amount of test coverage that we can achieve.

Next to the View is the ViewModel. The ViewModel represents the entire set of data and behavior contained in the View. It has properties to expose all the different pieces of data that the View will need to display, and it exposes another set of properties for all the behavior that the View will need to invoke.

The View and ViewModel are tied together in two separate, but very similar, ways. Through Data Binding, data travels between the View and ViewModel automatically. WPF, through the wonders of its internal magic, keeps consistent the data shown in the View and the data held in the ViewModel. There is a bit of work that we have to do to ensure this happens, but it mostly all automatic. The Commands are representations of the behavior that users invoke through the View. Individual commands are exposed through properties on the ViewModel and tied to controls on the View. When the user presses a button, for example, the command attached to that button fires and something happens. You can think of Commands as little controllers, focused on a specific topic, whose responsibility it is to respond to a user action in a particular manner by coordinating the response to that action between the View and ViewModel.

Our goal here is to put all logic about the View into the ViewModel. The View should be very thin and code-less, and the Commands should be thin shims that merely provide an execution conduit between the gesture being made and the behavior being invoked in the ViewModel. Code in the View or in Commands should be looked up with suspicion, with an eye towards trying to move it into someplace more testable. Sometimes you can move that code, and sometimes its entirely appropriate where it is, but the question should always be asked.

Step 1 – Modify the template to support TDD

When you create a WPF application using the Visual Studio New Project dialog, you get the framework of an empty application. There is no code anywhere, other than an InitializeComponent() call here and there. Most of the interesting behavior, at this point, takes place through XAML – things like instantiating the Application object, creating the main window and causing it to display, and other basic things like that. While this works, and works fine for the empty application, we’re going to need more control over how this initiation process occurs, for reasons we’ll discuss later in this post or a subsequent one.

So, to control the initial creation, there are a few changes we need to make. The first step is to put ourselves in control of when and where the main window is created. As time goes on, there are aspects of this creation process that we’re going to want to control, like wiring together other objects, so we’ll need full control over the how windows and controls are born.

App.xaml

When first created, App.xaml looks like this:

   1: <Application x:Class="WpfApplication1.App"   2:     xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"   3:     xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"   4:     StartupUri="Window1.xaml">   5:     <Application.Resources>   6:             7:     </Application.Resources>   8: </Application>

The StartupUri attribute of the Application element is what causes the class defined in Window1.xaml to be instantiated. We want to prevent this from happening until we’re ready for it, so we have to take this out. We’ll still need to create this window, however, so we’ll need to arrange for another way to create objects as the system is starting. It turns out that WPF exposes and event that is perfect for this initialization, the Startup event. By providing a handler for the Startup event, we can have a place to put all our initialization code.

App.xaml now looks like this:

   1: <Application x:Class="WpfApplication1.App"   2:     xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"   3:     xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"   4:     Startup="Application_Startup">   5:     <Application.Resources>   6:     7:     </Application.Resources>   8: </Application>

Now we have to add some code into the App.xaml.cs file to create the objects we need and to wire them together. Please note that I’m not writing tests for this code, because this is configuration code, not business logic. I view logic such as this the same way I view a Main method, and I tend not to test Main’s. It is where objects are created and wired together and then told to go on their merry way. This is not meant to be reusable code and should be just simple declarations of objects and assignments of variables. If I manage to screw up Main, the application isn’t going to work anyhow, and I’m pretty sure I’ll know it :)

   1: using System.Windows;   2:     3: namespace WpfApplication1   4: {   5:     public partial class App : Application   6:     {   7:         private void Application_Startup(object sender, StartupEventArgs e)   8:         {   9:             Current.MainWindow = new MainWindow();  10:             Current.MainWindow.Show();  11:         }  12:     }  13: }

The final step is to rename the template-provided window name of Window1 to MainWindow and make sure I instantiate it with the proper class name in the Application_Startup method, the handler for the Startup event. Once that is done, you can start the project, and an empty window should appear.

One more change…

Before going further, I’d like to introduce Unity into the codebase. Unity is the dependency injection library from Microsoft, and I’ve found it to be very useful in my WPF applications. Here is the previous code after injecting Unity (injecting Unity – HA! I kill myself).

   1: using System.Windows;   2: using Microsoft.Practices.Unity;   3:     4: namespace WpfApplication1   5: {   6:     public partial class App : Application   7:     {   8:         private readonly IUnityContainer container = new UnityContainer();   9:    10:         private void Application_Startup(object sender, StartupEventArgs e)  11:         {  12:             container.RegisterType<MainWindow>(new ContainerControlledLifetimeManager());  13:    14:             Current.MainWindow = container.Resolve<MainWindow>();  15:             Current.MainWindow.Show();  16:         }  17:     }  18: }

Briefly, the point of this code is to register a type, MainWindow, with the Unity container, and then use the container to instantiate the MainWindow object as the application’s main window. The reason I introduced Unity is to separate myself from the semantics of object creation. Unity will take care of instantiating any objects I ask for, as well as any objects that the class being created needs. Its just a way of relieving myself of having to worry about constructor signatures, basically.

Step 2 – Adding the initial content

Its time to fill in the empty window with some content. We’ll avoid adding any behavior yet, we just want to see something. The strategy that we’re going to use is to keep the MainWindow class as the one window in our application, and we’ll swap in and out different pieces of content to show in it. In my projects I’ve found this pattern to be useful, because it lets me layer content to mimic a workflow in the application, and have the content always show up in the same place, be the same size, and not take extra work to manage.

So our goal now is to set the MainWindow’s content to be the initial view we want to show people when they first open the application. The design for this looks like this:

And the implementation is easy, too.

First, I create my user control, TeamStatsControl:

At the same time, I create a ResourceDictionary to hold styles that I’ll be using around the app and merged that dictionary into my UserControl.Resources section. I created a menu, a somewhat attractive header, and a couple of buttons. There’s no behavior in it yet, but that’s coming shortly.

Now, for the fun part, let’s make the simple change to make the content show up in the MainWindow. Since we’re creating a new object, our TeamStatControl, we have to make a few simple changes in App.Application_Startup. We need to register the user control with Unity so that it can create it as needed, and then resolve an instance of it as the Content property of the MainWindow. Once that is done, WPF takes care of making it appear in the window.

   1: private void Application_Startup(object sender, StartupEventArgs e)   2: {   3:     container.RegisterType<MainWindow>(new ContainerControlledLifetimeManager());   4:     container.RegisterType<TeamStatControl>(new ContainerControlledLifetimeManager());   5:     6:     Current.MainWindow = container.Resolve<MainWindow>();   7:     Current.MainWindow.Content = container.Resolve<TeamStatControl>();   8:     Current.MainWindow.Show();   9: }

And, by the way, I also changed the Width and Height properties in MainWindow to be 600 and 1000 respectively so that the entire user control would be visible.

Step 3 – Adding behavior

Now that the shell is in place, we can add the behavior that we want. First, lets add the basic behavior of exiting the application in an orderly way. We want to be sure to do this in a way that all the code that we write is testable, and that is going to require a bit of extra work over and above just writing the simplest code. This is the price one pays when writing code using TDD, but the extra effort pays off in systems that work.

Let’s start by writing our first test. This test will be a test of the Command object, which is the object that the view will interact with. An underlying force of the MVVM pattern is that the ViewModel encapsulates the visible data and behavior of the View. And the Command object acts as the conduit through which the gestures of the user are translated into tangible actions in the ViewModel. Here is a sequence diagram showing this behavior:

Clicking the button causes the Command.Execute method to fire, which calls a method in the ViewModel. That method does the real work of this system, with the calls coming before it just part of the plumbing to cause things to happen.

So lets write a test to show that the above sequence is what will actually happen – that calling the Execute method of some Command object will invoke some sort of behavior that causes the application to exit.

Our first test:

   1: namespace ViewModelFixtures   2: {   3:     public class ApplicationExitBehaviorFixture   4:     {   5:         [Fact]   6:         public void ApplicationExitingBehaviorInvokedWhenExecuteCalled()   7:         {   8:             var exiter = new Mock<IApplicationExitAdapter>();   9:             ApplicationExitCommand command = new ApplicationExitCommand(exiter.Object);  10:             exiter.Setup(e => e.ExitApplication()).Verifiable();  11:    12:             command.Execute(null);  13:    14:             exiter.Verify(e => e.ExitApplication());  15:         }  16:     }  17: }

For those of you unfamiliar with the tools used in this test, I’m using Moq as my mocking framework and xUnit for my tests. These are my two favorite tools for TDD as of now, and I highly recommend both of them.

Beginning on line 7, defines the behavior of the system when my ApplicationExitCommand.Execute method is called. I’m defining the interface that the command is going to talk to, IApplicationExitAdapter, and I’m doing this in total and complete ignorance of what class is ever going to implement that interface (OK, I’m lying – its going to be my view model, but let’s keep that our secret for now).

And the code that we write to get this test to compile:

   1: namespace ViewModels   2: {   3:     public interface IApplicationExitAdapter   4:     {   5:         void ExitApplication();   6:     }   7: }

   1: namespace ViewModels   2: {   3:     public class ApplicationExitCommand : ICommand   4:     {   5:         public ApplicationExitCommand(IApplicationExitAdapter exitAdapter)   6:         {   7:             throw new NotImplementedException();   8:         }   9:    10:         public void Execute(object o)  11:         {  12:             throw new NotImplementedException();  13:         }  14:    15:         public bool CanExecute(object parameter)  16:         {  17:             throw new NotImplementedException();  18:         }  19:    20:         public event EventHandler CanExecuteChanged;  21:     }  22: }

Strictly speaking, I went a little further than I had to here, choosing to implement ICommand, but all commands that are hooked through a View as we’re discussing need to implement this interface (or one of a couple of others that are more advanced), so I just went ahead and did it.

Short Aside – Projects and Solution Structure

Before we go further, we should discuss the projects I’ve chosen to use in this solution, and why they were chosen. I have one project that holds the view and a separate project that holds the view models. I intentionally kept the Views and ViewModels separate to enforce the direction of the relationship between them. The Application class and the other WPF controls need to have access to the ViewModels, if only to create them and assign them to DataContexts. ViewModels, however, should be 100% ignorant of their views. The simplest way to enforce this constraint is to put all view model code into another assembly, which is what I’ve done.

Now its a simple matter of implementing the code to make the test pass:

   1: public class ApplicationExitCommand : ICommand   2: {   3:     private readonly IApplicationExitAdapter exitAdapter;   4:     5:     public ApplicationExitCommand(IApplicationExitAdapter exitAdapter)   6:     {   7:         this.exitAdapter = exitAdapter;   8:     }   9:    10:     public void Execute(object o)  11:     {  12:         exitAdapter.ExitApplication();  13:     }  14:    15:     public bool CanExecute(object parameter)  16:     {  17:         return true;  18:     }  19:    20:     public event EventHandler CanExecuteChanged  21:     {  22:         add { CommandManager.RequerySuggested += value; }  23:         remove { CommandManager.RequerySuggested -= value; }  24:     }  25: }

I also went ahead and added some boilerplate code into the CanExecute and CanExecuteChanged method and event inside this class. This boilerplate code is what you start with every time you write a command. You can think of this as creating a command using a code template inside Visual Studio.

At this point, the command should be invoking the behavior that we want, as seen in this diagram:

Now that the behavior is being called inside the IApplicationExitAdapter, we’ll need to make the giant leap and assume that it is, indeed, our view model class that is going to be implementing that interface. This only make sense, since the Command is invoking behavior on some class that represents the behavior of the View, and the class that represents a View’s behavior is that View’s ViewModel. Q.E.D. Once we’ve crossed that intellectual chasm, we’ll go ahead and implement the functionality inside the view model.

For that, we write this test:

   1: [Fact]    2: public void ApplicationControllerInvokedWhenViewModelExitApplicationCalled()   3: {   4:     var applicationController = new Mock<IApplicationController>();   5:     TeamStatControlViewModel viewModel = new TeamStatControlViewModel(applicationController.Object);   6:     applicationController.Setup(ac => ac.ExitApplication()).Verifiable();   7:     8:     viewModel.ExitApplication();   9:    10:     applicationController.Verify(ac => ac.ExitApplication());  11: }

This test causes us to make a few design decisions. First, we’ve discovered an interface called IApplicationController that is going to be responsible for controlling application-wide behavior, which would certainly include things like exiting at the appropriate time. We’re also creating the view model class, TeamStatControlViewModel, since we have to add behavior directly to it now. And finally, we’ve discovered that the view model needs to have a reference to the IApplicationController interface, to allow it to invoke functionality through that interfacee. This leads us to creating a constructor for the view model through which we can inject the interface at creation.

Here is the resulting code. First, the simple IApplicationController interface:

   1: namespace ViewModels   2: {   3:     public interface IApplicationController   4:     {   5:         void ExitApplication();   6:     }   7: }

and now the TeamStatControlViewModel:

   1: namespace ViewModels   2: {   3:     public class TeamStatControlViewModel : IApplicationExitAdapter   4:     {   5:         private readonly IApplicationController applicationController;   6:     7:         public TeamStatControlViewModel(IApplicationController applicationController)   8:         {   9:             this.applicationController = applicationController;  10:         }  11:    12:         public void ExitApplication()  13:         {  14:             applicationController.ExitApplication();  15:         }  16:     }  17: }

That’s just enough code to make that test pass, so we’re momentarily happy. However, our system isn’t going to work yet, because we haven’t found anyone to implement the IApplicationController interface. That’s our next major decision.

I’m going to choose to put this interface onto the App class, at least for now, since it seems to be the one place in our application that has knowledge of the entire application. It may turn out later that we need to move this responsibility somewhere else, but we’ll leave it here for now.

We’ll go ahead and make the easy changes to App.xaml.cs, which consist of making it implement IApplicationController and writing the ExitApplication method, which simply calls Current.Shutdown().

   1: public partial class App : Application, IApplicationController   2: {   3:     private readonly IUnityContainer container = new UnityContainer();   4:     5:     private void Application_Startup(object sender, StartupEventArgs e) {...}   6:     7:     public void ExitApplication()   8:     {   9:         Current.Shutdown();  10:     }  11: }

The important point to note is that the IApplicationController interface lives in the ViewModel assembly, even though it is being implemented by the App class in the main WPF assembly. This means that the main WPF application project has to have a reference to the ViewModel project, which is the direction we want the dependencies to flow. By moving the ViewModel classes and interfaces into an a project separate from the view classes, we’re enforcing our dependency management design as we described earlier.

This now leaves us with this for a design:

So we’re in the home stretch now. We have all our code built – what is lacking now are the few scattered bits and pieces needed to wire this whole thing together. There are several of these pieces, and we’ll look at them one at a time.

Let’s start with the object creation changes needed in App.Application_Startup. Over these last few changes, we’ve created a new interface for the App class, so we need to tell Unity that when I ask for an instance of an IApplicationController, it should pass back a reference to the App class. You can see this code on line 3 below. We also created a TeamStatControlViewModel, which we tell Unity about on line 5.

   1: private void Application_Startup(object sender, StartupEventArgs e)   2: {   3:     container.RegisterInstance<IApplicationController>(this);   4:     5:     container.RegisterType<TeamStatControlViewModel>(new ContainerControlledLifetimeManager());   6:     container.RegisterType<TeamStatControl>(new ContainerControlledLifetimeManager());   7:     8:     container.RegisterType<MainWindow>(new ContainerControlledLifetimeManager());   9:       10:     Current.MainWindow = container.Resolve<MainWindow>();  11:     Current.MainWindow.Content = container.Resolve<TeamStatControl>();  12:     Current.MainWindow.Show();  13: }

Next, we know that TeamStatControlViewModel is going to be the DataContext for the TeamStatViewModel, so let’s make that happen in code. The easiest way is to change the constructor for the TeamStatControl to take the view model and assign it to be its DataContext in its constructor. The really cool part of this is that we don’t have to make any changes in App.ApplicationStartup based on this constructor changing. Unity will just build all the dependent objects for us and call whatever constructors it can find, and it all just works.

   1: public TeamStatControl(TeamStatControlViewModel viewModel)   2: {   3:     DataContext = viewModel;   4:     InitializeComponent();   5: }

Now that we have the objects built and wired up, we need to do the data binding to put the commands into the controls on the interface. The first place to do this is in TeamStatControl, where we define the Quit button. We need to assign an instance of the ApplicationExitCommand to the Command attribute of the button. Here is the XAML code that will do this for the Quit button:

   1: <Button Command="{Binding ApplicationExit}" Grid.Column="1" Content="Quit" HorizontalAlignment="Left" Style="{StaticResource NormalButton}"/>

We do this by creating a binding to the ApplicationExit property of our data context, the TeamStatControlViewModel. The view is now expecting the view model to expose a property called ApplicationExit, of type ICommand, through which it can get the command. We don’t have that property right now, so lets write a test that makes us create it.

   1: [Fact]   2: public void ViewModelExposesApplicationExitCommandAsICommand()   3: {   4:     TeamStatControlViewModel viewModel = new TeamStatControlViewModel(null);   5:     6:     Assert.IsAssignableFrom<ApplicationExitCommand>(viewModel.ApplicationExit);   7: }

This test says that we can get an ICommand from the view model and the ICommand we get is actually an ApplicationExitCommand, which is what we need. We just need to implement that through creating a simple auto-property in the view model. That satisfies what we need for the binding we defined in the XAML. Now, we construct the command in the constructor of the TeamStatControlViewModel class and pass an instance of the view model to the constructor of its command to wire that up, and we’re set!

   1: public TeamStatControlViewModel(IApplicationController applicationController)   2: {   3:     this.applicationController = applicationController;   4:     ApplicationExit = new ApplicationExitCommand(this);   5: }   6:  

After all this, running the application and clicking the Quit button should cause the app to vanish silently, slipping into the night, never to be seen again. Whew!

A Bonus

Now that all this hard work is done, we can also hook this same logic to the menu button. If we go into the XAML and find the line where we define the menu item, we just set its Command attribute to be a binding to ApplicationExit as well, and now it works, too.

Conclusion

As I said at the beginning, this blog entry, and the couple more that will follow this week, will form the basis for my St. Louis Day of Dot Net talk on this same subject. I’d appreciate any and all feedback on this article, especially including things that weren’t clear, design leaps I made without a clear reason, and alternative ways to do the same things I did.

You can find the complete project for this on my website. You may need to install Unity to get the solution to compile.

Thanks for reading, and I hope it helps!

-- bab

Are you coming to St. Louis Day of DotNet?

Brian Button — Sat, 15 Aug 2009 06:08:00 GMT

Only a few seats left, apparently, for the conference on August 28th and 29th. Register here. Looks like lots of good sessions, lots of good topics, and filled with good speakers.

Personally, I’m speaking on Using MVVM and TDD to test drive a WPF application.

bab

I'm thinking of an example...

Brian Button — Fri, 03 Apr 2009 18:08:00 GMT

I'm writing an example for a workshop on estimation in an agile context, and I'm considering using the idea of preparing a multi-course meal. I think I like this because it is entirely non-technical, so I can give it to developers, customers, QA, or anyone else without regard to previous technical knowledge. I also like it because there are obvious tie-ins to concepts like freshness, inventory, rapid delivery, and so on. That is as close to the real-world considerations of a software project I can think of while keeping it approachable for everyone.

So, here goes:

I have 100 guests showing up in 6 hours for an end of project celebration. This is the entire project team and their families. They did a great job on their last delivery, so we want to reward them with a feast. The menu is top secret, but we want it to surprise and delight them as much as possible. Here is the schedule:

12:00PM - 1:00PM - Guests start arriving. I need hors d'oeuvres ready and passed around through the crowd as they gather.

1:00PM-2:00PM - Salad and appetizer course served

3:00PM-4:00PM - Lunch

5:00PM-5:30PM - Dessert and Coffee

That gives us 4 different courses to serve. I have a kitchen filled with supplies, everything you might need. The pantry is well stocked, tons of pots and pans, spices, herbs, three ovens and stoves, and anything else you might need. I just need you and your team of world-class chefs to create something for me and my guests.

I'd like to have 4 or 5 different hors d'oeuvres, 3 different kinds of salads, 2 kinds of appetizers. Lunch should be a buffet of 3 meats, 2 pasta dishes, 3 vegetables, and a rice dish. I'd like 3 different desserts, one decadently sweet, one fruit dish, and a big cake.

So, off you go. Give me a selection of great food at each of these times. Bear in mind that things can go wrong, like ovens not working, menus changed, schedules shortening, so you'll have to constantly keep your eye on time and delivering the best culinary value for the given effort.

So, how did that sound? I intend to mix things up by adding vegetarian dishes to the lunch menu, an oven going out, changing the schedule, running out of something... Basically doing whatever it takes to have them adapt, replan, and go forward.

Does this sound close enough to a real software project to be useful? Does the exercise sound like anything that would teach estimation and prioritization? Any sort of feedback would be greatly appreciated.

bab

Handling interactions between ViewModel classes

Brian Button — Fri, 27 Mar 2009 05:59:00 GMT

I’ve been puzzling over what seemed to be an insurmountable problem lately. It seemed that the guys who came up with the MVVM design pattern totally missed the boat on anything more than a simple, single-page app. It couldn’t be me, since I’m a SuperGenius (TM).

Well, OK, it did turn out to be me. Once I stopped flailing about in WPF-land and actually thought about the problem, it became easy.

The Problem

What I was trying to do seemed pretty simple, and I couldn’t figure out how to make it work, which is why I was sure it was them and not me – how wrong I would be…

Basically, I had an app with multiple views. In one view, I was doing something that caused some data to be updated. I wanted to show the updated data in another view. Since the two views were using two different ViewModels, I couldn’t figure out how data binding by itself could solve the problem. Then it came to me – the two different ViewModels were sharing the idea of the data they were both showing, and data is supposed to live in the Model layer. Duh!

Once this epiphany drilled its way through my head, I figured out how to solve the problem (Note – I’m 100% new to WPF, so there is every chance there is an easier way to do this. If you know it, please let me know!)

The Solution

The key to this was to make both my ViewModels implement INotifyPropertyChanged to hook them up to propagate changes to and from their Views. Then I created an event in the Model that would be raised whenever the underlying data they were sharing was changed. My model looked like this:

   1:     public class Model

   2:      {

   3:          private String modelValue;

4:

   5:          public delegate void ModelChangedEvent(object sender, ModelChangedEventArgs e);

   6:          public event ModelChangedEvent ModelChanged;

   7:          public void SetValue(string newValue)

   8:          {

   9:              modelValue = newValue;

  10:              if(ModelChanged != null)

  11:              {

  12:                  ModelChanged(this, new ModelChangedEventArgs {OldValue = modelValue, NewValue = newValue});

  13:              }

  14:          }

  15:      }

And I had my target ViewModel listen for this event. In the event handler for the ModelChangedEvent, the ViewModel used the newValue to set the value it needed to show on the View, which caused the PropertyChanged event to be raised, and everything worked like a champ. Here is the target ViewModel:

   1:      public class ReflectedViewModel : INotifyPropertyChanged

   2:      {

   3:          private string reflectedValue;

   4:          private Model model;

   5:          public event PropertyChangedEventHandler PropertyChanged;

6:

   7:          public Model Model

   8:          {

   9:              get { return model; }

  10:              set

  11:              {

  12:                  if(model != null) throw new InvalidOperationException("Attempted to set model more than once.");

  13:                  model = value;

  14:                  model.ModelChanged += model_ModelChanged;

  15:              }

  16:          }

17:

  18:          void model_ModelChanged(object sender, ModelChangedEventArgs e)

  19:          {

  20:              ReflectedValue = e.NewValue;

  21:          }

22:

  23:          public String ReflectedValue

  24:          {

  25:              get { return reflectedValue; }

  26:              set

  27:              {

  28:                  if(value.Equals(reflectedValue) == false)

  29:                  {

  30:                      reflectedValue = value;

  31:                      if(PropertyChanged != null)

  32:                      {

  33:                          PropertyChanged(this, new PropertyChangedEventArgs("ReflectedValue"));

  34:                      }

  35:                  }

  36:              }

  37:          }

  38:      }

You can download the entire example from here.

Conclusion

This was not a hard problem to solve, once I stopped and actually thought about it. I got so wrapped up in the new framework and toys (WPF/XAML) that I forgot about everything else I knew for a bit :)

As usual, any and all comments appreciated. Comments telling me about easier and more idiomatically correct ways of writing this are 100% welcomed!

-- bab

Agile in 6 words

Brian Button — Tue, 13 Jan 2009 16:18:00 GMT

My good friend, Matt Philip, wrote an interesting blog entry the other day about Six-Word Memoirs By Writers Famous and Obscure. I thought it might be interesting to write about the agile methods, their values, and their practices, following a similar style. So here goes, my own take on Six-Word Memoirs on Agile Values, People, and Activities…

Agile: Business plans, developers do, people thrive
Agile: Don’t want “resources”, give me people!
Agile: Project success comes from working together
Agile: Engine converting features to software daily
Agile: Solve biggest problem. Lather, rinse, repeat

QA: Hey, I made the team!!! Yea, QA!!!
QA: Building it right the first time
QA: Equal parts developer, tester, and customer
QA: The glue that holds ‘em together
QA: Helping customers define what they want

Scrum Master: Equal parts facilitator, friend, and psychologist
Scrum Master: My job is to listen carefully
Scrum Master: If I do it, you don’t!
Scrum Master: Fixing problems is not the solution

Customer: Content is mine, method is yours
Customer: I chart the course to success
Customer: You let me worry about that
Customer: Word of mouth, my best tool
Customer: Don’t read specs, ask me questions

Developer: I eat user stories for breakfast
Developer: I trust my customer and team
Developer: It feels good to be valued
Developer: Method is mine, content is yours
Developer: Best architectures owned by whole team
Developer: Ivory tower architects need not apply
Developer: Red, green, refactor. Lather, rinse, repeat.
Developer: Its more fun done in pairs

Delivery: Running, tested features - what really counts
Delivery: Scope is negotiable, quality is not
Delivery: Not over, under promising, just delivering
Delivery: Reliably delighting the customer every week

I could do more, but lets leave it there. Any more?

—bab

Obvious comment of the day - TDD makes Pair Programming easier

Brian Button — Wed, 08 Oct 2008 13:06:00 GMT

A fairly obvious observation hit me today…

If you are trying to pair program without also doing test driven development, when do you change roles? When doing TDD with Pairing, there is a rhythm to when the roles switch - see Micro Pairing. But if you’re not doing TDD, the person typing is frequently lost in solving a fairly large problem, they are balancing a bunch of things in their heads, and they have to finish a big thought before they could possibly swap the keyboard with their pair. So, while the typer is solving these big problems, what does the other person do? Just sit there? It just seems pretty painful…

I’m sure its not impossible, but it sure seems like TDD is a near necessity for Pair Programming.

Thoughts?

— bab

Continuing the Growing up Geek Meme

Brian Button — Tue, 07 Oct 2008 10:02:00 GMT

I’ve been tagged by Brad Wilson to tell a bit about my geek childhood. Like most of you, I certainly had one :)

My earliest geek memories starts with watching Star Trek back in about 1972. It was Return of the Archons - the one where the zombies in robes wander around talking about “Being of the Body”. I remember being totally and completely fascinated by it, and being hooked on science fiction from that point on. That led me to finding the Heinlein juveniles, like Space Cadet, The Rolling Stones, Double Star, Citizen of the Galaxy and so on. I can honestly say that Heinlein’s attitudes about politics, religion, and life, as well as Spock’s general logical demeanor, were a huge influence on me back when I was somewhere near 10 or a bit younger.

A few years later, I learned about amateur radio somehow. I think it was a year or two before we moved from Des Moines, IA to St. Louis, MO. I remember buying The Amateur Radio Handbook, a highly technical book that was years too old for me — I must have been about 8 at the time. I wanted to get my ham license right then, immediately, so I started studying. Of course, electronic theory was a big part of the test, so I had to learn about stuff like Ohm’s Law. The only problem was that it kind of required algebra, and at 9, I hadn’t really learned that yet. So my 4th grade teachers, Mrs. Clark and Ms. Dean, sent me to the 5th grade teacher for algebra tutoring. I did finally get my license a couple of years later, after moving to St. Louis. A couple helpful hams in town taught me the last few bits I needed, including letting me practice Morse Code, and I passed my General test when I was 10 or 11. I was now WD0FDG :) Over the next couple of years, I studied for the highest class license, the Amateur Extra, taking the test a couple of times, only to fail. On my last attempt, I missed the last two questions on the exam, pushing me over the limit by 1. Had I passed, I would have been one of the 10 youngest Extra class licensees in the country at that point :(

After that, I spent a lot of my time reading Heinlein’s more mature novels, talking on my radio, playing with electronics, playing violin, and other exciting activities for an early-teen boy.

I eventually did find sports and girls a few years later, but some things never change… I haven’t been on the radio on years, but I know I’ll get back to it some day. I did pick up amateur astronomy a few years ago, a similarly geeky habit, still read Heinlein religiously, if you’ll excuse the expression, and still watch Star Trek in all its forms. And now there is this computer thing that seems to eat up so much of my time :)

Well, that is the geek story of me. Hmmm, I guess I should tag a couple of other folks now… How about Cory Foy, Ade Miller, and Michael Feathers…

(I’ll update this post with a picture of me as a kid once I get home!)

— bab

A Story Splitting Story

Brian Button — Thu, 02 Oct 2008 09:29:00 GMT

This is a true story from a true client I’m working with . The names and details have been changed to protect the innocent…

Story splitting

Several of us were attending a pre-sprint planning meeting yesterday, trying to flesh out the user stories that the product owner was planning to bring to sprint planning in a few days. They are still pretty early in their agile adoption as well as their technology adoption, so there are lots of questions floating around about process and tools.

A story came up in the meeting that described the interaction that a user would take when visiting the site the first time, more specifically around the user agreement presented to them the first time they logged into the site. The story was something like:

“As a user, I want to be to able to accept the user agreement so that I can access my content”

The details of this story included a specific workflow to follow if the user didn’t agree, including errors to show them, and a need to refrain from showing the user agreement again after agreeing to it the first time.

Conversation around this story went on for a while, mainly focusing around the second part, how to handle remembering what the user did the last time they visited the site. There were technical details about where this information needed to be stored that hadn’t been agreed to yet, and team spun a bit around this issue.

The suggestion was made to split the story into two. The first story would be the same as the first, “As a user, I want to be able to accept the user agreement so that I can access my content”, and it included all the acceptance criteria other than the remembering part. The second story would be “As a previously logged in user, I will not be presented with the user agreement, since I had already agreed to it”, which picked up the remembering part.

By splitting the story in this way, they were able to work out the important part for the customer, which was the user agreement workflow, and defer the technical issues over where to store the agreement status until they could discuss the issue more.

Moral of the story

When discussing a story, if there is contention about how part of it is done, it is sometimes possible to split the story so that the understood part is separated from the not understood part, allowing progress to be made. In this case, we knew how to write the workflow, but not how to prevent the user from seeing the agreement each time. We split the story at that particular edge, which allowed the team to build something useful, and to defer what they didn’t know yet until they knew more about it later.

— bab

What do you think of this code?

Brian Button — Sun, 13 Jan 2008 21:15:00 GMT

I recently finished 6 weeks of coding for a client, and it was heaven! I actually got a chance to code every day, for 6 solid weeks. It was a chance for me to learn C# 3.0, and a chance to work on testing things that are hard to test. It was great!

Out of the work, came several interesting observations and coding techniques, all rooted in C# 3.0. Since no one at work has any experience with these new idioms I "invented", "discovered", or just "copied", I'd love to get some reader feedback. I'll start with this one trick I tried, and follow on with more as the mood strikes me over time.

Trick 1: Using extension methods and a marker interface in place of implementation inheritance

I had an instance of code duplication in two parallel hierarchies of classes, and I wanted to find a way to share the code. One option would be to use inheritance, factoring out another base class above BaseResponse and BaseRequest. This is where methods common to requests and responses could both live. Using inheritance as a way to reuse code in a single inheritance language is a pretty heavyweight thing to do. I'd rather find a way to use delegation, since that preserves the SRP in my class hierarchy. Instead, I decided to try an extension method, and just use that method where I needed it. To avoid polluting Object with unnecessary methods, however, I came up with the idea of using a marker interface on the classes I wanted to have these extension methods, limiting the scope where these extra methods were visible. (No idea if anyone else has done this yet or not)

For each request and response class, in the two parallel hierarchies, my client requirements made it necessary to add an XmlRoot attribute to tell the XmlSerializer that this object was the root of an XML document and to specify the runtime name of this element. To let me get the runtime name of each request and response object, for auditing and logging purposes, both hierarchies had a CommandName property, containing the exact same code. This was the code in question that I was trying to share.

As a simple exercise, I created an extension method to deal with this:

    internal static class SssMessageExtensionMethods
    {
        public static string GetCommandNameFromXmlRootAttribute(this object message)
        {
            object[] attributes = message.GetType().GetCustomAttributes(typeof(XmlRootAttribute), true);
            if (attributes.Length == 0) return message.GetType().Name;

            XmlRootAttribute xmlRootAttribute = attributes[0] as XmlRootAttribute;

            return xmlRootAttribute.ElementName;
        }
    }

This solution worked just fine, and the code ran correctly, but I still wasn't happy with my solution. The problem I was sensing was that I was adding yet another extension method to Object, and Object's neighborhood was already pretty crowded with all the Linq methods in there. I wanted my extension methods to show up only on those classes to which I wanted to apply them.

The solution that I came up with was to use a marker interface whose sole purpose is to limit the visibility of the extension methods to classes that I intend to apply them to. In this case, I made BaseRequest and BaseResponse each implement IMessageMarker, an interface with no methods. And I changed the extension method to be:

    internal static class SssMessageExtensionMethods
    {
        public static string GetCommandNameFromXmlRootAttribute(this ISssMessageMarker message)
        {
            object[] attributes = message.GetType().GetCustomAttributes(typeof(XmlRootAttribute), true);
            if (attributes.Length == 0) return message.GetType().Name;

            XmlRootAttribute xmlRootAttribute = attributes[0] as XmlRootAttribute;

            return xmlRootAttribute.ElementName;
        }
    }

Now I have the same extension method defined, but it only appears on those classes that implement the marker.

What do you think of this technique? In a more powerful language, like Ruby or C++ (ducking and running for cover!), this kind of trickery wouldn't be needed. But C# can only get you so far, so I felt this was a good tradeoff between adding the methods for needed functionality and making the most minimal change in my classes to hide these methods so that only those places that needed them could see them.

-- bab

Using Powershell to diagnose installation failures

Brian Button — Sat, 17 Nov 2007 15:25:00 GMT

I was trying to install the Application Block Software Factory, part of Enterprise Library 3.1, the other day, and I ran into a problem. During the installation, I got a failure stating that the necessary installer types could not be found in "c:\program files\Microsoft Visual Studio 8\common7\ide\Microsoft.Practices.EnterpriseLibrary.BlockFactoryInstaller.dll". I was instructed to see the LoaderExceptions property of the exception for details.

Huh? How in the world was I supposed to see this property of an exception that I didn't even have access to?????

Powershell to the rescue

Hmmm, I thought. Based on a previous blog posting, I remember that I found a way to load an assembly from a file, and I knew that I could inspect the types in an assembly once it was loaded. Maybe I could follow this process to learn something about what was happening.

So, I fired up powershell, and typed in the following command (note that I'm at home and not at work in front of the PC where I did this. The paths are as close as I can remember...)

$assembly = [System.Reflection.Assembly]::LoadFile("c:\program files\Microsoft Visual Studio 8\common7\ide\Microsoft.Practices.EnterpriseLibrary.BlockFactoryInstaller.dll")

Once I had the assembly loaded like this, I used its GetTypes() method to inspect the types in the assembly, and that's when I got the same exception as before.

After a little investigation, I came across the $Error special variable, which seems to hold an array of the last exceptions through during powershell execution. I was able to get to the exact exception I saw at the command line through this variable by typing $Error[0].

I investigated further by using the get-member cmdlet, as

$Error[0] | get-member

which told me that the object returned from $Error[0] had an Exception property on it. I followed on a bit, and looked at the members of the exception I could get to using $Error[0].Exception. Here, it turned out, there was a property called LoaderExceptions, which was the exact property that I had been instructed to see by the error message.

Looking at that property as:

$Error[0].Exception.LoaderException[0]

gave me the exact right answer. It was looking for Microsoft.Practices.Recipes.dll, an assembly loaded by GAX, but it couldn't find it. I searched for that assembly, and I did eventually find it, but it was installed beneath Orcas, not Whidbey, both of which I had installed on my machine.

The solution

So, to make a long story short, I reinstalled GAX, this time installing it for VS.Net 2005, and all was well. I was able to install the Enterprise Library in its entirety, and I was able to proceed.

But, without the ability of powershell to let me iteratively understand what was happening, and explore the objects involved, I don't know how I would have otherwise solved this problem.

-- bab

The downside of coding alone...

Brian Button — Sat, 17 Nov 2007 15:05:00 GMT

I had what was probably an obvious insight the other day while I was working on my project alone. I'm a team of one, which kind of gets in the way when it comes to pairing. This, unfortunately, has an effect on my final code.

Good pairs are adversarial

When you find yourself pairing with someone really good, it can almost feel adversarial. What I mean by that is that you can get into a rhythm where one person writes a test, intending to lead his partner down the road of writing a particular piece of code. His partner, however, can write something entirely different that still causes the test to pass.

This back and forth dance between tester and implementer forms the basis of good micro pairing sessions. In these sessions the tester/driver intends to lead the implementer down a particular path, but the implementer has the option of following another way, forcing the test writer to write another test, trying to drive the implementer down the intended path, and so on.

This leads to particularly good code, as the code that is written is usually the least code possible to implement the functionality, and the tests that are written thoroughly cover the functionality that was intended. It's really cool to watch this work.

If you're a pair of one...

If you happen to be working by yourself, it is very difficult to simulate this tension between test authoring and application implementation. At least, from my point of view, what happens is that I do write the code I want to test to lead me to, regardless of whether or not there is a simpler way to get the test to pass. I think it is natural to do this, since you're trying to play both sides of the partnership.

I think code I write without a pair is inferior to code I create with a partner, for this exact reason. We didn't fight over the minimal implementation, which leads to still good code, but not the glory that is fully paired/TDD code.

There ain't nothing better.

-- bab

Episode 2 - Filtering by Genre

Brian Button — Mon, 05 Nov 2007 14:16:00 GMT

Update — Craig Buchek pointed out something about one of my tests that he didn’t like. My test entitled PresortedBookListWithSomeBooksInCorrectGenreOnlyReturnsBooksInCorrectGenre made an assumption about data ordering that was stronger than was necessary for the intent of the test. I didn’t need to show that the elements came out of the filtered list in sorted order for that test — I only needed to show that the elements were present in the filtered list. I’ve updated the area around that test with new content explaining the interesting lesson that Craig taught me. Thanks to Craig and all the participants on the XPSTL list.

OK, time for story number 2 —

I want to see just those books that are in a specific genre, sorted by title, so that I can survey which books I have on particular topics.

Fortunately for us, this turns out to be trivial in .Net 2.0 (Sorry, Java guys!).

First case — test for 0

As I said in the previous episode, when faced with the challenge of implementing a story that involves multiple results, follow the rule of 0, 1, many. So here is my test for getting no books back when there are no books in my genre:

[Test]
public void NoBooksReturnedWhenFilteringEmptyListOfBooksForGenre()
{
    BookListManager manager = new BookListManager();

    List<Book> filteredBookList = manager.GetBooksInGenre("Genre");

    Assert.IsEmpty(filteredBookList);
}

I puzzled a bit about the name of our new member funcction, GetBooksInGenre. Should it be FilterBooksByGenre, GetAllBooksInGenre, or any one of several other candidates? I played with each of them, trying them out for size, thinking about whether or not I liked the way the API felt. The fact that I was thinking about the API now, before I implemented the functionality, is actually pretty important. This is one of the key differences in Test Driven Development versus Test-at-the-same-time Development or Test After Development. In the latter two kinds of development, you write the code, putting a stake in the ground representing a potentially significant amount of work. It is only after the code is written that you start exercising the interface that you’ve written. In the first way, using Test Driven Development, you play with the interface first, without regard to how the code will be written, and have the opportunity to get things as best as you can now, before that stake gets planted.

So I finally settled on the API I show in the test. Let’s write enough code to make that test compile but fail:

public List<Book> GetBooksInGenre(string genre)
{
    return null;
}

and the final code:

public List<Book> GetBooksInGenre(string genre)
{
    return bookList;
}

Again, remember to watch the test fail to make sure that the test can fail, and that your code is making it pass.

Second case — test for 1

Next test is to create a list with one book in it, and that book should have the correct genre being searched for, and filter for that genre:

[Test]
public void SingleBookReturnedWhenFilteringListWithOneBookInCorrectGenre()
{
    BookListManager manager = new BookListManager();
    manager.Add(new Book("Title", "Genre"));

    List<Book> filteredBookList = manager.GetBooksInGenre("Genre");

    Assert.AreEqual(1, filteredBookList.Count);
    Assert.AreEqual("Title", filteredBookList[0].Title);
    Assert.AreEqual("Genre", filteredBookList[0].Genre);
}

OK, so first of all, this test requires a change to our Book class. Previously, Book only had a single argument to its constructor, just a title. Now it needs a genre, which is going to require a change to the Book class to make this test compile. It also needs a Genre property to allow us to test that we get the right book back.

If we start off by changing the constructor for Book directly, we’ll break other tests. What we need to do is find a way to make this change in such a way that we keep our code working and can slowly change to the new constructor. Being able to do this is a critical part of learning to write code using TDD. Each and every change we make to our code needs to made in as small sized steps as possible. This lets us stay close to working code, adding functionality quickly, and then simplifying things immediately afterwards.

The path I’d take is to ignore this new test for a moment. We wrote it, and the act of writing it informed us that we need a different signature for our constructor. So let’s create that constructor and make sure that everything still works after making that change. Once we finish that, we can go back to this test and implement the functionality it is requiring.

Step one in implementing this refactoring is to create a new constructor that takes the two arguments defined in our newest test. Change the old constructor to call the new constructor, passing in a dummy value for the genre in all cases where the old constructor is being called:

public class Book : IComparable<Book>
{
    private readonly string title;

    public Book(string title) : this(title, "Unspecified")
    {
    }

    public Book(string title, string genre)
    {
        this.title = title;
    }

    public string Title
    {
        get { return title; }
    }

    public string Genre
    {
        get { return null; }
    }

    public int CompareTo(Book other)
    {
        return title.CompareTo(other.title);
    }
}

I also created a property called Genre to let the new test compile. After making this change, all my tests still pass. It is important to note that I didn’t add anything but the absolute minimum I needed to keep the old tests working.

Do not add functionality while refactoring. Resist, resist, resist. Do not add it now, but remember to add tests to force you to add it later.

Now that we have the two constructors, we can realize that we don’t need to original constructor any more, so we can get rid of it, one call-site at a time. This is important, since we don’t have to make a big-bang change but can change one thing at a time. That’s the sign of a well executed refactoring.

Change one site, re-run tests, ensure things still work. Once you’ve found and changed all call sites, remove the old method, recompile and re-run tests. Done! Now, back to that test…

As of right now, we have the new constructor in place, as well as the empty Genre property. We run the test, the test fails. Now lets implement the code to get this test working, which only consists of adding the code behind the Genre property to the Book:

public class Book : IComparable<Book>
{
    private readonly string title;
    private readonly string genre;

    public Book(string title, string genre)
    {
        this.title = title;
        this.genre = genre;
    }

    public string Title
    {
        get { return title; }
    }

    public string Genre
    {
        get { return genre; }
    }

    public int CompareTo(Book other)
    {
        return title.CompareTo(other.title);
    }
}

I guess the case of a filtering a list of a single book wasn’t that interesting after all. Let’s write another test that tries to filter another list containing a single book, but let’s make that book have a genre different than that we’re searching for. Maybe that will cause us to write some code.

[Test]
public void NoBookReturnedWhenFilteringListWithOneBookInDifferentGenre()
{
    BookListManager manager = new BookListManager();
    manager.Add(new Book("Title", "Good"));

    List<Book> filteredBookList = manager.GetBooksInGenre("Bad");

    Assert.IsEmpty(filteredBookList);
}

Run this test, it compiles the first time, but it fails. I guess we do get to write some code…

public List<Book> GetBooksInGenre(string genre)
{
    return bookList.FindAll(delegate(Book book)
                                {
                                    return book.Genre == genre;
                                });
}

This code uses the .Net 2.0 anonymous delegate syntax that allows you to create a delegate in place and pass it as a function into the method you’re calling. What happens in the List.FindAll method is that it takes the delegate and applies it to all the elements in the collection, one at a time. In this case, if the Predicate delegate passed in executes and returns true, then the code inside the FindAll method adds the element into a new collection. Once the iteration is finished, the new list is returned to the caller.

The powerful part about doing this is that the new delegate has access to all the state that existed at the point at which it was defined. In other words, even though the delegate we’re defining is being passed as a parameter to the FindAll method and will be invoked later, in a completely different context, it still has access to the methods, members, parameters, and local variables that were in existence at the place where the delegate was defined, which is in our GetBooksInGenre method. Pretty cool, eh? It is an example of how you can create and use closures in .Net.

A bit of test refactoring before we carry on

As Book is growing larger than a single property, we’re going to find ourselves inspecting its list of properties in our tests over and over. When faced with this, I tend to create an Equals method for the object I’m manipulating in my tests. This lets me directly compare the objects in a single Assert.AreEquals. Since the Equals method is code, however, I have to write tests for it, and it usually takes several tests. Here is the code for Book.Equals:

public override bool Equals(object obj)
{
    Book other = obj as Book;
    if(other == null) return false;

    return title == other.title &&
           genre == other.genre;
}

and the completed tests for it, in the BookFixture (obviously):

[Test]
public void TwoBooksWithSameGenreAndTitleAreEqual()
{
    Book first = new Book("Title", "Genre");
    Book second = new Book("Title", "Genre");

    Assert.AreEqual(first, second);
}

[Test]
public void DifferentTitlesMakeBooksNotEqual()
{
    Book first = new Book("A", "Genre");
    Book second = new Book("B", "Genre");

    Assert.AreNotEqual(first, second);
}

[Test]
public void DifferentGenresMakeBooksNotEqual()
{
    Book first = new Book("Title", "A");
    Book second = new Book("Title", "B");

    Assert.AreNotEqual(first, second);
}

[Test]
public void NullObjectToCompareToCausesObjectsToBeUnequal()
{
    Assert.IsFalse(new Book("", "").Equals(null));
}

[Test]
public void WrongKindOfObjectPassedToEqualsCausesObjectsToBeUnequal()
{
    Assert.AreNotEqual(new Book("", ""), "");
}

I personally find an Equals method difficult to implement test first. In my standard working model, I would like to slowly build up the complete set of functionality needed to make something work. I don’t know how to do this with Equals. The problem is that it is difficult to incrementally add behavior to an Equals method and keep a set of growing tests working for it.

For example, I could have defined a test called BooksWithSameTitleCompareEqual, something like this:

[Test]
public void BooksWithSameTitleCompareEqual()
{
    Book first = new Book("A", "");
    Book second = new Book("A", "");

    Assert.AreEqual(first, second);
}

This would lead to a trivial implementation of my Equals method that just compared the titles to see if the objects were equal. Next, I’d add a test comparing the genre of books, but it would have to be crafted in such a way that the titles would be the same as well. And, in the previous test, I would have to have created the test data in such a way that the test wouldn’t break as I added code to compare the genre. My second test would have looked like this:

[Test]
public void BooksWithSameGenreAndTitleCompareEqual()
{
    Book first = new Book("A", "G");
    Book second = new Book("A", "G");

    Assert.AreEqual(first, second);
}

Note that the test has to have the intent of proving that not just the genres are equal, but that all fields we’ve written tests for up to this point are equal. So if we had 5 fields in our class, we’d have to have 5 tests, each growing by one field each time, but still having all other fields “equal” in some way, like the empty genres in my first test. This all feels very contrived and pedantic to me. What I usually do is to write a single test with all fields being equal, and write the positive test case for equality in one fell swoop. The exception to this is when calculating equality is more complex than just comparing fields. If there are loop comparisons involved or something, I will write individual tests for that.

Once this is finished, however, I do tend to write negative test cases for each, individual field, to ensure I haven’t missed something, and tests for passing null and passing the wrong kinds of objects.

That gives me 3 + n tests to write the Equals method for any class, at a minimum, where “n” is the number of fields a class has. When you’re fairly trivial Equals method is only about 5 lines long, and you’ve spent 15 minutes writing all those tests for it, you have to start thinking whether or not it was worth it. Well, my answer is that it is worth it, if you’re writing your Equals method by hand.

I prefer to let my tool generate it for me, in which case I don’t write any tests for it :)

Third case — multiple books

OK, so we’re finally at the point of handling multiple books at a time in our filtering. To get the multi case working, I think I see two separate steps. The first step is to implement filtering across multiple books, while the second step is to make sure that the filtered list is sorted by title. We should break this down into two separate tests.

In the first test, we’re going to check that we’re filtering correctly. In this test, we need to prove that we can filter the list for books having the correct genre. We are not concerned with the ordering of the books here, so we’ll just confirm that the right books are contained in the filtered list (this is the change from Craig). Here it is:

[Test]
public void PresortedBookListWithSomeBooksInCorrectGenreOnlyReturnsBooksInCorrectGenre()
{
    BookListManager manager = new BookListManager();
    Book firstMatchingBook = new Book("A", "G1");
    Book secondMatchingBook = new Book("C", "G1");
    Book nonMatchingBook = new Book("B", "G2");
    manager.Add(firstMatchingBook);
    manager.Add(nonMatchingBook);
    manager.Add(secondMatchingBook);

    List<Book> filteredBookList = manager.GetBooksInGenre("G1");

    Assert.AreEqual(2, filteredBookList.Count);
    Assert.Contains(firstMatchingBook, filteredBookList);
    Assert.Contains(secondMatchingBook, filteredBookList);
}

The trick I just learned in writing this test is that you have to be conscious of making the assertions in the test match the intent of the test as described in the name. In this case, we are intending to prove that we can filter the list, so our assertions should support this functionality exactly. They should be strong enough to confirm that this behavior is actually happening, but not so strong that they assert behavior that hasn’t been written yet. In our case, that means assertions about filtering, but none about sorting. This is why I’m using Assert.Contains in that test.

While this sounds like a tremendously good plan, unfortunately this test passed the first time I ran it. I understand why it happened — the List.FindAll(Predicate) method I called finds all elements that satisfy the predicate when called. It was the simplest way to get that particular test working, and I got the looping logic for free.

Now for the test of making sure that the filtered list I get is sorted:

[Test]
public void UnsortedBookListWithSomeBooksInCorrectGenreOnlyReturnsBooksInCorrectGenre()
{
    BookListManager manager = new BookListManager();
    Book firstMatchingBook = new Book("A", "G1");
    Book secondMatchingBook = new Book("C", "G1");
    manager.Add(secondMatchingBook);
    manager.Add(new Book("B", "G2"));
    manager.Add(firstMatchingBook);

    List<Book> filteredBookList = manager.GetBooksInGenre("G1");

    Assert.AreEqual(2, filteredBookList.Count);
    Assert.AreEqual(firstMatchingBook, filteredBookList[0]);
    Assert.AreEqual(secondMatchingBook, filteredBookList[1]);
}

All I did was the switch up the order I added the books. The output, once the functionality is implemented, should be the same as in the previous tests. I implement the functionality in BookListManager like this:

public List<Book> GetBooksInGenre(string genre)
{
    return GetSortedBookList().FindAll(delegate(Book book)
                                {
                                    return book.Genre == genre;
                                });
}

All I had to do was the pre-sort the list! I love when I can build on existing functionality. This happens a lot when you build small, fine-grained methods. You end up being able to use them in new and interesting combinations to implement new functionality easily.

Conclusion

When I sat down to write this episode, I truly thought it was going to be 2 or 3 tests, a couple hundred words, and a bit of code. When I got into it, though, I found several other tests to write, a need to write and use the Equals method for Book, and a bit of refactoring. I always find it interesting how complexity just shows up and how easily it is handled.

As an observation, you may have noticed that I have 68 lines of source code, almost all of it completely and totally trivial methods, and about 190 lines of test code. That ratio is a little skewed, because I haven’t had any really good functionality to implement, but I’m not upset about it at all. I’m certain that the 68 lines of source work, and I can continue to leverage the 190 lines of test code forever to confirm that the lines continue to work. I consider that to be an investment well worth the effort.

The next episode will add another user story to the mix. I think I’ll do the last one in the list, retrieving a list of books sorted by genre and title.

Until we meet again!

— bab

Another TDD example - Part 1

Brian Button — Sat, 03 Nov 2007 06:25:00 GMT

Title: Solution to Class Exercise

As described in class:

I have books — too many books. They are all over the floor, I trip over them. I can’t keep track of all the different books I have. I really need a book list manager. Please build one for me.

Here is the list of stories I give the students, and I ask for them in somewhat random order.

I should be able to see a list of my books, sorted alphabetically by title
I should be able to see all books in a specific genre
I should be able to read in a list of books from a text file
I need to know the current price of a book
I want to sort books according to price
I want to be able to add a new book to my list
I want to be able to save my list of books to a text file
I want to be able to mark books as having been read
I want to be able to find which books have been read
I want to sort books by genre and title

BookID  |Title                          |Genre          |HasBeenRead
1       |Clifford Goes To College       |Childrens      |Y
2       |Have Space Suit, Will Travel   |ScienceFiction |N
3       |Goedel, Escher, and Bach       |Science        |N
4       |Elegant Universe               |Science        |Y
5       |Life in 1000 AD                |History        |N
6       |1001 Ways to Cook a Cat        |Cooking        |N

Story 1 — Give me a list of books sorted by title

Most basic functionality in system. I just need to get a list of my books. I’ll invent some way to get a list of books into my system later, but for now, assume I have a list, and show them to me in some way sorted alphabetically.

I start by writing a test, being the good TDD programmer. Here is my first test:

[TestFixture]
public class BookListManagerFixture
{
    [Test]
    public void EmptyBookListReturnsNothing()
    {
        BookListManager manager = new BookListManager();

        List<Book> sortedBookList = manager.GetSortedBookList();

        Assert.IsEmpty(sortedBookList);
    }
}

This is the simplest test I can write to get the ball rolling. I’m starting to get the feel for the API, seeing how to create a BookListManager, how to talk to it, and its basic empty behavior. It’s pretty apparent to me that I’m going to be managing a list of 0 or more books. When I am presented with a problem that requires me to handle many items, I generally try to handle three cases, in this order:

0 - Let’s me get the problem set up, and get feel of the API
1 - Gets the business logic in the problem correct
many - Makes me write the looping logic for already working business logic.

And now the simple code to get the previous test to compile. I created an empty Book class. I guess I don’t strictly need a Book class yet, but this application is all about managing lists of books. I’m willing to go out on a limb to guess about a book class, but I don’t know what is in yet.

public class Book
{
}

Here is the first shot at a BookListManager. Basic, simple, doesn’t do anything yet. It exists just to fail my test.

public class BookListManager
{
    public List<Book> GetSortedBookList()
    {
        return null;   
    }
}

This leads me to implement the simplest code I can to get this test to pass:

public class BookListManager
{
    public List<Book> GetSortedBookList()
    {
        return new List<Book>();   
    }
}

Now my GetSortedBookList class returns an empty list, which allows my test to pass, trivially. An important thing to note, however, is that I’m making a statement about how my code acts when the collection it is asked to sort is empty. This behavior has to work now, it has to work tomorrow, and it has to work forever. If I were to skip writing this test, I’d always have that nagging doubt about how my system acted in this situation.

Rule — Always write tests for trivial boundary condition cases. They have to work, so they need tests. The tests are easy to write, so write ‘em!

Now the test for a single item in the list. Again, this test should be trivial, but we have to document and prove the behavior for this case, which requires a test to be written.

[Test]
public void SingleBookInListIsReturnedAsSortedList()
{
    BookListManager manager = new BookListManager();
    manager.Add(new Book());

    List<Book> sortedBookList = manager.GetSortedBookList();

    Assert.IsNotEmpty(sortedBookList);
}

So, this is a logical second test. I needed to add a book into my list somehow, and I found one of the many ways to do this. There are several ways to get the book into the system, some of them better than others. The easiest way of doing it is to just add an Add method to the BookListManager. This way, you can add new books to the list in the Arrange section of your test, putting the test data and test behavior in the same place, which is always a good thing.

The assert in this test just checks to make sure that there is something in our list of books, which is OK, but is not what I would consider to be a strong assertion. What we really mean is that there is a book, and, in fact, it is the same book as we put in. Since we’re sorting based on title, perhaps this is a good time to give a book a Title property, to allow us to assert a bit more about this solution.

    [Test]
    public void SingleBookInListIsReturnedAsSortedList()
    {
        BookListManager manager = new BookListManager();
        manager.Add(new Book("My Title"));

        List<Book> sortedBookList = manager.GetSortedBookList();

        Assert.AreEqual(1, sortedBookList.Count);
        Assert.AreEqual("My Title", sortedBookList[0].Title);
    }
}

This test is essentially the same, but it has a stronger assertion — the output list has a single element in it, and that element has the same title as the book that we put in. That’s about the strongest assertion that we can make at this point. Note that I didn’t use Assert.AreSame to ensure that the Book object put into the list and the Book object returned from the list are the same object, as that would imply an implementation decision. Eventually, I’m going to want to implement Book.Equals, so I don’t have to manually compare books by inspecting their properties.

Implementing this functionality is trivial:

public class Book
{
    private readonly string title;

    public Book(string title)
    {
        this.title = title;
    }

    public string Title
    {
        get { return title; }
    }
}

public class BookListManager
{
    private readonly List<Book> bookList = new List<Book>();

    public List<Book> GetSortedBookList()
    {
        return bookList;  
    }

    public void Add(Book book)
    {
        bookList.Add(book);
    }
}

OK, now its time for the many test. Here is my first shot at this test. Note that this is wrong, wrong, wrong.

[Test]
public void MultipleBooksAreReturnedInSortedByTitleOrder()
{
    BookListManager manager = new BookListManager();
    manager.Add(new Book("AAA"));
    manager.Add(new Book("BBB"));

    List<Book> sortedBookList = manager.GetSortedBookList();

    Assert.AreEqual(2, sortedBookList.Count);
    Assert.AreEqual("AAA", sortedBookList[0].Title);
    Assert.AreEqual("BBB", sortedBookList[1].Title);
}

This looks like a pretty reasonable test to write, and it is, save for one important detail. It won’t ever fail. Many a rookie (and experienced!) TDD’er has left out the step of watching a test fail before implementing it. In this case, this test would have passed the first time it was run. When that happens, you should immediately react by thinking, “Huh? WTF?” Tests that pass the first time should be viewed with lots and lots and lots of skepticism. In this case, we added to books to the BookListManager in pre-sorted order, so no sorting was necessary to make the test pass. Since writing the sorting behavior is an important part of the method we’re writing, and the test isn’t forcing us to write any sorting behavior at all, I’d say this was a bad test. 2 lessons to take from this:

Always watch your tests fail before implementing the logic

Care must be taken when crafting test data to have it force you down the path you need to take

Let’s try that test one more time, with better test data, and watch it fail:

    [Test]
    public void MultipleBooksAreReturnedInSortedByTitleOrder()
    {
        BookListManager manager = new BookListManager();
        manager.Add(new Book("BBB"));
        manager.Add(new Book("AAA"));

        List<Book> sortedBookList = manager.GetSortedBookList();

        Assert.AreEqual(2, sortedBookList.Count);
        Assert.AreEqual("AAA", sortedBookList[0].Title);
        Assert.AreEqual("BBB", sortedBookList[1].Title);
    }
}

There was a little bit of work necessary to get this test to pass. My first attempt was to add a bit of code to the BookListManager.Sort method:

public List<Book> GetSortedBookList()
{
    bookList.Sort();
    return bookList;
}

First of all, I hate this code. I hate for about 92 different reasons. The first is that I hate having to separate the two lines of implementation, but List.Sort() returns void. Second, and equally hateful, is that it sorts the list in place. What I would really like is List<T> List<T>.Sort(), a method that Sorts the underlying list and returns me a sorted copy of it, leaving the original list untouched. I have a feeling they made this choice because it gives me the option of copying the list first by myself or just sorting the list in place. If they did what I was suggesting, then there would be no way to sort a list in place, which may be a desired behavior in some cases. Hey, developing software is all about making choices, right? I do have a solution to the problem involves using Extension Methods from C# 3.5 that I’ll post another day.

The other thing I didn’t like about this code is that it didn’t work :( My problem is that the Sort() method requires that the objects being sorted be comparable in some way. The easiest way is to make my Book class implement IComparable, or I could create a BookComparator that implements IComparator and move this functionality outside of Book itself. I chose the former, as it seems simpler for right now. This required me to write some code in the Book class, which is a danger sign.

A fixture for one class should not force you to add code into a different class. Write a separate fixture. The first fixture describes the need, the second fixture drives the implementation.

Since I need to add functionality into the Book class, I really need a BookFixture. I’m going to comment out my original test, create the functionality I need in the BookFixture, and then return to my original test. This jumping from test to test is actually very common. Here is my BookFixture and Book code to implement IComparable:

[TestFixture]
public class BookFixture
{
    [Test]
    public void BookWithTitleBeforeSecondBookReturnsNegativeCompareToValue()
    {
        Book before = new Book("A");
        Book after = new Book("B");

        Assert.Less(before.CompareTo(after), 0);
    }

    [Test]
    public void BookWithTitleAfterSecondBookReturnsPositiveCompareToValue()
    {
        Book after = new Book("B");
        Book before = new Book("A");

        Assert.Greater(after.CompareTo(before), 0);
    }

    [Test]
    public void BooksWithSameTitleReturnZeroCompareToValue()
    {
        Book same1 = new Book("A");
        Book same2 = new Book("A");

        Assert.AreEqual(0, same1.CompareTo(same2));
    }
}

public class Book : IComparable<Book>
{
    private readonly string title;

    public Book(string title)
    {
        this.title = title;
    }

    public string Title
    {
        get { return title; }
    }

    public int CompareTo(Book other)
    {
        return title.CompareTo(other.title);
    }
}

That’s some pretty exhaustive testing! To be very honest, the second and third tests passed the first time I ran them. I kind of expected that, as I had only one line of code to write to invoke the correct CompareTo behavior for the entire class, and I wrote that to get the first test to pass. I still wrote the remaining tests, and I’d recommend that anyone else write these tests, as a way of clearly documenting the correct behavior. I have to admit that I always forget how CompareTo works with respect to which way the comparison works. I figure that if I have a problem with it, others may also, so I document the daylights out of it ;)

Now when we go babck to our original test, it works now that I’ve implemented the IComparable functionality on Book.

Here is the final BookListManagerFixture and BookListManager code to go with the BookFixture and Book classes above:

[TestFixture]
public class BookListManagerFixture
{
    [Test]
    public void EmptyBookListReturnsNothing()
    {
        BookListManager manager = new BookListManager();

        List<Book> sortedBookList = manager.GetSortedBookList();

        Assert.IsEmpty(sortedBookList);
    }

    [Test]
    public void SingleBookInListIsReturnedAsSortedList()
    {
        BookListManager manager = new BookListManager();
        manager.Add(new Book("My Title"));

        List<Book> sortedBookList = manager.GetSortedBookList();

        Assert.AreEqual(1, sortedBookList.Count);
        Assert.AreEqual("My Title", sortedBookList[0].Title);
    }

    [Test]
    public void MultipleBooksAreReturnedInSortedByTitleOrder()
    {
        BookListManager manager = new BookListManager();
        manager.Add(new Book("BBB"));
        manager.Add(new Book("AAA"));

        List<Book> sortedBookList = manager.GetSortedBookList();

        Assert.AreEqual(2, sortedBookList.Count);
        Assert.AreEqual("AAA", sortedBookList[0].Title);
        Assert.AreEqual("BBB", sortedBookList[1].Title);
    }
}

public class BookListManager
{
    private readonly List<Book> bookList = new List<Book>();

    public List<Book> GetSortedBookList()
    {
        bookList.Sort();
        return bookList;
    }

    public void Add(Book book)
    {
        bookList.Add(book);
    }
}

Next up

In the next installment, I’ll take a book list and filter it by genre. Coming soon to a theater near you :)

— bab

Slides from my powershell talk

Brian Button — Wed, 31 Oct 2007 20:30:00 GMT

I gave an introduction to Powershell talk at the St. Louis .Net UG meeting on Monday, October 29th to about 70-80 people or so. I introduced basic concepts of powershell, talked about a few problems I had solved with it, and showed some simple scripts.

At the end of the presentation, I promised to post the slides by the end of this week, and I'm making it Wednesday night. Believe me when I say that me getting something finished early is a minor miracle :)

-- bab

Finding all Attribute types in an assembly through powershell

Brian Button — Tue, 23 Oct 2007 12:57:00 GMT

I was using the new xunit.net testing framework, and I wanted to see a list of all the attributes they had. This looks like a job for Powershell!!!

[System.Reflection.Assembly]::LoadFile("pathToFile.dll").GetTypes() | where-object { $_ -match "Attribute" }

That did the trick!

-- bab

Finding installed products with uninstall instructions

Brian Button — Mon, 22 Oct 2007 20:35:00 GMT

I was repaving a machine the other day, and I had to load all my development tools. There were a bunch of them, and when I got finished, I noticed that IIS and SQL Server failed to install properly. So I uninstalled IIS and reinstalled it, no problem. SQL Server was another story.

I uninstalled it, and it only went part way. Then I tried to reinstall it, and it said it was already installed. I went around and around like this a few time, with a few reboots thrown in for good measure.

About this time, I started to google around for how to manually uinstall SQL Server. I came across a KB article on msdn.com somewhere, and it said to crawl through the registry in HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall, inspect all the GUIDs found there for those that had a DisplayName that contained SQL Server as part of it. Once I found a matching GUID, I was to use the UninstallString to manually uninstall it.

The only problem was that there were dozens of these GUIDs in there. I sure wasn't going to crawl through them all by hand.

So, what was a handy shell programmer to do? Well, I pulled out powershell and whipped up a script.


dir HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall | foreach-object {get-itemproperty $_.PSPath} | where-object {$_.DisplayName -match "SQL Server"} | select-object DisplayName,uninstallstring

Taking this script apart, piece by piece...

dir HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall lists all the registry keys beneath that location. It doesn't just spit out a string name for each item like a Unix shell would, it returns a list of RegistryKey objects. These objects are passed to the next command in the pipeline...

foreach-object {get-itemproperty $_.PSPath} is basically a for loop over each of those objects. It looks at the PSPath property of the RegistryKey objects and calls get-itemproperty on that path to return a list of registry items.

where-object {$_.DisplayName -match "SQL Server"} selects just those registry items where the DisplayName property of the registry items match "SQL Server". Finally, we clean up the output...

select-object DisplayName,uninstallstring essentially takes the objects that are passed to it from the previous pipeline stage and slices them into smaller pieces, creating a new object for each object passed to it. The new object contains just the two properties specified on the command, DisplayPath and UninstallString.

Running this command gives me this output:

DisplayName                                                 UninstallString
-----------                                                 ---------------
GDR 1406 for SQL Server Integration Services 2005 (64-bi... C:\WINDOWS\DTS9_KB932557_ENU_64\Hotfix.exe /Uninstall
GDR 1406 for SQL Server Notification Services 2005 (64-b... C:\WINDOWS\NS9_KB932557_ENU_64\Hotfix.exe /Uninstall
GDR 1406 for SQL Server Analysis Services 2005 (64-bit) ... C:\WINDOWS\OLAP9_KB932557_ENU_64\Hotfix.exe /Uninstall
GDR 1406 for SQL Server Reporting Services 2005 (64-bit)... C:\WINDOWS\RS9_KB932557_ENU_64\Hotfix.exe /Uninstall
GDR 1406 for SQL Server Database Services 2005 (64-bit) ... C:\WINDOWS\SQL9_KB932557_ENU_64\Hotfix.exe /Uninstall
GDR 1406 for SQL Server Tools and Workstation Components... C:\WINDOWS\SQLTools9_KB932557_ENU_64\Hotfix.exe /Uninstall
Microsoft SQL Server 2005 (64-bit)                          "C:\Program Files\Microsoft SQL Server\90\Setup Bootstra...
Microsoft SQL Server Setup Support Files (English)          MsiExec.exe /X{18C5A65B-0A39-40B5-B958-63055AFAB65C}
Microsoft SQL Server VSS Writer                             MsiExec.exe /I{50822200-2E95-4E62-A8D8-41C3B308DF5E}
Microsoft SQL Server 2005 Analysis Services (64-bit)        MsiExec.exe /I{54C2B4E9-DD13-4AA4-B09A-A6EF68F9359A}
Microsoft SQL Server Native Client                          MsiExec.exe /I{6E740973-8E71-42F9-A910-C18452E60450}
Microsoft SQL Server 2005 Integration Services (64-bit)     MsiExec.exe /I{8A52D844-0DA7-40B0-8602-0567C068C081}
Microsoft SQL Server 2005 Reporting Services (64-bit)       MsiExec.exe /I{BEE3EC3D-0C91-4A3E-A42C-7634D32968F4}
Microsoft SQL Server 2005 Backward compatibility            MsiExec.exe /I{C92556F2-4950-48CF-ABA3-F0026B05BCE8}
MySQL Server 5.0                                            MsiExec.exe /I{D84E063A-AE58-41AF-B6FC-313B12DC89A6}
Microsoft SQL Server 2005 Notification Services (64-bit)    MsiExec.exe /I{EA145881-7452-4004-80B9-971FC3D1D8D8}
Microsoft SQL Server 2005 (64-bit)                          MsiExec.exe /I{F14F2E25-99AF-42A9-977C-F6D0352DC59F}
Microsoft SQL Server 2005 Tools (64-bit)                    MsiExec.exe /I{FE7C8861-3195-4CA5-98EB-094652478192}

which is exactly what I wanted to find out in the first place. If I wanted to go further, I could run the uninstall command for these things automatically, but since I only had about 3 items I had to reinstall in my case, doing it by hand was no big deal.

Anyhow, consider this published so that when I need this trick next time, it will be waiting here, safe and sound, on my blog, ready for me to read again.

-- bab

Top 10 Movie List -- just for fun

Brian Button — Mon, 24 Sep 2007 16:03:00 GMT

My wife, Sharon, and I were talking about our top 10 movie list and what would be on it. The requirements were pretty simple. These had to be movies that we would generally stop what we were doing and watch together. Just because one of us like it wasn’t enough to make the list — it had to be both.

Here they, are in random order:

A Few Good Men
Field of Dreams
The Shawshank Redemption
Bull Durham
Remember the Titans
Top Gun
Back to the Future
Men In Black
Breakfast Club

No real point to this post, but I thought I’d share :)

— bab