Discussions on software engineering

Tag Archives: WPF

One of the great advantage of the MVVM pattern is that it allows you to test the Graphic User Interface logic of the application through the view models. The latter ones are in charge of ‘presenting’ the data to your screen controls, the so-called views. For a very short introduction to MVVM, I recommend this article. This post is the last one of the series on the WPF/MVVM and it deals with the organization of the view model unit tests in a large project. I have written a blog post on how MVVM can let you test some part of your logic that you might not have thought possible before. The present blog post does not aim at presenting ‘how’ you write unit test but rather at presenting a way to organize the numerous unit tests.

When you implement unit tests for view models, you must test end-user actions. For example, you will implement test assertions for the click command on a button. Unit test should be organized so that when they fail you can easily find out the user action or presentation status of the data that you are testing. To this aim, we will use a structure of unit tests that use extensively class inheritance. Although, MSTest is not know to be the best framework for tests with inheritance, it remains the framework that I use. I do believe that one can find an even more elegant approach with other tests framework. The approach presented here is mine, I do not pretend this is the best one, it is just an example of an organization that have proven to work in large projects.

The mocking framework used is Moq. A mocking framework is not 100% mandatory for TDD. However, anytime I saw a C# project that was not using a mocking framework, then the unit tests were not really unit tests. Sometimes they were badly written and were not asserting relevant stuff and sometimes they were more or less integration tests.

Let us get back to our organization of view model tests: the basic idea is taken from the book Professional Test Driven Development in C#. I recommend it if you are unfamiliar with unit testing. It is one of the best reference that I found on the subject of TDD. It contains many relevant real life examples.

This is the base class that all view model unit test class should inherit. I acknowledge that there are virtual calls in constructor, this not a very neat pattern. But as you probably know, C# defers from Java and C++ and the virtual call will always call the most derived class implementation of a virtual method, even in constructors.

Another thing that you must know: for each unit test execution, a new instance of the class is created, even if the tests belongs to the same test class. Consequently, we get a well test isolation without even use [TestInitialize] [TestCleanup] [ClassInitialize] attributes.

Let us go back to our Specification class, you remarked that it is abstract. To continue the organization, for each view model, you create a directory under the ViewModels directory of the test project. In this directory, create a new abstract class derived from the Specification class. This will be the base class for all test of a given view model we prefix this base class by ‘General’, e.g. for a view model called AdminViewModel, we created GeneralAdminViewModelTests class.

In this GeneralAdminViewModelTests, we instanciate the System Under Test (SUT), in this example: AdminViewModel. It is assigned to a protected field with the same name, this is the only ‘true’ implementation. The role of this GeneralAdminViewModelTest, is to pass the dependencies, that can be other view model (parent view models) or other services. The dependencies are “fresh” mock object, without any setup. The configuration of the setups depends on their usage, which will be precised in the ‘true’ derived child test class, to this aim we declare a protected abstract method SetupMocks. There is a big benefit of performing the instanciation of the SUT in one base class. Indeed, whenever you’ll add or remove a dependencies you will have just this base class implementation to change. This would have been a tedious operation if the SUT were instanciated in multiple places.

Personally, I did not managed to use one fake implementation for all tests and inject them using a IoC container. Actually, when you write unit tests you always need a different behavior of you mock depending on the test specification. For example, if you have an IoService that abstracts usage of disk I/O operation, sometimes you will want to fake a failure, an exception throwage etc. Therefore, my approach is to setups the mocks only with the behavior required for the tests. However, it is possible to factorize your mocks configuration, by using some ‘Usual Mocks’ setups.

Let us detail the true implementation of unit tests. You must separate your tests according to “existing” configurations. In my example, the AdminViewModel must deal with two situations (among others): when there are some existing data (called matters) and when there are none. That is why, under the AdminViewModelTests directory we created two files “WhenThereAreThreeMatters.cs” and “WhenThereAreNoMatter.cs”. See the resulting tree file structure in picture below.

An example of view model test organization for the ‘AdminViewModel’

Once again, the trick is to play with inheritance. A the top of the file, we declare once again a base class. That will be the mother class of all test class in this file. In this situation, we will setup the mocks so that they fake the existence of three matters in the database.

