Web Testing with Microsoft Visual Studio 2010 Ultimate: Context Parameters

This represents the first of a number of blog posts I hope to write over the next few weeks.  As my colleagues and I continue to deep-dive into the web testing tools provided by Microsoft Visual Studio 2010 Ultimate, I hope to share what we learn with you.

Today, my colleagues and I discussed the concept of test organization strategy.  In short, this translates to building reusable "chunks" of tests.  A great example of a reusable test is "Logon to site".  These is absolutely no reason to duplicate this effort across all tests you record.  Instead, record logon, parameterize the username and password and save it as a ".webtest" file.  The same approach applies to logging off a site.

The primary reason to do this is to promote reuse of webtests across your testing repository.  I'm not a test engineer so I have to give credit where credit is due.  My good friends and colleagues Guru Shyam Mony and Azmathulla Mohammed drilled this into my head and it simply makes sense from a test organization perspective.

Once we start going down this path, ultimately we'll want to create composite web tests.  Composite Web Tests a simply web tests that call other web tests.  Typically a single composite web test will represent a unit of work to be tested, or in test engineer terms a test scenario. 

Once we start creating composite tests, there will almost always be situations where we want to pass context parameters from the composite test to its child test.  I was surprised to find tonight how easy this actually is.

Step 1:  Create a context parameter in the "child test" and give it a default value that will allow the "child test" to pass.
Step 2:  In the composite test, create a parameter with the same name as that in the "child test".  Choose your method of setting the value for the context parameter.
Step 3:   Run the composite test and create some form of validation that ensures the value is passed from the composite test.

What you'll find is the composite test will in effect override the "default" value of the context parameter in the web test it calls and supply its own value. 

A great example of where this type of behavior may be desirable is as follows:

1) User logs in
2) Data source drives a set of dates and each date is supplied to a context parameter in the composite test.
3) Composite test calls a data entry web test and needs the date as a value.
4) Composite test calls a "review entries" web test and needs the date as a value.

We can essentially control the composite test and its subordinates with a single data source and a context parameter.