Christofer Löf

Portable Class Library and ICommand

2012-03-13T20:48:00+01:00

Unit testing

A while ago I wrote an article describing how the Portable Class Library can enable us to write Unit Tests for our Windows Phone apps using the tools and frameworks we’re already familiar with. By adding an abstraction layer and using types common to the Base Class Library, Portable Class Library and Windows Phone we can write unit tests using tools like MSTest and Moq.

View Models & ICommand

A popular approach for writing Windows Phone apps is to use the Model-View-ViewModel pattern and by that expose operations on the View Model as commands which can be data bound to buttons on the view. The interface which enables commands, ICommand, isn’t available in the Portable Class Library thus exposing that kind of commands from our PCL View Models isn’t possible. In my earlier article I demonstrated how we can return concrete instances using factories but that requires a common known interface or base class. In the case of commands – ICommand is supposed to be that common interface – but since it’s not available in the PCL we need another abstraction. By exposing the command as Object on the View Model would enable the same approach as previously shown using Factories – but hey – how fun would that be? Not much.

Download

Sample solution

BindingConverter to the rescue

Instead we can implement a BindingConverter which allow us to dispatch the invocation of a command to a method on the View Model. So far this approach seems to work really well and when giving this solution a second thought I really believe it improved the architecture by separating the concerns even further – the view specific ICommand is no longer part of the model library.

<Button 
   Content="Button text" 
   Command="{ Binding 
      Converter={ StaticResource CommandConverter }, 
      ConverterParameter='ViewModelMethodName' }" 
   CommandParameter="MethodParameter" />

Button.xml

Thanks to Johan Lindfors who initiated this discussion.

Visual Studio “11”

Today I learnt that Visual Studio “11” Beta has support for ICommand when targeting Windows Phone, SilverLight, Metro and .NET 4.5. Pure awesomeness.

Unit testing Windows Phone 7 apps

2011-08-14T20:50:00+01:00

The Portable Library Tool is the key ingredient in enabling Visual Studio integrated unit testing of Windows Phone 7 apps. This article will demonstrate how to get started and a technique in managing the required dependencies between the projects.

What’s this all about?

Unit testing is in itself a big topic with lots of opinions on how and reasons for why and why not. I will not dig into the why part further than stating – I do it on my WP7 apps to ensure that I didn’t break anything. Until now I used to use my own testing framework – which is now, thanks to the introduction of the Portable Library Tools, kind of obsolete.

Portable Library Tools is a new Visual Studio add-in from Microsoft which enables you to create C# and Visual Basic libraries that run on a variety of .NET-based platforms without recompilation, including Windows Phone. This enables us to create a Visual Studio project containing the phone agnostic code and reference it from both a phone project and a test project. But since the portable library doesn’t know about phone specifics we may need to make them available to the library at runtime through patterns like Dependency Injection , Service Locator and Factory.

I can finally throw away my home brewed unit test fx!
— Christofer Löf

Getting started

In order to get started – the first thing would be to make sure you’ve the Portable Library Tools installed. They’re easy to find and install through the Extensions Manager in Visual Studio. When installed you should have a new project type called Portable Class Library available in the new project wizard. Then you’ll need three projects in your solution; The phone app-, the portable library- and the test- project. The phone app project and the test project should both have a reference to the portable library project.

In my first example I’m writing a very simple test just to make sure that the project setup works as intended – a calculator with an Add method. The calculator class is created within the library project and an unit test that simply invokes the Add method is created within the test project. Also I invoke the Add method from the phone app just to create a baseline knowing that the project setup is OK.

Green lights!

Model-View-ViewModel-what?

Two of the drivers behind the Model-View-ViewModel (MVVM) pattern are testability and code reuse. By extracting the ViewModels from the phone project into the portable library project you will be able to test them and reuse them with ease.

For this next example I create a phone app that’s implementing the MVVM pattern by choosing the Databound Application template in the new project wizard. The template will create two simple view-models and tie them to their views. The next thing would be for me to move the view-models to the library project.

So far this portable library journey has been friction free. When moving the just created view-models to the library project the first perceived problem arise – Visual Studio complains about the type ObservableCollection. That’s because ObservableCollection live in the System.Windows assembly which isn’t referenced by the portable library project. If I remove the .NET Fx 4 target from the portable library project – I would be able to reference System.Windows but I wouldn’t be able to reference the portable library project from the test project since the portable library project then would be a SilverLight only library.