Once the mocks are setup, we can implement the true tests class, that act as the specification of the view models. They are the most derived class (they could be marked as sealed), they are decorated with the [TestClass] attributes and the [TestMethod] attiribute for the tests. In the code listing below, there are two examples. First the WhenNothingIsDone, that will assert the following facts: when nothing is done, there are still three matters displayed, the view model is not ‘dirty’ (no changes from the end-user) and that is still possible to delete a matter. Then we have another class, that will test the behavior of our AdminViewModel, when there are ThreeExistingMatters: when we click Delete (on a matters) then, there are only two matters displayed and the view model is dirty. You may think, of others TestClass, asserting behavior of this view model under these circumstances, for example, you may Assert what is going on when the end-user clicks Save (after clicking Delete) etc.

Remark that we needed more setups for the mock in the WhenDeletingMatters implementation, so it is possible to override the the SetupMocks method to add some behavior to the mock. See examples in C# code listing below.

Finally, one particularly helpful trick is to use the folder Namespacing conventions. Remark that a feature from Resharper enables you to enforce this convention for all files in a given folder, the current project and even the whole solution. Then our class WhenDeletingAMatter has for complete name .ViewModels.AdminViewModelTests.WhenThereAreThreeMatters.WhenDeletingAMatter. In your Resharper Test Session or VisualStudio TestExplorer, you can select ‘group by namespaces’, then you have a very neat a readable organization of your unit test as shown in the screenshot below.

When selecting the option ‘GroupByNamespaces’ then the readability of the test organization becomes very clear

This is the first post of a series in three parts where I will discuss what are the “must have” of any of my WPF/MVVM projects. This one is about dealing with design time data with the framework MVVM light. The sample project of this post can be found here on my github.

When we speak of design time data in a WPF project, we refer to the data that will be visible in the Visual Studio designer. In the picture below the data displayed have no reason to be related to production or any testing dataset. They serve the only purpose of designing your app. It is important to be aware that the Visual Studio designer is extremely powerful and is able to execute some of the .NET code of your app. I have noticed also that the VS WPF designer have improved a lot with VS 2012.

Visual Studio 2013 designer

Why having design time data is ABSOLUTELY mandatory?
First, some controls do not need data to be designed. Take a Button for example, its Content (the label) is probably static then you will not have any troubles designing it. On the contrary, if you take the DataGrid in the screenshot above, the rows are dynamic data so you won’t be able to see some lines in your VS designer unless you specify some design time data.

Now let me tell you a story. I learnt WPF because I was affected to an Excel addin project that had been started two years before. The screens had been developed using WPF but without any pattern, only (spaghetti) code behind. In addition to the fact that nothing was testable and the business logic was tightly coupled to the presentation, there was no design time data for the WPF screens. Sometimes, in order to view the effect of a single border color modification, the developer had to start the addin, connect some web services, fetch (potentially large) data etc… All of this was dramatic in term of efficiency. A complete reskin of the application was not even thinkable. Let me conclude this argumentation by saying that some data are not easily produced with a test dataset. For example, if you have a Textblock displaying a path on your hardrive. You would like to see if it is still ok if this path becomes very long. If you do not have design time data, you will have to create such a deep folder hierarchy in your drive, only to see the behavior of your TextBlock control style. This is a pity, using design time data, you may insert any string in the control in less than a second.

How do you do that in practice with an MVVM project?
We are going to take a very simple sample project (that can be found here). This application is a window with two tabs to display some information about book authors. You can select the author with a Combobox. On the first tab, there is basic information about the author while on the second tab there is the list of the books written by this author. Implementing this with MVVM: you will have three views (.xaml files): one the main window, two for the tabs.

In my WPF apps, all view models are specified through interfaces. Then, for the sample project, we have the three following interfaces: IMainViewModel, ISummaryTabViewModel and IBooksWrittenTabViewModel.ISummaryTabViewModel and IBooksWrittenTabViewModel are “sub view models”. Naturally, they are exposed as member of the IMainViewModel.

For each view model there are two implementations: the production implementation and the design implementation. I like to separate in another namespace the design time implementations to avoid “solution explorer visual pollution”.

Visual Studio Solution Explorer with Design ViewModels

We use a ViewModelLocator so that the views can find the appropriate implementation of the view model interface. Typically, the ViewModelLocator exposes a static property for the “top” rooted view model.

