Data-Independent Tests


Tests that are data-independent can run with different test data values; they're not restricted to hard-coded values. Data-independent tests allow you to cover as much of the input space as you feel is necessary. You can hard-code specific cases initially, add additional values and permutations in the future, and/or move the values out of the test and into a separate file, depending on how extensive you want the coverage to be.

We've said it before, and we'll probably say it again: it's essential that your customer provide realistic data for the tests and that you drive your tests with this data. Since the customer is likely (and encouraged) to change his mind, you need to be able to easily add to, enhance, and reorganize this data.

When you capture scripts, all the values you enter end up hard-coded into the script. So do lots of others you may not have entered but that were generated, returned by the system, or otherwise created as a side effect of your interactions. It's possible to go into the captured script, identify and separate these components, rewrite the hard-coded statements to use parameters, and develop an infrastructure for passing these parameters down and around to all the places where they need to be used. It just takes a lot of time, and it's easy to be distracted by low-level details and miss something, especially if you didn't capture a particular variation on the scenario.

When you start with the tests, the parameters to the modules jump out just like the modules do. What parameters does the login module in the above example need to have? It requires a login id and a password, obviously.

How about the search module for the following search tests:

  1. Test that a search for a category/location combination with businesses succeeds and one with no businesses fails.

  2. Test that a search for a business name/location for which a business exists succeeds and that one for which no business exists returns an empty list.

Obviously, it needs a category/location combination or a business name/location combination and some means of knowing which it's getting:

 assertTrue( search("Cat/Loc", "Horses","Denver"));  assertFalse( search("Cat/Loc","Joy","Mudville")); assertTrue( search("Name/Loc","OCLC","Dublin, Ohio")); assertFalse(search("Name/Loc","OCLC","")); 


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