Jared's Weblog

Main Page - Books - Links - Resources - About - Contact Me - RSS

Jared Richardson Most Popular
 Help! I've Inherited Legacy Code
Testing Untestable Code
Continuous Integration... Why Bother?
Mock Client Testing
The Art of Work
Technical Idiot Savants
Targetted Skills Aquition vs Free Range Chickens
The Habits of Highly Effective Developers



 Blog Archive
2005-December
2005-November
2005-October
2005-September
2005-August
2005-July
2005-June

Tue, 15 Nov 2005

A Great Test

There are several characteristics a great test should have. I've discussed the topic recently and decided to create a blog entry about it. It will also be a part of a book I hope to start early next year.

By the way, bear in mind that I'm not talking about unit tests. While they do share some characteristics, they don't require external resources like external data.

Create

First, the test (or it's caller) configures it's environment. If the test needs data in a database, wipe the old table, recreate the schema, and re-add the data. This can be done once per test run (as opposed to once per test) but leaving old data laying around is just asking for data integrity issues to cast doubt on the resutlts your tests returns.

Anything you can do to make your tests rock solid and relable, you should do. Recreating data for each test run is an important step. Use tools like dbUnit to easily reproduce your data.

Run

A great test runs.

That is to say, nobody has to run it. Once a test suite is set in motion, nobody needs to push a button, start a server, click a dialog or run a script.

Nothing is more frustrating that seeing someone create an "automated" test that doesn't run without human intervention. Sometimes people get so close, but forget to stop short before the edge of the cliff.

Decide

Next, a great test passes or fails. A mediocre test has you look at log files to determine the pass or fail status.

Build enough smarts into your test that it can either pass or fail without your help. It already has enough smarts to test the code. Add just a bit more and let it know what the result is. This frees you from the boring chore of reading log files every morning.

Fail

A great test also fails from time to time. If it never fails, then it never catches a problem. You still get a lot of benefit from knowing your code is solid, but push the envelope with some of your tests.

There are few ways to move in this direction.

  1. You can target active code development. Put a few tests in place before the refactoring starts. These tests will ensure that your work doesn't change the code's function. This is great way to start your performance tuning, bug fixing, or feature adding work.
  2. Wrap tests around bugs as you find them and then test the code close by.
  3. Target code that's had historical problems. The odds are good that the routines that caused problems last year have undiscovered issues. Get test coverage in place to help uncover those unknown issues as well as keep the state of the code stable when addditional bug fixing occurs.

Clean

Finally, a great test cleans up after itself. It doesn't leave test droppings throughout the system that could corrupt the next test run or have unintended consequences.

Report

A great test leaves behind enough of a message to determine where the failure occurred and what caused the problem. A great test returns more than a stack trace. It also returns a short message that tells you exactly what it looked for and didn't find.

Sure, someone could go code diving to find the failed test and attempt to decipher the intent of the author. But a great test doesn't require that. It tells you what happened.

More?

This is a start... what more? What do you think about when you write a great test? What annoys you in a bad test? What test patterns trap the mediocre tests before they reach greatness?

Tell me.

Jared

posted at: 21:01 | path: | permanent link to this entry

Dancing Yoda: Update

I recently posted a link to a great video clip... Master Yoda break dancing. I've since learned that the Yoda clip is an Easter egg on the Revenge of the Sith DVD. You can find the directions to access the clip here.

The real story behind the egg is very interesting. The entire story is posted on Star Wars.com.

Apparenty Michel d'Annoville started the project as a surprise for the animation director... it turned out so well that when Lucas saw it, he insisted it go on the DVD.

But don't take my word for it. Read the entire story. :)

Enjoy!

Jared

posted at: 20:14 | path: | permanent link to this entry

Run Linux on your Windows desktop

You may already know that VMWare is now giving away their virtual machine run time.

What does this mean? Think of Adobe and PDFs. They give away the PDF reader (Adobe Acrobat) but they sell the tools to create PDFs. This is the same concept. You can run a virtual machine with the VMware player but you can't create one.

But you don't have to create a virtual machine. You can just download one. :)

Check out the VMWare Virtual Machine Center. Just by registering you can get VMs for Red Hat Enterprise Linux, Novell's Suse, etc. You can get WebLogic and Websphere as well.

You can also download their Browser Appliance . It's a prebuilt Ubuntu Linux image with FireFox already installed. I'm running on my desktop at the moment and it's quite responsive.

One of the cool features that I didn't expect is how it preserves state. Initially you "boot" into your virutal machine, but when you exit it preserves the state of the memory. When you restart the virtual machine image, it brings you right back to the same spot. Did you leave the browser open? It'll still be open. Cool.

This looks like a really easy way to keep different web browsers around, different versions of an operating system, etc. I can see this being very useful for developers or testers who need another environment around... or just someone who wants to tinker a bit.

Jared

posted at: 19:26 | path: | permanent link to this entry