In the sample above, I kept the IoC Ninject container (the _kernel field). You may ignore this but the ViewModelLocator is the composition root of the application, this is where an IoC Container should be used, see this post for more information.

All the magic lies in the if statement ViewModelBase.IsInDesignModeStatic which is provided by the amazing MVVM Light Framework developed by Laurent Bugnion. It will detect if the call to the ViewModelLocator comes from the Visual Studio Designer or if the application is truly running.

If you create a multi lang app with the approach detailed in one of my previous posts you can change within the if(ViewModelBase.IsInDesignModeStatic) scope the CurrentUICulture to design and see your app with any supported languages.

Now the ViewModelLocator is manipulated in the views as follows
In MainWindow.xaml

When implementing the “Design” view models it is important to avoid implementing any business logic. If the fake data are incoherent between the several view models design implementations that should not trouble you either. To conclude, in a real app, you will probably have to create design implementation not only for the view models but also for the objects used in data bindings (e.g. the interface IBook).

This is the end of the first part of the WPF/MVVM “must have” series. The second article will deal with the organization of the unit tests of an MVVM application.

In this post I will describe a solution for easy localized strings management in XAML or C#. Precisely, we will use the usual recommended material for manipulating localized strings in .NET: resx files and the ResourceManager class. However, for XAML manipulation, we will add a “type layer” on top of this. We will see that having typed resources can be very useful. The “type layer” is basically an interface where string properties contain the localized strings, then in XAML or C# code the translations are accessed by using directly these properties. To avoid painful repetitions, the implementation of the interface is dynamically generated using some very simple MSIL. To conclude, we will write simple unit tests that check that the translation files (.resx) contains all the localized strings for all supported languages.

First, let us recall that it is really important that your localized strings are not dispersed in the source code of your application. Using a code snippet of the following form is a bad practice.

Indeed, it is very important that you keep grouped all the translations for a given language in one file. Then, you could rework your translations on your own or with a professional without having to grep the entire code base.

Fortunately, .NET comes with all the material you need to handle Culture-Specific resources with the ResourceManager. Say you support english (default) and french languages then you have two .resx files which contains key/value string entries. Such files are named LocalizedStrings.resx and LocalizedStrings.fr-FR.resx they may contain, among others, the entry SayHello (“Hello!” in english and “Bonjour !” in french). Finally, you only have to initialize the ResourceManager and getting the localized strings as follows.

It is important to note that the right file (*.resx or *.fr-FR.resx) is automatically chosen using the Tread.CurrentThread.CurrentUICulture.

When manipulating XAML for the UI of your app, creating a type for the localized string is recommended. Indeed, in XAML you can bind to properties but you cannot (at least not easily) bind to methods. So the recommended method from the MSDN is to create a LocalizedStrings class whose members are the localized strings.

Using this “type layer” is not only mandatory for XAML it is also very useful because we benefit from the static typing. Indeed, typing help us to create localized strings list that do not contain tons on unused entries. Even if this is not a matter of life or death, it is a good thing to remove unused localized strings from your dictionaries, because they going to cost you some effort or money when you will make new languages available or if you want to review the terminology used in your application. The only thing you have to do is to search for unused member of the class (the plugin Resharper does this well even in XAML).

As shown in the image below the XAML-intellisense of Resharper shows us all members of the interface which is handy to reuse localized strings.

The plugins resharper shows all properties of the LocalizedStrings class

Still there is one thing which is cumbersome, every-time you create a new entry you have to type the same logic for the property: _rem.GetString(“NameOfTheProperty”). Then, it’s time to be nerdy and find a way to do this automatically! Let us replace the LocalizedStrings class by and interface ILocalizedStrings whose implementation is dynamically generated. You can emit dynamically new type in .NET using the ILGenerator. So this is the implementation of the new StringLocalizer with some help from the .NET IL guru Olivier Guimbal.

To conclude let us write unit tests to ensure that all properties in the interface ILocalizedStrings are defined on all .resx files and, reciprocally, to make sure that all keys in the resx files are properties of the interface. This will help us to track non translated entries and to remove useless keys in the resx dictionaries. We basically parse the .resx files to retrieve all keys and use reflexion to get all public properties of the interface. The test fail when problematic entries are discovered and printed in the test console.