I’m not changing the target setting because in this case I want to unit test my app. I wrote perceived above just to state that this really isn’t a big problem. The principle to solve the ObservableCollection challenge is the same as it would’ve been for the phone’s NavigationService class for instance. There’re things in the phone part of the framework that you probably need to consume in the view-models. The best way to gain access to phone specifics, like ObservableCollection and NavigationService, would be to fulfill the dependency inversion principle.

In order to create an abstraction layer I need to change the type of the members that are returning ObservableCollection to a type that’s known by all my projects and exposes the functionality needed. That type would be IList<T> in this case. The next thing I need is something that can provide me with an instance of ObservableCollection at runtime – since I can’t instantiate it in the view-model. Furthermore I need an instance of something that implements the above defined contract during test execution. This is the part where more choices and opinions about how to provide instances at runtime arise. There’re a couple of libraries and guidance out there which could prescribe how and aid me in wiring up the dependency injection. But for the simplicity of this example I chose not to bring in an external framework like that. A simple Factory will solve this for now.

The base implementation of the ListFactory will return instances of List<T> , which satisfies the above contract and is available on all targeted platforms. All I need to do is to make sure that the factory is instantiated before the tests run. In the phone project I add a new factory class which derives from the ListFactory base class and overrides the CreateList method in order to return an instance of ObservableCollection instead. The ObservableListFactory is instantiated once in my phone project’s App class and it will hold a reference to itself thru the Current property. With this approach I will be provided a list implementation that’s compatible with the current execution context.

Wrapping it up

Splitting up your Windows Phone app in two projects – the phone app project and a portable library project – should be your pattern of choice if you want to unit test your implementation.

Libraries and guidance for MVVM

Caliburn Micro
MVVM Light
Prism

Is MVVM and unit testing suitable for all WP7 projects?
It certainly adds complexity to your application implementation but one great benefit you’ll get from it is confidence – knowing that you didn’t break anything from release 1 to release 2. The path I usually take is to first create some kind of Proof of Concept of the app in mind in order to validate the overall idea and to run a few iterations on the end user experience. When I believe in the overall I start to refactor my way into the patterns and practices described in this article.
In the end it’s the end-user experience that matters.

Download

Sample solution

Driver's log for Windows Phone 7

2011-03-12T09:05:00+01:00

Driver's log is a simple application for Windows Phone 7 which helps you keep track of mileage and expenses while on the road.

As a consultant I travel quite a lot by car. By the end of every month I need to fill in our corporate Excel spreadsheet with my mileage and send it to payroll in order to get reimbursed.

When I received by HTC Mozart a couple of weeks ago I immediately felt the urge to develop for it and get to know the platform. So I thought for myself – why not smash two birds with the same stone and learn something while I build something that I need?

Said and done – I named the application “Driver’s log”. It allows me (and you, since it’s available on the Marketplace) to keep track of my travels and car mileage and associated expenses like gas and parking. By the end of the month I export my log through e-mail and then easily copies the entries from the e-mail into the form my manager expects. (“Convince manager to accept Driver’s log export format” is on my to-do list). This saves me some time but more important – since it’s fast and easy – it ensures that I really report all trips and by the end of the day it means that I get accurately reimbursed (money saved).

So how did I implement Driver’s log?
On the framework side I took a dependency on Caliburn.Micro to do proper unit testing with VFx. Caliburn brings – among other things – Windows Phone API abstractions, Dependency Injection Container and Messaging to the table. This allowed me to clearly separate the Phone UI and Phone specific services from the core of the Driver’s log application – a necessity for unit testing the model outside of the emulator.
I also took a dependency on the Silverlight Toolkit. It provides Driver’s log with nice date pickers and touch effects.

At the time of writing this Driver’s log is at version 1.2. I have a few more things on my list that I want to implement. Besides from them I want to hear from you. Please post your questions, concerns, requests, criticism, praise and ideas in the comments section below.

WP7 Testing Extravaganza!

2010-11-06T16:40:00+01:00

Writing an Unit and Integration Test framework for Windows Phone 7 Silverlight isn't hard once you got hold of all moving parts. The Victoria Framework helps me to successfully Unit Test my Windows Phone 7 applications without deploying to the emulator.

During my paternity leave this summer I had some moments which I could spend on coding-for-fun. Like a whole lot of others these days I began to write a couple of Windows Phone 7 apps. Among the first things I looked into was the availability of testing frameworks especially suited for Windows Phone developement. Back then I found one – the silverlight toolkit unit testing framework. It’s an impressive piece of work. But in my humble opinion it lacks, currently, two major features. The first feature is; execute unit test outside of the emulator or the device i.e. on your computer.

