Our first input

Well, our next test action to be configured is one that when executed will produce a list of available items for a given type. Here is the beginning of its entry in the Puffin config file:

     <testAction name='getPetsList'>
        <path>/puffindemoapp/itemList.cgi</path>
     </testAction>

As you can see, the getPetsList test action involves a call to the itemList.cgi page. The itemList.cgi page takes a parameter called list to indicate what type of list we want the app to display (Pets, Books, Gear, or Posters). In our case, we want a list of available Pets, so let's set up an input for this test action:

     <testAction name='getPetsList'>
        <path>/puffindemoapp/itemList.cgi</path>
        <input name="list" type="GET" processor="VALUE">
           <param name='value'>Pets</param>

        </input>
     </testAction>

The <input> element we added configures the getPetsList test action to take an input. An input is some value that Puffin will send to the Web application when it executes this test action. Puffin allows you to use POST or GET to send a value, or you can add a HEADER. In the above case, we set the type attribute to GET. This instructs Puffin to add this value to the query string when it executes this test action.

The input's processor attribute tells Puffin how to get the value it will send as an input. In the above case, this is simple. It will simply use the value specified in a parameter as is (in this case the word "Pets").

Now if Puffin executes this test action, it would be as if you typed the following into your browser's address line:

http://localhost/puffindemoapp/itemList.cgi?list=Pets

Puffin adds the ?list=Pets to the address as a query string (because this is a GET type input).

What if the user goes to this page and selects a pet for purchase? What shopping cart will Puffin use? We need the session id. But wait. We don't know what that value will be when we execute this. No problem. We will instruct Puffin to get the value from the token dictionary, like this:

     <testAction name='getPetsList'>
        <path>/puffindemoapp/itemList.cgi</path>

        <input name="list" type="GET" processor="VALUE">
           <param name='value'>Pets</param>
        </input>
        <input name="session_id" type="GET" processor="DICT">
           <param name='key'>SESSION_ID</param>

        </input>
     </testAction>

You can probably guess how this works. Basically, the DICT value for the processor attribute instructs Puffin to retrieve a value from the current token dictionary and to use that value for the input (again of type GET). So if we'd run a test plan that executed the login test action before this one (the login test action, recall, extracted the value for a SESSION_ID output token) and the value retrieved was 3201020311352, then executing the above test action would be like calling the following through your browser:

http://localhost/puffindemoapp/itemList.cgi?list=Pets&session_id=3201020311352

Puffin looks up the current value of the SESSION_ID token and uses that value to build the query string above.

We're almost ready to start writing test plans. Let's go ahead and set up a few more test actions. Make your <testActions> element look like the following:

  <testActions>

     <testAction name='login'>

        <path>/puffindemoapp/start.cgi</path>
         <output name="SESSION_ID" processor="extractRegex">
            <param name="expr" eval="0">
               <![CDATA[href="itemList\.cgi\?session_id=(\d*)]]>

            </param>

         </output>
     </testAction>

     <testAction name='getPetsList'>
        <path>/puffindemoapp/itemList.cgi</path>

        <input name="list" type="GET" processor="VALUE">

           <param name='value'>Pets</param>
        </input>
        <input name="session_id" type="GET" processor="DICT">
           <param name='key'>SESSION_ID</param>

        </input>

     </testAction>

     <testAction name='getPostersList'>
        <path>/puffindemoapp/itemList.cgi</path>
        <input name="list" type="GET" processor="VALUE">

           <param name='value'>Posters</param>

        </input>
        <input name="session_id" type="GET" processor="DICT">
           <param name='key'>SESSION_ID</param>

        </input>
     </testAction>


     <testAction name='tooLong'>
        <path>/puffindemoapp/tooLong.cgi</path>
     </testAction>

     <testAction name='serverError'>
        <path>/puffindemoapp/serverError.cgi</path>

     </testAction>

  </testActions>

The getPostersList test action is similar to the getPetsList test action. The other two will help us demonstrate what happens when we run into problems.

There are several things to notice:

• We are doing some of this the hard way (setting up two different list test actions when we could set up only one with a dynamically driven value for the listparameter, for example). But I want to show how this works.
• POST and HEADER type input work in a very similar fashion.
• There are MANY other input processors. Check them all out in the User's Guide if you cannot wait for future articles.
• Finally, as I mentioned earlier, we can also create response analyzers specific to individual test actions (you will do this often in your test plans). We will tackle this in later articles as well.