Tools - Refactoring HTML: Improving the Design of Existing Web Applications - page 34

Testing

In theory, refactoring should not break anything that isn't already broken. In practice, it isn't always so reliable.
To some extent, the catalog later in this topic shows you what changes you can safely make. However, both
people and tools do make mistakes, and it's always possible that refactoring will introduce new bugs. Thus, the
refactoring process really needs a good automated test suite. After every refactoring, you'd like to be able to
press a button and see at a glance whether anything broke.

Although test-driven development has been a massive success among traditional programmers, it is not yet so
common among web developers, especially those working on the front end. In fact, any automated testing of
web sites is probably the exception rather than the rule, especially when it comes to HTML. It is time for that to
change. It is time for web developers to start to write and run test suites and to use test-driven development.

The basic test-driven development approach is as follows.

1. Write a test for a feature.

2. Code the simplest thing that can possibly work.

3. Run all tests.

4. If tests passed, goto 1 .

5. Else, goto 2 .

For refactoring purposes, it is very important that this process be as automatic as possible. In particular:

The test suite should not require any complicated setup. Ideally, you should be able to run it with the click
of a button. You don't want developers to skip running tests because they're too hard to run.

The tests should be fast enough that they can be run frequently; ideally, they should take 90 seconds or
less to run. You don't want developers to skip running tests because they take too long.

The result must be pass or fail, and it should be blindingly obvious which it is. If the result is fail, the failed
tests should generate more output explaining what failed. However, passing tests should generate no
output at all, except perhaps for a message such as "All tests passed." In particular, you want to avoid the
common problem in which one or two failing tests get lost in a sea of output from passing tests.

Writing tests for web applications is harder than writing tests for classic applications. Part of this is because the
tools for web application testing aren't as mature as the tools for traditional application testing. Part of this is
because any test that involves looking at something and figuring out whether it looks right is hard for a
computer. (It's easy for a person, but the goal is to remove people from the loop.) Thus, you may not achieve
the perfect coverage you can in a Java or .NET application. Nonetheless, some testing is better than none, and
you can in fact test quite a lot.

One thing you will discover is that refactoring your code to web standards such as XHTML is going to make
testing a lot easier. Going forward, it is much easier to write tests for well-formed and valid XHTML pages than
for malformed ones. This is because it is much easier to write code that consumes well-formed pages than
malformed ones. It is much easier to see what the browser sees, because all browsers see the same thing in