Our first output token

Puffin maintains this type of information in a TokenDictionary object, which is basically a glorified hash of named values. Puffin can extract these values from a given test action's response (or from other previously existing tokens or from several other sources of information) and store them in the token dictionary. The act of initializing this value is called "processing an output" because most of the time you will be retrieving this value from the response document the Web application returns upon execution of a test action; you will be retrieving an "output" of that test action's execution.

How do we tell Puffin to extract this output (in our case, the session id) every time it executes this test action? Exactly as you'd guess: with information in the Puffin config file:

<testActions>
   <testAction name='login'>
      <path>/puffindemoapp/start.cgi</path>

         <!-- OUTPUTS -->
         <output name="SESSION_ID" processor="extractRegex">

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

   </testAction>
</testActions>

The bold code above tells Puffin to use the extractRegex output processor to extract a value from the response of the test action named login and store it in the current token dictionary under the name SESSION_ID. The processor takes a parameter named expr, which, in our case looks like this:

   href="itemList\.cgi\?session_id=(\d*)

For those of you familiar with regular expressions, this is pretty straightforward; for all others, this probably looks like an erroneous entry. Though it is beyond the scope of this article to teach the nuances of regular expressions, suffice it to say that regular expressions allow you to parse text that by matching certain patterns (see Resources for some developerWorks articles on regular expressions). In the above case, the pattern can be roughly translated into the following pseudo code: Return all the text that starts with 'href="itemList.cgi?session_id=' and is followed by some number of numeric characters.

The parentheses around the \d* denote the actual sub-section of the matching phrase we want to return. So in our example HTML, if given the following:

<a href="itemList.cgi?session_id=3201020311352&list=Posters">Posters</a><br/>

The regular expression would match this:

href="itemList.cgi?session_id=3201020311352

And return this:

3201020311352

Puffin would then store this value in a token named SESSION_ID in the current token dictionary (which is maintained throughout a test plan's execution).

Those of you familiar with regular expressions will note that the above regular expression matched several lines (not just one). You are right. However, because we used the extractRegex and not the extractRegexList output processor, Puffin returned the first match. We will cover the extractRegexList output processor and its use in a later article. If you get curious before then, check the User's Guide. There are many other things you can do with output processing including generating random numbers or strings, calculations using tokens, etc. All are in the User's Guide.

Once this test action gets executed in a test plan, we will have an output token called SESSION_ID. Now what?