In this post we will describe how to create a searchable list with WPF following MVVM principles. To this aim we will use a WPF ListView to display the searched items and a TextBox to enter the text used for the search. Most of the implementation that you will find on the web (e.g. this one) will recommend you to bind your ListView to an ICollectionView. However, this is not 100% satisfactory as long as ICollectionView does not have a built-in generic version. Consequently the ViewModel’s member exposing the binding items will return an ICollectionView which is a powerful object (see this for instance) but is “only” an enumeration of System.Object. In this post we will show you that a generic version can be easily implemented and exposed by your ViewModel.

In this post we will create a very simple app that let you search a player in the list of all the players of the last Football World Cup in Brazil. The complete source code can be found on my Github here.

Searching ‘dav’ in the ListView display a list of results starting with ex Chelsea’s player David Luis…

The key ingredients of such implementation is very simple in MVVM. First take the View which does not need more than the few lines of xaml below.

As I said in the introduction, this is quite enoying. You may want to create screens with many ICollectionView bindings that may contain different types, then it is becoming error prone and we are loosing the benefit of C#’s type safety. The unit test example below is showing you that the elements need to be casted while they are accessed from the ICollectionView.

In addition we cannot use anymore the XAML validation and intellisense provided by Resharper.

Resharper complaining because of the unknown’s member of the DataContext (typed as object)

Fortunately we can create our generic version of ICollectionView and get back to the comfortable world of type safety. In this example, I will only provide the generic enumeration and the generic version for the SourceCollection member but you can add others. Indeed, you may create a generic version of the Filter predicate to avoid dealing with System.Object in your lambdas but with your generic type T instead.

I recently had a discussion with a friend about the Model-View-ViewModel pattern (MVVM) for UI apps and the fact that it allows unit testing where you would not have thought it possible in the first place, for example, logic involved by drag and drop. We agreed on the fact that most of MVVM posts are very theoretical regarding MVVM and when they are not, the testing part, is only mentioned never detailed. That is why I decided to write this concrete post focusing as much as possible on the testing topic.

The objective of this post is to detail the code architecture and the techniques involved to the testing of a very simple WPF app. This app enables the user to rank via drag and drop the list of the french football clubs and save this ranking. This could be a part of larger app that could be used, for example, to bet the final table… However for the sake of simplicity of this post we will focus mainly on the WPF control ListView containing the football club rows. The source code can be found in this github repository.

List view control displaying the football clubs that can be reorganized by drag and drop. The order can be saved.

We will use an external library that wraps all the complex events handling regarding the mouse action involved in the drag and drop. Following unit testing principles, we will only test our logic which will be the movement of elements in the collection the ListView is bound to. In order to add little bit of extra complexity, we would like to allow not only the movement of one row but also of a block of contiguous rows.

There are tons of blog posts and articles on theoretical description of MVVM written by brilliant developers so I will try to be as brief as possible and will focus more on the example. The fundamental and natural principle on which MVVM and other UI pattern are based on is to separate the UI from the business logic. In one sentence, the application logic should not be tied to UI elements. The Model/View/ViewModel comes in three parts as well summarized in this blog

A view is simply a UI page. It does not know where the data is coming from.

A ViewModel holds a certain shape of data, and commands, that a View binds to.

The model refers to the actual business data, which is used to populate the ViewModels.

The basic interaction rules can be summarized in the drawing below.

MVVM interactions overview

Speaking more in term of WPF, the view contains the UserControls, the windows. A view class definition is split between the xaml file (simplifying UI design) and the associate .cs file called code behind. If an application is coded following MVVM principles the code behind should be small, containing code on the UI elements that are difficult to expressed with XAML syntax (e.g. keyboard bindings).

Now it is time, to present the external tools that we are going to use in this small app. The drag and drop mouse interaction will be handled by the open source project GongWPF. For unit testing we will use the Visual Studio Test framework and Moq for creating mock objects. For a real and more sophisticated app written with MVVM, I would recommend you to use a framework. Personally, I do like MVVMLight.

Let us describe the code of our app starting by the so-called model part. This is a natural way because, in real scenarios this may be existing parts, written before ever considering the UI. However, in this fake app it is going to be very simple. The main business interface is IFootballClub exposing three properties regarding the club.

