Following up on the series of posts on Legacy Projects, my legacy project with no tests now has a build server with empty coverage data. At this point, it's really quite tempting to start refactoring my code, adding in tests as I go, but that approach is slightly ahead of the cart.
Although Tests for the backend code would help, they can't necessarily guarantee that everything will work correctly. To be fair, the only real guarantee for the backend code would be to write Tests for the existing code and then begin to refactor both Tests and code. This turns out to be a very time consuming endeavour as you'll end up writing the Tests twice. In addition, I'm working with the assumption that my code is filled with static methods with tight-coupling which doesn't lend itself well to testing. I'm going to need a crowbar to fix that, and that'll come later.
It helps to approach the problem by looking at the current manual process as a form of unit testing. It's worked well up to this point, but because it's done by hand it's a very time consuming process that is prone to error and subjective of the user performing the tests. The biggest downfall of the current process is that when the going get's tough, we are more likely to miss details. In his book, Test Driven Development by Example, Kent Beck refers to manual testing as "test as a verb", where we test by evaluating aspects of the system. What we need to do is turn this into "test as a noun" where the test is a "procedure to evaluate" in an automated fashion. By automating the process, we eliminate most of the human related problems and save a bundle of time.
For legacy projects, the best place automation starting point is to test the user interface, which isn't the norm for TDD projects. In a typical TDD project, user interface testing tends to appear casually late in the project (if it appears at all), often because the site is incomplete and the user interface is a very volatile place; UI tests are often seen as too brittle. However, for a legacy project the opposite is true: the site is already up and running and the user interface is relatively stable; it's more likely that any change we make to the backend systems will break the user interface.
There is some debate on the topic of where this testing should take place. Some organizations, especially those where the Quality Assurance team is separated from the development teams, rely on automated testing suites such as Empirix (recently acquired by Oracle) to perform functional and performance tests. These are powerful (and expensive) tools, but in my opinion are too late in the development cycle -- you want to catch minor bugs before they are released to QA, otherwise you'll incur an additional bug-fix development cycle. Ideally, you should integrate UI testing into your build cycle using tools that your development team is familiar with. And if you can incorporate your QA team into the development cycle to help write the tests, you're more likely to have a successful automated UI testing practice.
Of the user interface testing frameworks that integrate nicely with our build scripts, two favourites come to mind: Selenium and WaitN.
Using Selenium
Selenium is a java-based powerhouse whose key strengths are platform and browser diversity, and it's extremely scalable. Like most java-based solutions, it's a hodge-podge of individual components that you cobble together to suit your needs; it may seem really complex, but it's a really smart design. At its core, Selenium Core is a set of JavaScript files that manipulate the DOM. The most common element is known as Selenium Remote-Control, which is a server-component that can act as a message-broker/proxy-server/browser-hook that can magically insert the Selenium JavaScript into any site -- it's an insanely-wicked-evil-genius solution to overcoming cross-domain scripting issues. Because Selenium RC is written in Java, it can live on any machine, which allows you to target Linux, Mac and PC browsers. The scalability feature is accomplished using Selenium Grid, which is a server-component that can proxy requests to multiple Selenium RC machines -- you simply change your tests to target the URL of the grid server. Selenium's only Achilles' heel is that SSL support requires some additional effort.
A Selenium test that targets the Selenium RC looks something like this:
[Test]
public void CanPerformSeleniumSearch()
{
ISelenium browser = new DefaultSelenium("localhost",4444, "*iexplore", "http://www.google.com");
browser.Start();
browser.Open("/");
browser.Type("q", "Selenium RC");
browser.Click("btnG");
string body = browser.GetBodyText();
Assert.IsTrue(body.Contains("Selenium"));
browser.Stop();
}
The above code instantiates a new session against the Selenium RC service running on port 4444. You'll have to launch the service from a command prompt, or configure it to run as a service. There are lots of options. The best way to get up to speed is to simply follow their tutorial...
Selenium has a FireFox extension, Selenium IDE, that can be used to record browser actions into Selenese.
Using WatiN
WatiN is a .NET port of the java equivalent WatiR. Although it's currently limited to Internet Explorer on Windows (version 2.0 will target FireFox), it has an easy entry-path and a simple API.
The following WatiN sample is a rehash of the Selenium example. Confession: both samples are directly from the provided documentation...
[Test]
public void CanPerformWatiNSearch()
{
using (IE ie = new IE("http://www.google.com"))
{
ie.TextField(Find.ByName("q")).TypeText("WatiN");
ie.Button(Find.ByName("btnG")).Click();
Assert.IsTrue(ie.ContainsText("WaitN");
}
}
As WatiN is a browser hook, its API contains exposes the option to tap directly into the browser through Interop. You may find it considerably more responsive than Selenium because the requests are marshaled via windows calls instead of HTTP commands. Though there is a caveat to performance: WatiN expects a Single Threaded Apartment model in order to operate, so you may have to adjust your runtime configuration.
WatiN also has a standalone application, WatiN Recorder, that can capture browser activity in C# code.
UI Testing Strategy Tips
Rather than writing an exhaustive set of regression tests, here's my approach:
- Start Small: Begin by writing coarse UI tests that demonstrate simple functionality. For example, a test that hits the homepage and validates that there aren't any 500 errors. Writing complex tests that validate specific HTML markup take longer to produce and often tend to be brittle and less maintainable in the long run.
- Map out and test functional areas: Identify the key functional elements of the site that QA would normally regression test for a build: login, update a profile, add items to a shopping cart, checkout, search, etc. Some of these will be definite road-blockers that you'll have to work around -- you'll quickly realize you can't guarantee profile-ids and passwords between environments, or maybe your product catalog changes too frequently. Some will require creative thinking, others may inspire custom testing tools that can perform test-specific queries or functions. You may even find a missing need in the backend systems that you could build and leverage as part of your tests.
- Write tests for functional changes: You don't need to sit down an write an exhaustive site wide regression fixture -- focus on the areas that you touch. If you write tests before you make any changes you can use these tests to help automate the debugging process. The development effort is relatively small -- you have to test it anyway a dozen times by hand.
- Write tests for testing bugs!!!: What better motivation could you have? This is what regression testing is all about!
- Design for different environments: The code examples above have URLs hard-coded. Consider using a tool that uses configuration settings to retrieve or help construct URLs so that you can run your UI tests against your local instance, dev, build-server, QA, integration, etc. UI Tests make great build-validation utilities!
