This post originated from an RSS feed registered with Agile Buzz
by Jared Richardson.
Original Post: Test Driven Refactoring
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.
This is something that people have probably been doing for years, but I haven't seen it named and I've found it's easier to remember something with a "name", so TDR it is. :)
If you are a developer or tester trying to get an automated test suite 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 testing framework. It's not impossible to test "untestable" code, but the effort involved in test creation and maintainence 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 5th item. Not only is this very difficult for someone else to understand and maintain, 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 hit the moon on your first attempt. Shoot for a simple pass that exercises basic functionality.
Second, write using some framework (JUnit, MBUnit, whatever). Make the test go as far as you can. When you get stuck, what's the least amount you can add and 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 "boil the ocean" 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 from developers, testers and even managers once you've got a basic automation suite in place.
Previous Topic
