Figured I'd share something I found valuable.  Did you ever make a call to a request level plug-in in a Visual Studio 2008 WebTest and get multiple calls to the same plug-in because of a 302 redirect?  Well I did and took me a little bit to find out a way to prevent it.
When you are making the call in your code, decide if it should run based on IsRedirectFollow property (http://msdn.microsoft.com/en-us/library/microsoft.visualstudio.testtools.webtesting.webtestrequest.isredirectfollow(VS.80).aspx)
As an example:

  1: namespace MyAppTests
  2: {
  3:     public class GetSomethingPlease: WebTestRequestPlugin
  4:     {
  5:         
  6:         public override void PostRequest(object sender, PostRequestEventArgs e)
  7:         {
  8:             if (e.Request.IsRedirectFollow == false) //only want to run this on on a primary, not a redirect
  9:             {
 10:                 //do something here
 11:              }
 12:          }
 13:       }
 14: }
 15: 

Anyway, I hope this helps someone else a little further along.  It works in VS2008 and VS2010 as well.  I'm sure there could be a more efficient way, but this worked in a pinch ;-)

Some of my regular readers said they wanted to see more "technical" content, so here is one that perplexed me a while.

While assisting a client with setting up an automating testing environment using Visual Studio 2008 Web Tests (among other things) we uncovered a need to check the results of a transaction halfway through, then when its complete to verify the results of the test.

Now I know what experienced testers and SQA people are thinking, "why didn't you just use an Extraction rule from a results page and validate that?". Yes, that's the first thing I wanted to have done as well and that works quite well under most circumstances.

Unfortunately on this particular application there is no real "confirmation" screen that displays the results of the transaction, just kind of a yeah I did or no I didn't kind of page. Not good enough in our case where I wanted to have real transaction results.

Since time was very short and I'm still working with the group to adopt more "test friendly" designs we needed a sure way of verifying the results. I though that this check DB feature would be a native feature in the VSTS2008 Web Test, but the only DB connectivity included out of the box was binding to a DB for data driven testing (which is very useful as well).

So our option was a to create a request level plug-in to go out to the DB and check the transaction results, and write them back to the test results.

My goals here were:

1. Connects to an SQL DB.
   
2. Builds a query string using a Context parameter
   
3. Puts the value pulled from the DB back into another Context parameter for use in follow on requests.

Here is how I did it (in a plug-in 101 type format), complete with code snippet I used to create this:

1. Create the following in a class library in your test project (that part is covered in detail in MSDN), compile, and reference it:

  1: using System.Text;
  2: 
  3: using Microsoft.VisualStudio.TestTools.WebTesting;
  4: 
  5: using System.Data.SqlClient;
  6: 
  7: 
  8: 
  9: namespace Test1
 10: {
 11: 
 12:     public class MyRequestPlugin : WebTestRequestPlugin
 13:     {
 14: 
 15:         public override void PostRequest(object sender, PostRequestEventArgs e)
 16:         {
 17: 
 18:             base.PostRequest(sender, e);
 19: 
 20:             int CustomerID = 0;
 21: 
 22: 
 23:             // this is my connection string
 24:             String connectionString = "Persist Security Info=False;Initial Catalog=dbname;Data Source=machinename; User Id=dbuser;Password=somepassword";
 25: 
 26: 
 27:             // select statement getting just the field I need.  Note that if this is;
 28:             // messed up it may throw an error saying is cant open the db.;
 29:             // This is misleading, its probably your select; 
 30:             SqlConnection connection = new SqlConnection(connectionString);
 31: 
 32:             string queryString = "Select CustomerID from Orders where OrderID=" + e.WebTest.Context["OrderID"];
 33: 
 34: 
 35: 
 36:             SqlCommand command = new SqlCommand(queryString, connection);
 37: 
 38:             command.Connection.Open();
 39: 
 40:             SqlDataReader reader = command.ExecuteReader();
 41: 
 42:             while (reader.Read())
 43:             {
 44: 
 45:                 CustomerID = Convert.ToInt32(reader[0]);
 46: 
 47:             }
 48: 
 49:             e.WebTest.Context.Add("CustomerID", CustomerID);
 50: 
 51: 
 52: 
 53:         }
 54: 
 55: 
 56: 
 57:         public override void PreRequest(object sender, PreRequestEventArgs e)
 58:         {
 59: 
 60:             base.PreRequest(sender, e);
 61: 
 62:         }
 63: 
 64:     }
 65: 
 66: }
 67: 
 68: 
 69: 

2. Insert the Request Plug-in (if you compiled and referenced it, it will be in the list.) AFTER the Context parameter you are using (in a production test you'll need error control, errors in a Plug-in are ugly and will mess up your results).

This whole exercise made think that a "data check" validation rule of sorts really should be part of this product.

Anyway hope this helps someone else a little further along some day using web tests. This same method also works in Visual Studio 2010 as well.

I'm always happy to see an organization I'm working with recording "lessons learned" documentation from multiple iterations of the same product, or successive project engagement.  The real key however is taking this information and turning into action items that help you get further along.  Too often I see teams committing items to Lessons Learned documents more like a confessional than a plan to not make the same mistake, or repeat a successful technique.

There are some simple steps we can use to help ensure a learning experience:

1. Document collaboratively.  This will avoid personal attacks and maximize the effort. I find it best to conduct several short meetings to get this done than one long one (again no confessionals here).
2. Successes and Failures.  Too often people are quick to point out failures but its just important to make sure we don't miss the things that worked well the next time.
3. Everyone Participates.  These sessions aren't just for the PM's, get everyone involved in the project involved.  This would also include your outside vendors if the relationship allows.
4. Rinse and Repeat.  Take your list of Lessons Learned and put them into documents used in every project Initialization phase.

Thats about it.  Hopefully we are all a few short steps away from the next level of productivity.

CRHC9HJBHU87