Morse Coder Part 5 : Unit Testing with the Microsoft Unit Test Framework

How do we know that our Morse Code Translation Logic is working correctly? This is where Unit Tests prove to be a valuable tool to have in our toolkit. There are a number of Test Frameworks available, NUnit, XUnit, etc. Given that we’re using PCLs targeting Universal Apps, our choices are limited slightly at this stage, so for simplicity and speed of getting up and running we can use the Libraries and Test projects bundled with Visual Studio. There’s masses of documentation and blog posts around Unit Testing and Test Driven Development (TDD) so I won’t go into the why’s here, but if you’re new to the concept I would recommend you read The Three Rules of TDD by Robert C Martin (Uncle Bob).

(If we were following strict TDD, these tests would have been written before we created the translators, but we’ll look past that for now!)


By the end of this post we will have the basis of a test suite to build on over time. Unit Testing is a standard practice across the industry and is an important aspect of nearly all Projects. We should be able to:

  • Instantiate our Translator Classes, feed in some Input, and ‘Assert’ that the Output is as expected over a variety of scenarios and test cases;
  • Be able to build our Test Project, find and run our Tests from Visual Studio.


  • Morse Coder Part 4
  • Ideally a rough understanding of the benefits of Unit Testing, though I’m sure it will become apparent!


Let’s dive in and create a Unit Test Project. We’ll be targeting Windows in this example, but we could equally use the Windows Phone based Project.

Create a Project in the usual manner, Visual C# > Store Apps > Windows Apps > Unit Test Library (Windows) and call it something sensible, I went for MorseCoder.Windows.Test.

Create Unit Test Library in Visual Studio
Create Unit Test Library in Visual Studio

So we’ve got somewhere to write and run our tests from. Let’s think about what we actually want to test. We translate both to and from Morse Code, it follows that we will want to have test classes to exercise both of these translations, so lets create a couple of classes:

  • AlphabetToMorseTranslatorTests;
  • MorseToAlphabetTranslatorTests.

We’ll start with AlphabetToMorseTranslatorTests, let’s think of the simplest scenarios it will need to handle, bearing in mind that Unit Testing is as much about exercising edge cases as it is in dealing with the expected (never underestimate the ability of users to break your application!). At simplest, our translator needs to :

  • Translate Single Character In our Dictionary;
  • Translate Single Character Not In our Dictionary.

so lets create a couple of methods accordingly :

public class AlphabetToMorseTranslatorTests
public void TranslateSingleCharacter_InDictionary()


public void TranslateSingleCharacter_NotInDictionary()


Note the test attributes we’ve added there, they are part of the Microsoft.VisualStudio.TestPlatform.UnitTestFramework namespace and decorate our methods to flag them as Unit Tests. It should be fairly self explanatory what they mean but TestClass can be viewed as a collection of ‘normally’ related unit tests and TestMethod signals a Unit Test.

Building this and opening the Test Explorer window will give us access to the following :

Test Explorer Test Discovery in Visual Studio
Test Explorer Test Discovery

We can see that it’s picked up our newly created (empty) unit tests and clicking run will run them, at this stage they’ll ‘pass’ as no Assertion (or otherwise,) Exception has been thrown.

Let’s think about what a Unit Test actually entails :

  • We need to have access to an instance of the object we are looking to test (set up of this can elegantly be put in a test fixture if we have commonality between tests);
  • We need to understand what we are expecting to happen;
  • We need to carry out an action;
  • We need to Assert that our Expected Result matches our Actual.

With this in mind, let’s add the following :

public class AlphabetToMorseTranslatorTests
public void TranslateSingleCharacter_InDictionary()
ITranslator translator =new AlphabetToMorseTranslator();

var expected =”.- “;

var actual = translator.Translate(“A”);

Assert.AreEqual(expected, actual);

public void TranslateSingleCharacter_NotInDictionary()

Note the additional code added to the second test TranslateSingleCharacter_NotInDictionary(), we’ve not written this test and therefore have no test coverage, let’s force a fail so we don’t forget about it! On Building and Running our tests we now have one Passing (Green) and one failing (Red). Completing our other test (and adding a bunch more!) will give us some confidence that the translator classes are working as intended under various scenarios. I won’t go into further unit tests here but the above covers a really simple pattern to follow and build upon.

Test Explorer in Visual Studio


Where are we?

  • We’ve got a Unit Test Project in the solution that allows us to Build and Run our Unit Test Suite to give us confidence that the functionality that we create is behaving as we expect it to.

Where are we heading?

  • The next in the series will look at dealing with Application Settings in Universal Apps.

1 thought on “Morse Coder Part 5 : Unit Testing with the Microsoft Unit Test Framework”

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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s