For a TDD style of development having to deploy to the emulator to execute one test just eats too much of my precious time. I’ve understood that the APIs of the Silverlight Unit Test Framework are compatible with the VSTest APIs so linking files between projects would probably be one way to execute the tests on the development machine. But that would force me to create shadow projects to link files and execute the tests outside from the Silverlight runtime – I don’t want that. The second feature I believe the Silverlight Testing Framework is lacking, which I really thought was there, is support for UI tests.

So. When you’re a guy who likes to write frameworks and has some spare time. What do you do? You roll your own testing framework of course!

Unit Tests

The amount of code that is required to execute tests within the Silverlight runtime from a console app isn’t too many. The number of moving parts within the solution are a few more though. The console app hosts a Browser control. The source URL of the WebBrowser control is set to a static HTML page (the RunnerPage) which hosts the generated xap file. The console app calls a JavaScript function in the HTML page using the InvokeScript method of the Browser control. The JavaScript in the HTML page executes the TestRunner within the xap package by calling a method exposed by the Silverlight JavaScript Bridge. The key parts here are the two different JavaScript bridges exposed by the WebBrowser control and by Silverlight.

The console app creates the xap package on the fly by examining the Package folder and include all assemblies found in there. The resulting xap is copied to the Content folder, where the RunnerPage expects it to be.

Writing the Unit Tests is as simple as you might expect. Create a Windows Phone 7 class library, add your tests and mark them with the Fact attribute.

To run the tests you have to copy the test assembly to the Package folder as previously described. To do that you could set up post build events in Visual Studio or just write a simple script to handle the copying and executing of tests for you. I’m currently using my new best friend psake to handle all that for me. It allows me to just write .\test.ps1 in a PowerShell in order to build and unit test my apps.

[Fact]
public void should_set_id_on_save() {
    
    var item = new TodoItem();
    
    TodoItem.Add(item);
    TodoItem.SaveChanges();

    Assert.True(item.Id!=null);
}

TodoItemTests.cs

UI Tests

[Fact]
public void should_create_todo() {
    Page("/CreatePage.xaml").Ready(p => {
        p   .Find<TextBox>("TitleTextBox")
            .SetText("New Todo");
        p   .Find<Button>("CreateButton")
            .Click();
        p   .Find<TextBox>("IdTextBox")
            .WaitForText(text => 

        Assert.True(text!=null));
    });
}

TodoTests.cs

The UI test (or Integration tests as I call them in the Framework) functionality is at this point very immature. My goal here is to run the UI using the Silverlight Automation APIs. For the basic controls like Buttons and TextBoxes this isn’t a problem. But for the ApplicationBar, for instance, it’s harder because that control isn’t a Silverlight Control and hence it lacks automation support. I believe the UI test support in the framework will be a mix of Silverlight Automation and a pinch of reflection magic by relying on some naming conventions. (It’s true – it really will be magic. Promise.)

Lately I’ve used the Lightweight Test Automation Framework by the ASP.NET QA team in a bunch of projects and I really like the APIs it provides for writing tests. So it’s not a coincidence that the VFx integration test APIs reminds you of LTAF.

#if INTEGRATIONTEST
    RunIntegrationTests();
#endif

App.xaml.cs

The UI tests are run with the same runner as the unit tests. Currently the tests have to live in the app they are testing and the runner is executed by defining the INTEGRATIONTEST compilation symbol. This is clearly something I want to change in the future.

Download

The framework, which I call the Victoria Framework or just VFx, is hosted at github.

Context/Specification enhetstester

2010-09-05T21:46:00+01:00

Context/Specification är en alternativ stil att skriva enhetstester enligt. Stilen kan vara ett verktyg i arbetet med att reda ut en komplex flora av enhetstester, samtidigt som den kan ge en tydligare koppling till kravställningen.

Majoriteten av alla enhetstester skrivs sannolikt enligt den så kallade Arrange-Act-Assert stilen. Stilen går ut på att först etablera scenen för vad som skall utspela sig ( Arrange ), därefter utförs handlingen ( Act ), för att till sist försäkra sig om att det gick som man hade föreställt sig ( Assert ). Detta sker vanligen inom ramen för en testmetod. Att hålla allt som rör ett testfall inom en testmetod kan initialt ses som klart fördelaktigt då man anser att det blir enkelt och läsbart.