The core model is represented by the interface IChampionship. It is extremely lightweight in our situation because, in this post, we want to focus more on the View/ViewModel interaction. However, we have added the property CurrentChampionShipRanking and GetGoodBetCount as examples of methods that could be put in the model.

Let us now present the interface for our ViewModel, IChampionshipViewModel, which is the most important part of this blog post. Therefore, it will be the only interface where we provide the implementation. This implementation will handle the drag and drop core logic and will be the system under test for our matter. The list of football clubs will be kept in the FootballClubs observable collection. This collection handles natively all the notifications for the view. The Save action will be handled by the SaveClick property whose type is ICommand. An ICommand is an interface for an action that can be executed.

Remark also that IChampionshipViewModel extends IDropTarget which is the main interface provided by GongWPF for handling the drag and drop events. This interface contains two methods void DragOver(IDropInfo dropInfo) and void Drop(IDropInfo dropInfo)

To complete the overview let us present the xaml for our view. Indeed, following MVVM principles, our custom UserControl is essentially XAML leaving no code behind. The most important part is the binding of the View to the ViewModel via the DataContext property. In our case, we have used a ViewModelLocator (a very simple one with no IoC container) see this post for more information on the ViewModelLocator pattern. Naturally, the ListViewItemsSource (the list of rows) is bound to the FootballClubs property of the IChampionshipViewModel interface. For each column, we can bind to a property of the interface IFootballClub. Note also, that the Resharper AddIn enables intellisense and type validation of those bindings which is really valuable for early detection of errors.

Finally, the ListView control has the following GongWPF attributes:dd:DragDrop.IsDragSource=”True”, dd:DragDrop.IsDropTarget=”True”, dd:DragDrop.DropHandler=”{Binding}”

Thanks to these attributes, GongWPF will be able to make a bridge between the mouse UI events and the methods of the IDropTarget interface which our ViewModel extends.

Unfortunately, as brilliant as it is, GongWPF does not do everything and its our responsibility to implement the logic that moves the elements within the ObservableCollectionFootballClubs.

Following the TDD principles let us write tests first. But before that, let us have a glimpse at our SUT (system under test) which is the class ChampionshipBetViewModel. The model IChampionship is injected as a constructor parameter. We will not discuss further the SaveClick part but we use a custom implementation of the ICommand interface which basically execute the lambda expression passed as parameter. This Action typed lambda updates our model with the reranked list of football clubs.

Here comes our first unit test. I think it is a good thing when a test can expressed in term of a simple sentence such as “Given… When … Then…”. Logically, the test method name should be closed to this sentence. The first one will assert that ” given a list of four rows when the the source is the first row and the target is the second one then the list of row should be reordered“. Remark that the target (the InsertIndex in GongWPF API) corresponds to the row instance preceding the inserted item. Being clear with this convention, the GongWPF interfaces are easily mocked using Moq, resulting in the following unit test. We assert that after executing the Drop method the list is club2, club1, club3, club4

For having a proper case coverage it is also important to assert “negative” situations such as the following one “given a list of four rows, if the source is the block containing the two last rows and the target is the second one then the drop action should not change the order”

Remind, that we have for specification to be able to move a block of contiguous rows at once but we do not want to move two discontinuous blocks. Therefore, the DragOver method should handle properly this situation: the styling that allows insertion should be set in the first situation and not set at all in the second one. To assert this with unit tests, we use the VerifySet methods on the mock object dropInfo. For both properties DropTargetAdorner and Effects, we verify they are set when the selected items forms a contiguous block and not set when the two selected rows are not adjacent. If those conditions are not met the tests would fail, indeed, Moq framework would throw exceptions.

We finish this post by showing the true implementation of the ViewModel. We do not provide the details of the method MoveAllLeft and MoveAllRight they can be found on the github (they probably can be reviewed and shortened) .

To conclude, we have shown the basic ingredients for the testing of a ViewModel, this tests suite can be extended to complete a strong code coverage (there are many corner cases in our situation). Not also, that the MVVM pattern allows you to test the command, for example the SaveClick. Thanks to the Moq VerifySet method, you can check that the setter on the UserBet property for the mock Mock<IChampionship> is called (see project on github).