This post is sixth in a series about a group TDD experiment to build an application in 5 days using only tests. Read the beginning here.
Today is the fifth day of our five day experiment to write an application over lunch hours using TDD. Five days was a bit ambitious, as a lot of time was spent teaching concepts, so the team agreed to tack on a few extra days just to see it all come together. So, my bad.
By the fifth day, we had all the necessary pieces to construct a graph from our NDepend xml file. Today we focused our attention on how these pieces would interact.
Next Steps
If we look back to our original flow diagram (shown below), upon receiving input from the user we need to orchestrate between loading model data from a file and converting into a Graph object so that it can be put into the UI. As we have the loading and conversion parts in place, our focus is how to receive input, perform the work and update the UI.
Within WPF and the MVVM architecture, the primary mechanism to handle input from the user is a concept known as Commanding, and commands are implemented by the ICommand interface:
namespace System.Windows.Input
{
public interface ICommand
{
bool CanExecute( object parameter );
void Execute( object parameter );
event EventHandler CanExecuteChanged;
}
}
While it’s clear that we’ll use a custom command to perform our orchestration logic, the question that remains is how we should implement it. There are several options available, and two popular MVVM choices are:
- use the DelegateCommand that ships with Microsoft’s Prism framework, or;
- an old school approach where we encapsulate the logic for the command as its own class.
The elegance of the DelegateCommand allows the user to supply delegates for the Execute and CanExecute methods, and typically these delegates live within the body of the ViewModel class. When given the choice I prefer command classes for application-level operations as it aligns well to the Single Responsibility Principle and our separation of concerns approach. (I tend to use the DelegateCommand option to perform view-centric operations such as toggling visibility of view-elements, etc.)
Writing a Test for an ICommand
As a team, we dug into writing the test for our NewProjectCommand. Assuming we’d use the ICommand interface, we stubbed in the parts we knew before we hit our first roadblock:
[TestClass]
public class NewProjectCommandTests
{
[TestMethod]
public void WhenExecutingTheCommand_DefaultScenario_ShouldShowGraphInUI()
{
var command = new NewProjectCommand();
command.Execute( null );
Assert.Fail(); // what should we assert?
}
}
Two immediate concerns arise:
First, we have a testing concern. How can we assert that the command accomplished what it needed to do? The argument supplied to the Execute command typically originates from xaml binding syntax, which we won’t need, so it's not likely that the command will take any parameters. Moreover, the Execute method doesn't have a return value, so we won't have any insight into the outcome of the method.
Our second concern is a design problem. It's clear that our command will need to associate graph-data to a ViewModel representing our user-interface, but how much information should the Command have about the ViewModel and how will the two communicate?
This is one of the parts I love about Test Driven Development. There is no separation between testing concerns and design problems because every test you write is a design choice.
Reviewing our Coupling Options
We have several options to establish the relationship between our Command and our ViewModel:
- Accessing the ViewModel through the WPF’s Application.Current;
- Making our ViewModel a Singleton;
- Create a globally available ServiceLocator that can locate the ViewModel for us;
- Pass the ViewModel to the command through Constructor Injection
- Have the Command and ViewModel communicate through an independent publisher/subscriber model
Here’s a further breakdown of those options…
Application.Current.MainWindow
The most readily available solution within WPF is to leverage the framework’s application model. You can access the top-level ViewModel with some awkward casting:
var viewModel = Application.Current.MainWindow.DataContext as MainViewModel;
I’m not a huge fan of this for many reasons:
- Overhead: the test suddenly requires additional plumbing code to initialize the WPF Application with a MainWindow bound to the proper ViewModel. This isn’t difficult to do, but it adds unwarranted complexity.
- Coupling: Any time we bind to a top-level property or object, we’re effectively limiting our ability to change that object. In this case, we’re assuming that the MainWindow will always be bound to this ViewModel; if this were to change, all downstream consumers would also need to change.
- Shared State: By consuming a static property we are effectively making the state of ViewModel shared by all tests. This adds some additional complexity to the tests to ensure that the shared-state is properly reset to a neutral form. As a consequence, it’s impossible to run the tests in parallel.
ViewModel as Singleton / ServiceLocator
This approach is a slight improvement over accessing the DataContext of the current application’s MainWindow. It eliminates the concerns surrounding configuring the WPF Application, and we gain some type-safety as we shouldn’t have to do any casting to get our ViewModel.
Despite this, Singletons like the Application.Current variety are hidden dependencies that make it difficult to understand the scope and responsibilities of an object. I tend to avoid this approach for the same reasons listed above.
Constructor Injection
Rather than having the Command reach out to static resource to obtain a reference to the ViewModel, we can use Constructor Injection to pass a reference into the Command so that it has all the resources it needs. (This is the approach we’ve been using thus far for our application, too) This approach makes sense from an API perspective as consumers of your code will be able to understand the Command’s dependencies when they try to instantiate it. The downside to this approach is additional complexity is needed to construct the command. (Hint: We’ll see this in the next post.)
This approach also eliminates the shared-state and parallelism problem but it still couples us the Command to the ViewModel. This might not be a problem if the relationship between the two objects remains fixed – for example, if the application were to adopt a multi-tabbed interface the relationship between the command and ViewModel would need to change.
Message-based Communication
The best form of loose-coupling comes from message-based communication, where the ViewModel and the Command know absolutely nothing about each other and only communicate indirectly through an intermediary broker. In this implementation, the Command would orchestrate the construction of the Graph and then publish a message through the broker. The broker, in turn, would deliver the message to a receiver that would associate the graph to the ViewModel.
Such an implementation would allow both the ViewModel and the Command implementations to be change independently as long as they both adhere to the message publish/subscription contracts. I prefer this approach for large scale applications, though it introduces a level of indirection that can be frustrating at times.
This approach would likely work well if we needed to support a multi-tabbed user interface.
Back to the Tests
Given our time constraints and our immediate needs, the team decided constructor injection was the way to go for our test.
[TestClass]
public class NewProjectCommandTests
{
[TestMethod]
public void WhenExecutingTheCommand_DefaultScenario_ShouldShowGraphInUI()
{
var viewModel = new MainViewModel();
var command = new NewProjectCommand(viewModel);
command.Execute( null );
Assert.IsNotNull( viewModel.Graph,
"Graph was not displayed to the user.");
}
}
To complete the test the team made the following realizations:
| Realization | Code Written |
| Tests are failing because Execute throws a NotImplementedException. Let’s commit a sin and get the test to pass. | Implementation:
public void Execute(object unused)
{
// hack to get the test to pass
_viewModel.Graph = new AssemblyGraph();
}
|
| Our command will need a ProjectLoader. Following guidance from the previous day, we extracted an interface and quickly added it to the constructor. | Test Code:
var viewModel = new MainViewModel();
var projectLoader = new Mock<IProjectLoader>().Object;
var command = new NewProjectCommand(
viewModel,
projectLoader);
Implementation: ///<summary>Default Constructor</summary>
public NewProjectCommand(
MainViewModel viewModel,
IProjectLoader projectLoader)
{
_viewModel = viewModel;
_projectLoader = projectLoader;
}
|
| We should only construct the graph if we get data from the loader.
(Fortunately, moq will automatically return non-null for IEnumerable types, so our tests pass accidentally) |
Implementation:
public void Execute(object unused)
{
IEnumerable<ProjectAssembly> model
= _projectLoader.Load();
if (model != null)
{
_viewModel.Graph = new AssemblyGraph();
}
}
|
| We’ll need a GraphBuilder to convert our model data into a graph for our viewmodel. Following some obvious implementation, we’ll add the GraphBuilder to the constructor.
A few minor changes and our test passes. |
Test Code:
var viewModel = new MainViewModel();
var projectLoader = new Mock<IProjectLoader>();
var graphBuilder = new GraphBuilder();
var command = new NewProjectCommand(
viewModel,
projectLoader,
graphBuilder);
Implementation: public void Execute(object unused)
{
IEnumerable<ProjectAssemby> model
= _projectLoader.Load();
if (model != null)
{
_viewModel.Graph =
_graphBuilder.BuildGraph( model );
}
}
|
| Building upon our findings from the previous days, we recognize our coupling to the GraphBuilder and we recognize that we should probably write some tests that demonstrate that the NewProjectCommand can handle failures from both the IProjectLoader and GraphBuilder dependencies. But rather than extract an interface for the GraphBuilder, we decide that we’d simply make the BuildGraph method virtual instead – just to show we can. Only now, when we run the test the test fails. It seems our graph was not created? |
Test Code:
var viewModel = new MainViewModel();
var projectLoader = new Mock<IProjectLoader>().Object;
var graphBuilder = new Mock<GraphBuilder>().Object;
var command = new NewProjectCommand(
viewModel,
projectLoader,
graphBuilder);
// ...
|
Finally, in order to get our test to pass, we need to configure the mock for our GraphBuilder to construct a Graph. The final test (shown below) looks like this. Note the IsAnyModel is a handy shortcut for simplifiying Moq’s matcher syntax.
[TestClass]
public class NewProjectCommandTests
{
[TestMethod]
public void WhenExecutingTheCommand_DefaultScenario_ShouldShowGraphInUI()
{
// ARRANGE: setup dependencies
var viewModel = new MainViewModel();
var projectLoader = new Mock<IProjectLoader>().Object;
var graphBuilder = new Mock<GraphBuilder>().Object;
// Initialize subject under test
var command = new NewProjectCommand(
viewModel,
projectLoader,
graphBuilder);
Mock.Get(graphBuilder)
.Setup( g => g.BuildGraph( IsAnyModel() ))
.Returns( new AssemblyGraph() );
// ACT: Execute our Command
command.Execute( null );
// ARRANGE: Verify that the command executed correctly
Assert.IsNotNull( viewModel.Graph,
"Graph was not displayed to the user.");
}
private IEnumerable<ProjectAssembly> IsAnyModel()
{
return It.IsAny<IEnumerable<ProjectAssembly>>();
}
}
Of course, we’d need a few additional tests:
- When the project loader or graph builder throw an exception.
- When the project loader doesn’t load a project, the graph should not be changed
- When the Command is created incorrectly, such as null arguments
Next: Day Six
