How we approached WinRT, solution structure and unit testing

I’ve written about a few of the things we’ve implemented in our Windows 8 app but not much about how we actually structured our code or how we approached unit testing.

First thing to say is we are an agile team committed to code quality.  Although the Windows 8 application is not part of our core product code it is still important for it to be maintainable.

The next is we’re developing it in C#.  We had a discussion about whether or not to use HTML and Javascript.  We went for C# because our team had more experience and we thought it would be easier and quicker to develop the application.  Although we did spike using NodeJS to test the Javascript, stubbing our WinRT dependencies.

The thing to remember with Windows 8 development is WinRT isn’t .Net.  From C# it looks and smells like .net but it isn’t.  So you might think the path to least resistance is to use MSTest and test the WinRT code (given your favourite testing framework might not have been ported / portabled yet).  We spent a day trying to get those tests running from build scripts and on our build server and it is far from easy.  We managed to get it working outside of Team City but when you run it from the build agent it complains about non-interactive users (to get this working on Windows Server 2012 you need to hack the registry), then about running as an administrator (again we tried hacking the registry to change the user the service runs under when an in interactive mode but to no avail).  We can change the way Team City hosts its build agent to not be a windows service but we didn’t like that.  We found a better alternative, don’t use MSTest.  (If I have the heart I’ll write about all this in more detail…)

We can actually test the vast majority of our code in .Net if we use portable libraries.  I’d liken this to Silverlight development, you could test using the Silverlight test runner but you’d rather not.  We do still have WinRT specific tests but we only run them locally.  As you’ll see they only test adapters.

So rather than just explain our assembly structure (WinRT Tests  -> WinRT -> Portable <- .Net 4 Tests) let’s walk through an example.  The next post shows how we implemented a non re-entrant dispatcher timer to keep our app up to date.  It is a good example because it’s a simple concept and shows the dependency inversion on WinRT specific APIs not available inside Portable libraries.


About Tom Peplow

C# .Net developer based in London and the South Coast
This entry was posted in Uncategorized and tagged . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s