This post originated from an RSS feed registered with Agile Buzz
by Jared Richardson.
Original Post: Testing Untestable Code
Feed Title: Jared's Weblog
Feed URL: http://www.jaredrichardson.net/blog/index.rss
Feed Description: Jared's weblog.
The web site was created after the launch of the book "Ship It!" and discusses issues from Continuous Integration to web hosting providers.
If you are a developer or tester trying to get an automated test suite
set up for your product, you may find yourself in the uncomfortable
position of trying to test a product that doesn't have good "hooks" for
your test rigs. It's not impossible to test "untestable" code, but the
effort involved in test creation and maintenance usually cancels out
the benefit of the automation.
For instance, you might be trying to test an HTML page that has a lot
of unnamed fields. So instead of using the "name" or "id" tags to locate
a field, you count the items on the page and check the value in the
fifth item. This is very difficult for someone else to understand and
maintain, but the test is also very fragile. Often, changes to the page
will break your test.
What's the solution? Tell your manager you want to start test driven
refactoring. You want to start adding the simple hooks to your application
that make it possible (or feasible) to do good automated testing.
First, create (or borrow) a test plan for the product. Keep the plan
simple at first. Don't try to make it perfect on your first attempt. Shoot
for a simple pass that exercises basic functionality.
Second, write an automated test. Make the test go as far as you can.
When you get stuck, what's the least amount you can add to the product's
code to get the test running? Is it just a return code to an existing
API or an "id" tag for an HTML field?
Don't try to fix every problem with your first pass. Don't try to add "id"
tags to every page in your product; shoot for the one page you need
to get the test passing. If your test plan hits a roadblock, don't stop.
Remove the part of the test plan you can't test and move on. Remember
that you can also add the hard part to your next test plan.
The goal here is incremental improvement and momentum. As you
make small improvements, your developers will start learning how to
create testable products. As you write automated tests, you'll start
learning tricks too. You'll be surprised at how much support you'll get
once you've got a basic automation suite in place.
The Tip? Use test driven refactoring to clean up untestable code
Previous Topic
