The test action is the fundamental unit of any puffin test plan. It represents a step in a
larger process. Most often, a test action represents a call to your web application. However,
sometimes, a test action can represent only a specific action in a test plan that, when
executed, produces an output value for later use.
 
Test actions (as are most things) are configured in the puffin config file.
Here is an example test action that involves a server call:
 
      <testAction name='login' stopPlanOnFail='1'>
         <path>/jsp/appLogin.jsp</path>
         <responseAnalyzers useDefaults="1">
            <responseAnalyzer src="puffin" type="ExpressionResponseAnalyzer">
               <param name="expr"><![CDATA[E.C.PTION]]></param>
               <param name="caseSensitive">0</param>
               <param name="re">1</param>
               <param name="foundResult">0</param>
            </responseAnalyzer>
         </responseAnalyzers>
         <input name='userid' type='POST' processor='DICT' sendDefault='0' defaultValue=''>
            <param name='key' eval='0'>USER</param>
         </input>
         <input name='password' type='POST' processor='DICT' sendDefault='0' defaultValue=''>
            <param name='key' eval='0'>PASSWORD</param>
         </input>
         <output key='SECURITY_COOKIE' processor='extractHeader' extractDefault='0' defaultValue=''>
            <param name='headerName' eval='0'>set-cookie</param>
            <param name='headerPrefix' eval='0'>WebLogic</param>
         </output>
      </testAction>
 
As you can see, you have a path (which represents how to call the server app) and a series
of inputs and/or outputs. It also includes a section specifying the response analyzers to 
use with this test action (note you can choose to ALSO use the defaults as well as the
response analyzers configured here, if you choose). The default on whether or not to use
the default response analyzers is TRUE. This results in the test action's response being
analyzed against the default response analyzers and the response analyzers configured 
specifically to the test action.
 
Here is an example test action that does NOT involve a server call:
 
       <testAction name='loginLoad' stopPlanOnFail='0' noSvrCall='1'>
          <path/>
          <output key='USER' processor='getNextLoginInfo' src='custom' extractDefault='0' defaultValue=''>
             <param name='returnVal' eval='0'>USER</param>
          </output>
          <output key='PASSWORD' processor='getNextLoginInfo' src='custom' extractDefault='0' defaultValue=''>
             <param name='returnVal' eval='0'>PASSWORD</param>
          </output>
          <output key='ITEMS_REMAINING' processor='getNextLoginInfo' src='custom' extractDefault='0' defaultValue=''>
             <param name='returnVal' eval='0'>ITEMS_REMAINING</param>
          </output>
       </testAction>
 
Note that other than the noSvrCall attribute on the <testAction> element, there is no
difference between a test action that involves a server call and one that does not.
 
To execute a test action, you must specify it in a test plan. Test plans come in two forms.
For more detail, see the user's guide in /doc folder.
 
All test actions can have one or more input and/or output tokens. (For more information on 
inputs and/or outputs, see the tokenprocessing module.) However, puffin need not process all
inputs or outputs. You can specify that only some subset of the total set of possible inputs
or outputs get processed in the test plan. See the user's guide for more information.