I takt med att antalet tester ökar ökar också kraven på att testerna är minst lika underhållsvänliga och läsbara som den kod de avser att testa. Nu och då träffar jag utvecklare som anser enhetstester bidrar till fler problem istället för att avhjälpa eller förhindra dem.

public void ServiceReturnsFooTest() {           
   //arrange
   var service = new FooService();
   //act
   var result = service.Foo();
   //assert
   Assert.AreEqual("Foo", result);
}

basic-arrange-act-assert.cs

Testerna går sönder för lätt när systemet under test förändras. När vi skall reparera testerna vet ingen riktigt vad de faktiskt testar – de är för komplexa.
Eftersom vi inte riktigt förstår testerna så litar vi inte på dem. Oftast är allt grönt. Ibland är några tester röda utan någon känd anledning.
Skall vi lyckas med enhetstester känns det som vi behöver tester som testar testerna.
— Frustrerad utvecklare

Att testerna går sönder lätt kan bero på flera saker. Ett vanligt problem är att testerna är överspecificerade och använder mockramverk allt för intensivt för att simulera interna beroenden. När testerna väl går sönder, eller behöver justeras av andra anledningar, så gäller det som alltid att få ställen har påverkats och därmed behöver ändras. Det handlar helt enkelt om att minimera duplicerad kod i testerna. Det är inte alls ovanligt att två tester har snarlika eller rent av samma arrange och act block för att sedan bara skilja sig åt i assert blocket.

För att snabbt förstå vad ett test verifierar så bör namnet på testet vara tydligt samt att antalet asserts hålls så nära ett som möjligt. Detta för att slippa titta i testet för att möjligen förstå vad det faktiskt avser att testa. Ett BazTest med tre asserts är ett exempel på ett otydligt testfall.

I många fall vill man försäkra sig om att flera förändringar har skett i tillståndet av systemet under test och då krävs flera assert uttryck. Så snart fler asserts introduceras till en testmetod blir frågan snart vad det är som faktiskt försäkras och testas? För att tydliggöra det så ger man möjligen testmetoden ett långt fint namn eller kryddar på med kommentarer i testmetoden. Men vad man då fortfarande går miste om är den visualisering som resultatet av en testsvit faktiskt kan ge. Om en assert av fyra i ett testfall inte går igenom – vad innebär egentligen det? Vad är det som inte fungerar? Vissa saker fungerar uppenbarligen eftersom tre asserts accepterades. Borde inte resultatet bli halvgrönt åtminstone? Frågorna kan bli många. Kanske måste man till och med debugga testfallet för att verkligen få reda på vad som inte fungerar som planerat.

//arrange for test 1
var repository = new Mock<IFooRepository>();
.. a few lines of mock setup goes here ..
var service = new FooService(repository);

//arrange for test 2
var repository = new Mock<IFooRepository>();
.. here comes the mock setup again ..
var service = new FooService(repository);

dupe-arranges.cs

public void BazTest() {
   //arrange
   var service = new FooService();           
   //act
   var result = service.Baz();

   //we need some asserts.. right?
   Assert.IsNotNull(result);   
   Assert.IsTrue(result.Succeeded);
   Assert.AreEqual("42", result.TheMessage);
}

multiple-asserts.cs

Tydligare tester

Context/Specification stilen kan hjälpa dig skriva stabilare och tydligare tester genom att på ett naturligt sätt bryta ut arrange och act blocken samt att hålla nere antal asserts till en per testmetod. Stilen innebär dock att varje arrange (i detta fall kallad sammanhang eller context) får en egen dedikerad klass vilket till en början kan uppfattas som överflödigt.

Genom att gruppera klasser i varandra och möjligheten till att ärva ett sammanhang från ett annat sammanhang gör att man snart ändrar uppfattning om att många klasser skulle vara ett problem.

För att anamma Context/Specification stilen behövs en basklass som testfallen ärver från. Basklassen, vilken förslagsvis kallas ContextSpecification, exponerar tre metoder som testfallet kan överrida och därmed nyttja.

Metoden Context motsvarar arrange blocket – det vill säga här etableras sammanhanget och scenen för systemet under test riggas upp. Because innehåller troligen endast en rad kod – den rad som förändrar tillståndet i systemet under test. Tänk varför förändras tillståndet? Jo – därför… så har du en förklaring till namnvalet. Båda dessa metoder anropas i basklassen i en metod som är märkt med attributet TestInitialize (Varierar beroende på val av testramverk). Det innebär att metoderna Context och Because exekveras innan varje testmetod för att på så vis återställa sammanhanget och tillståndet till dess utgångspunkt för att sedan exekvera testet.

