Modular Tests


Modular tests don't have the massive duplication that results in captured scripts. The advantages of this should be obvious. In fact, these days, the idea of a creating a monolithic program with twenty chunks of identical code to do the same thing in twenty different places would probably never even cross your mind. Unless, of course, you can remember when people actually wrote programs that way. We can, unfortunately, still remember those programs (at least on good days we can. Some days, we can't remember where our teeth are). Uh … where were we? Oh yes the sad thing is, people are still creating automated tests like that, even though we've known better for going on thirty years now.

Modular doesn't just mean breaking the test into any old pieces. It has to make sense and make you more productive. For instance, suppose you're working on a test for a forms-based Web application. After you do some capturing and start editing the scripts, you see lots and lots of code filling out forms, in whatever manner the test tool represents that. "Aha!" you think, "This cries out for some modularization" and create a module called FillOutForm. You parameterize it with the form to fill out, the fields to set, and the values to set them to, and replace all that code with calls to FillOutForm.

Unfortunately, this modularization is not useful. For instance, it removes duplication in an area that isn't likely to change and leaves it in the areas that will (how you fill out a form won't change, but the fields you set and the values you set them to will). Also, how does FillOutForm relate to your test? It doesn't it's just a means to an end. Try reviewing a test full of FillOutForms with your customer and you'll spend a lot of time trying to relate it to anything she cares about.

In fact we know you would never make this particular mistake, but it's a classic case of not seeing the forest for the trees. It's easy to fall into similar traps when trying to reverse-engineer. All that junk in the captured script can easily confuse you about what's important. So much has to do with the mechanisms of running the test that you focus on that instead of the test itself.

When you start with the test, the modules are obvious:

Test that login with a valid password succeeds and a bad one fails

 assertTrue( login("bob","bobspassword") );  assertFalse(login("bob","wrong")); 

What is the module? login, of course it jumps right out at you. The login module can encapsulate everything possible about logging in, so this test never has to change, no matter how much the application changes (and it will change), and the test relates exactly to the feature of concern: logging in.



Testing Extreme Programming
Testing Extreme Programming
ISBN: 0321113551
EAN: 2147483647
Year: 2005
Pages: 238

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net