Chapter 24. Unit Testing Apps

Unit testing saves time and helps to find defects early in the development cycle. Unit tests become assets that provide assurance that further development or refactoring has not broken something. The more tests you create, the more confidence you have when adding features and fixing bugs. This is especially true if you are working with a team of developers.

Manual ad hoc testing becomes less effective as an app increases in size and complexity. Having a solid suite of unit tests can actually decrease the time it takes to get your app to the marketplace. This is because often an exorbitant amount of time is spent on ad hoc testing in the last stages of development before a release.

Another benefit of unit tests is that they can act as a tacit form of documentation. There is a distinct lack of code documentation in many software houses today. Unit tests can assist a developer in understanding how an app works, and unit tests are less susceptible than traditional system documentation to implementation drift, where design changes and feature creep can see the documentation of an app become outdated. Unit tests tend to fare better because they are verifiable. Relying solely on unit tests to document a system is, however, not wise. Unit tests should be considered production code, requiring their own adequate documentation.

For all its benefits, unit testing does have a cost. It takes time and skill to write effective unit tests. In your career, you may have experienced the reluctance of management to support unit testing because it is invariably seen as time stolen from writing product code. It is that old story: developers craft a product and then scramble in the last moments to iron out defects, producing fixes that frequently introduce new bugs. Unit testing can help to alleviate that last-minute scramble.

Some may also see unit tests as a liability because when there are substantial changes to an app, unit tests have to be rewritten. This cost is, however, usually overstated and can sometimes reflect unsound development practices.

Testing and patterns of testing vary, and divided opinion on the topic has spurred many a heated debate. This chapter is not about affirming one approach over another. The techniques and tools presented in this chapter should, however, make a worthy addition to your development toolbox.

Throughout this book you have seen the use of the Model-View-ViewModel (MVVM) pattern. MVVM comes into its own when combined with unit testing. In fact, it is one of the key motivations for using the pattern. MVVM allows you to separate UI technology-specific code so that it can be tested without a user interface (UI).

This chapter delves into the Windows Phone Toolkit Unit Test Framework (UTF). The chapter begins with a walk-through of the creation of a unit test project from scratch. You see how to create test classes and test methods, and get to know the tag expressions editor, which provides a useful mechanism for selecting which tests are to be run.

The UTF is then explored more deeply by creating a simple chat client app, in which you see how to verify a viewmodel before creating a user interface. Following the creation of the view, the test suite is extended to include code driven UI tests, where we manipulate the user interface, simulating button clicks and other user actions from a unit test. The chapter illustrates how to perform asynchronous testing and touches on the Microsoft Automation framework.

Some advanced topics, such as Inversion of Control (IoC) and mocking, are also discussed, and you learn how to use a custom IoC container.

Finally, we put it all together to see how to perform testing of trial applications and how to hide or reveal content based on a mock licensing service. You then look at a custom API for mocking launchers and choosers.

There is a lot to cover in this chapter, and the tools and techniques presented here can help spot unintended side effects, increase the robustness of code, assist in focusing the development effort, and perhaps, save you some time.