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:
As you can see, the
getPetsList test action involves a call to the
itemList.cgi page. The
itemList.cgi page takes a parameter called
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
set up an input for this test action:
<input> element we added configures the
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.
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
Now if Puffin executes this test action, it would be as if you typed the following into your browser's address line:
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:
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
executing the above test action would be like calling the following through
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
getPostersList test action is similar to the
action. The other two will help us demonstrate what happens when we run
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.