Login Module

The modules login, createUserId, and deleteUserId share a similar basic structure. They have a fixed set of parameters defined by the MDS framework and make the same sort of calls to MDS utilities at the beginning and end. Here's what the login module looks like:

 !subscript login *pOut pIn tData vLevel *outCome vCrit  !declare zzId zzPsw pPage !declare myOutCome ! {   trace (login, interface, pOut, pIn, tData, vLevel);   myOutCome=UnKn;   getField(zzId,id,tData);   getField(zzPsw,psw,tData);   >0>$get(pPage,           "http://${zzorghostzz}/.../login.htm")[];   form.pPage.0.superid.tb.0[0] = "zzId";   form.pPage.0.password.pw.0[0] = "zzPsw";   form.pPage.0.Submit.su.0[0] = "Logon";   >7>$submit(pOut,pPage,0)[];   doValidation(outCome, myOutCome, tData, vCrit,                vLevel, pOut);   } !end 

The first few lines are declarations that define the parameters to the module and variables for use within the module.

• The pOut parameter will receive the XTrack system's response to the attempted login when login returns.

• The pIn parameter contains the current page (if any the first time login is called, there will be no current page).

• tData contains the "real" parameters to login: the id and password.

• vLevel is an MDS variable that controls the level of validation.

• outCome will receive a value reflecting the outcome of the validations of the system's response to the login attempt.

• vCrit contains the validation criteria to check.

These last three are handled by MDS utilities and are just passed on to those utilities without requiring processing within login.

Next, a call to MDS utility called trace handles logging the test results. An assignment sets the variable myOutCome to UnKn (unknown in the MDS framework, the outcome of a test can be pass, fail, or unknown).

The next steps are two calls to the MDS getField utility, which unpacks the values of the parameters from the tData. All parameters passed from an executable test in Java into a module like login are packed together into tData, and the getField utility unpacks them by name. This is why the parameter names were added to the parameter values in the calls to the WebARTPersistentScript.invoke method in the previous chapter. The names specified for the parameters there must match the names user here: id and psw.

The remaining lines, except for the call to doValidation at the end, are the scripting of the interaction with the XTrack system through the HTTP protocol. They are

• A $get that retrieves the page with the login form (we replaced a large chunk of text in the URL parameter to $get with "…" for clarity)

• Several assignment statements that set the fields in the login form to the specified id and password (the values that were passed in in tData, then extracted via getField into zzPsw and zzId)

• A $submit that submits the filled-out login form to the XTrack system

Finally, doValidation is an MDS utility that takes the response to the login (which was placed into pOut by $submit) and validates it according to the validation criteria in vCrit. If the validations pass, doValidation sets outCome to PASS. If not, it sets it to FAIL. The value of the outCome variable is then returned to the jWebARTInterface module, which in turn passes a value of either true (for pass) or false (for anything else) back to the executable tests in the Java environment. All this is to allow our tests to be self-verifying. If you see pass after this test runs, no worries. Otherwise, you need to investigate.

The other modules, createUserId and deleteUserid, are similar to this, as would be the others required to get all the executable tests running through WebART (createTask, updateTask, createStory, and so on).