Varje testmetod innehåller endast ett assert-uttryck som försäkrar att resultatet av tillståndsförändringen är vad som förväntas.

[TestClass]
public class when_foo_is_invoked : ContextSpecification {

   protected FooService    Service;
   protected string        Result;
   
   //"arrange"
   protected override void Context() {
       var repository = new Mock<IFooRepository>();
       .. mock setup code goes here ..
       Service = new FooService(repository);
   }

   //"act"
   protected override void Because() {
       Result = Service.Foo();
   }

   //"assert"
   [TestMethod]
   public void should_return_foo() {
       Assert.AreEqual(expected: "Foo", actual: Result);
   }
}

basic-context-spec.cs

Ökad återanvändbarhet

Den riktiga styrkan med Context/Specification stilen är som tidigare nämnt dess enkelhet att ärvas och återanvändas.

En tjänst som skapar kontakter tar emot ett meddelande innehållandes kontaktens förnamn, efternamn och e-postadress. Samtliga dessa egenskaper är obligatoriska för att en ny kontakt skall få sparas ned i systemet. I det fall någon av de nämnda egenskaperna på kontakten inte uppfyller valideringsreglerna blir svaret på meddelandet false.

För att testa alla kombinationer i detta scenario med arrange-act-assert stilen är det lätt hänt att duplicerad kod skapas genom tre testmetoder vilka innehåller snarlika arrange block samt identiska act och assert block.

Med Context/Specification stilen skapas i detta fall en basklass för sammanhanget där alla kontaktens egenskaper initieras till ett godkänt värde. För varje egenskap på meddelandet skapas ytterligare en klass som ärver från grundsammanhanget och som endast justerar aktuell egenskap till ett otillåtet värde. På så vis kan en testsvit skapas med god täckningsgrad, god läsbarhet och god underhållbarhet. Notera hur ett arrange block (i form av Context) och en Assert resulterar i tre testfall (testmetoden är del av basklassen when_validating_contact).

public class when_validating_contact : ContextSpecification {

   protected ContactService    Service;
   protected bool              Result;
   protected Contact           Contact;

   protected override void Context() {
           
       Service = new ContactService();
       //initialize the contact with known and valid values
       Contact = new Contact {
           Email       = "e-mail",
           FirstName   = "fist-name",
           LastName    = "last-name"
       };
   }

   protected override void Because() {
       Result = Service.Validate(Contact);
   }

   [TestClass]
   public class with_empty_email : when_validating_contact {
       protected override void Context() {
           base.Context();
           //set email to an invalid value
           Contact.Email = string.Empty;
        }
   }

   [TestClass]
   public class with_empty_firstname : when_validating_contact {
       protected override void Context() {
           base.Context();
           //set firstname to an invalid value
           Contact.FirstName = string.Empty;
       }
   }

   [TestClass]
   public class with_empty_lastname : when_validating_contact {
       protected override void Context() {
           base.Context();
           //set lastname to an invalid value
           Contact.LastName = string.Empty;
       }
   }

   //note - this test method is part of the base class
   [TestMethod]
   public void should_not_be_valid() {
       Assert.IsFalse(Result);
   }
}

adv-context-spec.cs

Koppling till kravställning

Ordet specification används istället för ordet test för att skapa en tydligare upplevelse av ett det är exekverbara specifikationer som skapas. Själv ser jag en klar fördel med att åtminstone använda ett språk i namngivning av contexts och specifications som ligger så nära som möjligt det språk som används av kunden i dess kravställning och kommunikation. Man tenderar då få tester (specifikationer) som tydliggör varför klasser finns och hur deras beteende associerar till kundens önskemål. Att gruppera testfallen efter feature eller user story kan stärka spårbarheten ytterligare.

when_validating_contact+with_empty_name.should_not_be_valid är enligt min mening ett mer tydligt testresultat än BazTest. Kanske förstår också din kund vad som faktiskt fungerar av det hon efterfrågar.

Christofer Löf

Portable Class Library and ICommand

Unit testing

View Models & ICommand

Download

BindingConverter to the rescue

Visual Studio “11”

Unit testing Windows Phone 7 apps

What’s this all about?

Read more about patterns

Getting started

Model-View-ViewModel-what?

Wrapping it up

Libraries and guidance for MVVM

Download

Driver's log for Windows Phone 7

WP7 Testing Extravaganza!

Unit Tests

UI Tests

Download

Context/Specification enhetstester

Tydligare tester

Ökad återanvändbarhet

Koppling till kravställning