« February 2008 | Main | April 2008 »

March 24, 2008

Unit Testing User Interfaces - Introduction

You may have caught my last series in which I looked at six different patterns for organising view logic in a Flex client. In this series I'm going to take the demonstration applications for three of those patterns and look at the changes required to effectively unit test them. The aim of the exercise is to gain an insight into how amenable each pattern is to unit testing and hopefully wrestle with some common unit testing challenges along the way.

What is unit testing?

This isn't an introduction to unit testing or a tutorial on how to get started with unit testing. So if you're asking this question you may want to have a look at some of the links below. The test tool of choice for this series is Flex Unit as it is the one we use on our consulting projects. There are others out there, so feel free to shop around.

• Unit testing and Test Driven Development (TDD) for Flex and ActionScript 3.0
• How to use FlexUnit with FlexBuilder 2
• FlexUnit Basics
• The lost FlexUnit documentation
• FlexUnit articles in the Flex Cookbook

The plan

When looking at Presentation Patterns I started with the simplest pattern to implement, but for this series I'm going to start with the pattern that I believe will be simplest to unit test. So here's the order of business:

1. Presentation Model
2. Supervising Presenter
3. Autonomous View

Why test view logic?

Applying a unit testing strategy to your user interface logic can have more than one advantage:

• Helps uncover defects early - This is the obvious one, unit testing should help you detect bugs as you develop your code. It won't detect every bug, but it should provide an extra line of defence.
• Facilitates refactoring - Refactoring is something of a buzzword these days and you're far more likely to hear people talking about refactoring their code than unit testing it. Refactoring is a structured technique for reducing duplication and redundancy in your code, but without automated unit tests it can also be a great way to add defects.
• Helps to communicate intent - Unit tests can help to describe the intended behaviour of a class. This is of particular importance in team-based software development, or for applications with long maintenance phases. Code commenting and technical documentation are still often favoured over unit testing, but it is debatable whether these are more reliable than a comprehensive suite of unit tests.
• Increases the focus on architecture - Adopting a unit test strategy forces you to think more about the architecture of your application. Perhaps most significantly, the need to test each class in isolation of its collaborators encourages a developer to code against interfaces rather than concrete classes. You're also likely to see fewer global singletons and law of demeter violations in a unit tested application because of the increased emphasis on modularity.

Is this Test Driven Development?

Test Driven Development (TDD) or test-first development is a development practice in which unit tests are written before the code they test. The advantage of TDD is that the test is seen to fail before the code is written, and the code is then written to make the test pass. I'm not following a TDD approach in these entries because the applications I'm testing have already been written.

In my next entry I'll take a look at unit testing my Presentation Model example.

Posted by paulw at 01:25 PM | Comments (0) | TrackBack