HTML and CSS Reference
class GoogleSearch < Test::Unit::TestCase
@verification_errors = 
@selenium = $selenium
@selenium = Selenium::SeleneseInterpreter.new("localhost",
4444, *firefox", "http://localhost:4444", 10000);
@selenium.stop unless $selenium
assert_equal , @verification_errors
@selenium.type "q", "elliotte"
@verification_errors << $!
Getting Started with Tests
Because you're refactoring, you already have a web site or application; and if it's like most I've seen, it has
limited, if any, front-end tests. Don't let that discourage you. Pick the tool you like and start to write a few tests
for some basic functionality. Any tests at all are better than none. At the early stages, testing is linear. Every
test you write makes a noticeable improvement in your code coverage and quality. Don't get bogged down
thinking you have to test everything. That's great if you can do it, but if you can't, you can still do something.
Before refactoring a particular page, subdirectory, or path through a site, take an hour and write at least two or
three tests for that section. If nothing else, these are smoke tests that will let you know if you totally muck up
everything. You can expand on these later when you have time.
If you find a bug, by all means write a test for the bug before fixing it. That will help you know when you've
fixed the bug, and it will prevent the bug from accidentally reoccurring in the future after other changes.
Because front-end tests aren't very unitary, it's likely that this test will indirectly test other things besides the
specific bit of buggy code.
Finally, for new features and new developments beyond refactoring, by all means write your tests first. This will
guarantee that the new parts of the site are tested, and tests will often leak over into the older pages and
scripts as well.