One of the biggest issues with UI tests described at the task level (such as click there, type this etc) is that they are very brittle and hard to understand. Too many details in technical steps make it hard to see the big picture, so tests work nicely as a regression check but once something fails it is hard to figure out what exactly went wrong. They are also bound to a particular UI design, so when the design changes, lots of tests break. Selenium works on the technical task level and tests written for Selenium frequently fall into this black whole. Once the design is changed, you might as well do everything again from scratch.

Instead of writing tests at the technical task level, the Page Object pattern suggests creating one more level of indirection and describing business functionality of pages with objects (eg search for customers, submit registration form) and then implementing individual methods of these objects with Selenium. Tests are then written with the page object methods, which make them much more understandable and easier to maintain. Once the UI changes, we can reimplement only the relevant methods of Page Objects making the effects of changes relatively contained. Tests themselves don’t need to change. Similar ideas are implemented by xUseCase recorders and Domain-Specific Testing Languages in Selenium (see Mickey Phoenix’s Agile 2008 presentation).

Marcano said that page objects focus on the wrong thing. Taking ideas from interaction design, he suggested that it is natural to think about functionality on three levels — goals, activities and tasks:

1. Goal: Buy a book
2. Activities: Add the following items to the cart,…
3. Tasks: click search, type in book name, click book image, click Add to cart…

When thinking about web site functionality, people don’t think about pages but about activities that span multiple pages. Focusing on goal oriented cross-page activities instead of page oriented functionality makes tests more natural, easier to understand and maintain. Instead of Page Objects, Marcano suggested implementing activities with Selenium and then composing tests from activities. One more significant benefit of this approach is that activities aren’t baked into the user interface, unlike objects representing web pages, so the same test definitions can be kept for testing below the UI with different task implementations.

• MVC approach in general helps a lot to make web UIs testable as it allows us to test lots of things below the surface of the UI efficiently, including the controller workflow, and just roll back transactions to make tests repeatable
• Comperensive testing above the UI surface (eg through web automation tools) often doesn’t pay off as scripts take too much time to execute and maintain.
• Automation of stuff below the surface leaves us with more time to do exploratory testing, but some basic automated tests still make sense to do through the web ui as well (eg face saving tests)
• Rather than testing the formatting through the UI, a better approach is to move complex formatting away from view templates into helper classes which can be unit tested. This also reduce the stuff you need to test through the Web surface.

ASP.NET MVC specific ideas

• The default (web forms) view engine allows you to put arbitrary code in the view, but view rendering cannot be easily unit tested, so this requires discipline and ensuring that view pages contain only display and formatting code. Going back to the one of already mentioned ideas, complex formatting should be moved to helper classes and not be in the view page as well.
• ASP.NET MVC doesn’t really provide any special support for unit testing out of the box. There is no equivalent to Monorail’s test HTTP contexts. You can still mock out HTTP objects yourself. However, controller methods that don’t depend on HTTP contexts or sessions can be easily unit tested as normal classes.
• Using helpers to generate forms makes views more resilient to change as routes are automatically generated based on class properties. So when you refactor controller method names, form targets and properties get updated automatically.
• Similar approach in the controllers is to use the ExpressionHelper from the optional extension package Micrososft.Web.MVC, which enables us to get calculate routes with a lambda expression, generating the URL for a particular action. Using this rather than hard-coding strings makes controllers more resilient to change, as lambda expressions are strongly typed and refactoring friendly.
• Although IView has the render method with a Writer argument, because the default WebForms view engine is using HttpContext.Current it ignores the writer and cannot be mocked out. Other view engines do make use of the TextWriter so the view output could be captured for testing purposes from a unit test.
• The MVC contrib package has some more additional tools to test routes from unit test tools.

We did manage to put together a very simple web application that demonstrates some of these techniques during the workshop, and you can download the source code for that from the Open space code subversion repository.

I really enjoyed participating in the Openspace Code workshops and I’m really looking forward to the next one. Apparently, they are going to be organised every two months. Here are some links to other write-ups:

• Alan Dean
• Rob Cooper
• Chris O’Dell
• Jamie Thomson

Photo by Alan Dean

Download Powerpoint slides from here.

• Selenium-core: selenium-core.openqa.org/
• Selenium-Remote Control: selenium-rc.openqa.org/
• Selenium-IDE: selenium-ide.openqa.org/
• Selenium-Grid: selenium-grid.openqa.org/
• Domain-specific testing languages presentation from Agile 2008 by Mickey Phoenix from Solutions IQ: www.solutionsiq.com/agile2008/agile-2008-domain.php
• StoryTestIQ: storytestiq.solutionsiq.com
• Cubic Test: www.cubictest.com
• WebTest Fixtures: fitnesse.info/webtest

Ivan Sanchez will put his slides online at www.isanchez.net.