I don't think Latka's quite this smart yet, although you're not the only one
who would like it to be.
> Question 1 -- Selecting a form
>
> Our app frequently has multiple forms per page. Depending
> on what the user chooses to do, one or the other will be
> submitted. How can I tell latka which form should receive
> the parameters defined in its input file?
> For instance:
<snip/>
> <form name="editUserForm" action="EditUser.do">
> <input type="hidden" name="userName"/>
> </form>
>
> <form name="neverMindForm" action="CancelProcess.do">
> <input type="hidden" processName="editUser"/>
> </form>
<snip/>
Latka doesn't really know about forms, it just knows about URIs. Hence to
post the first form, you send a request like:
<request path="/mywebapp/EditUser.do" method="post">
<param name="userName" value="james"/>
<validate>
<!-- validations here -->
</validate>
</request>
To send a request to the second form, use:
<request path="/mywebapp/CancelProcess.do" method="post">
<param name="editUser" value=""/>
<validate>
<!-- validations here -->
</validate>
</request>
> Question 2 -- Preserving values for "playback"
>
> In reality, the user add process would create
> users with automatically generated unique IDs.
> So instead of this:
> <li><a href="javascript:editUser('james');">James</a>
> we would have this:
> <li><a href="javascript:editUser('1234');">1234</a> James</li>
>
> In order to test the user-add process completely
> I would define my testcase along these lines:
>
> A) Invoke AddUser.do
> B) Populate that form with some test user data. Let's say the username
> is "TestUserFoo"
> C) Submit the form
> D) Invoke ListUsersForEdit.do
> E) Apply an xpath along these lines to locate the user I just added:
> //li[contains(.,"TestUserFoo")]/a
> (that may not be perfectly correct but you get the idea)
> F) Use the getText() value of the 'a' element located to invoke
> DisplayUser.do?uid=whatever
As far as I know, Latka can't do that yet. The response to a request can be
validated, but currently can't really be used to modify the rest of the
requests in the suite.
To do this, I think we'd need to add a notion of "variables" into Latka test
suites, and ways of setting variables from response data. (As you suggest,
XPath seems like a good way of doing this.) We'd also need a little bit
smarter request processing.
Let's break down that testcase a bit:
> A) Invoke AddUser.do
> B) Populate that form with some test user data. Let's say the username
> is "TestUserFoo"
> C) Submit the form
Latka can currently do this, but you need to tell it the names and values of
each field in that form (i.e., you need to set <param>s in the <request>
with predetermined names and values). It seems reasonable, and perhaps not
that difficult to make Latka support logic like "set the first <input
type="text"> field in the form named 'addUser' to 'TestUserFoo" and submit
it, which would allow us to populate forms without necessarily knowing what
the field names are or what the form action/method is. (Of course, it would
make the testcase brittle with respect to reordering the fields in the
form.)
> D) Invoke ListUsersForEdit.do
> E) Apply an xpath along these lines to locate the user I just added:
> //li[contains(.,"TestUserFoo")]/a
> (that may not be perfectly correct but you get the idea)
Latka can currently do this as part of a validation, to confirm that
'TestUserFoo' is listed.
> F) Use the getText() value of the 'a' element located to invoke
> DisplayUser.do?uid=whatever
AFAIK, Latka can't do that yet, but with variable support it could. (I.e.,
set a variable to the value of that XPath, and then use that variable in a
later request.)
Perhaps some of the more recently active committers can comment on this, or
correct me where I'm wrong.
- Rod
