Hello all.

I'm considering modifying the <webtest> task source to support a few
common ant tasks as nested elements:

-add support for the <echo> task so that I can include these in modules
for printing debug messages.  For example, I could use <echo
message="module:createUser.xml"/> inside of my createUser.xml entity so
I can find it within the console window.

-add support for the <fail> task so that I can ensure all required
properties (that is, required by the xml inside the module) are set.
For example, in my createUser.xml module, I could use <fail
unless="user.name"> to toss a friendly debug message if user.name was
not provided (i.e. if user.name is has a uniqueness constraint, and
therefore a logical default may not be useful).

-add support for the <property> task.  I could use this to define
default properties within a module that could be overridden by the
caller.  Putting these together, I could have a module that looks like
this:

  <echo>module:createuser.xml"</echo>

  <fail unless="user.name">
  The property 'user.name' is required by module createuser.xml; use
this property to specify the name of the user to be created.
  </fail>

  <property name="user.pwd" value="letmein"/>
  <property name="pwd.confirm" value="letmein"/>
  <property name="user.email" value="[EMAIL PROTECTED]"/>
  <property name="user.notes" value="This user created by WebTest"/>

  <invoke         description="get create user page"
url="/CreateUser!input.action"/>
  <setinputfield  description="set user name" name="user.name"
value="${user.name}"/>
  <setinputfield  description="set user password" name="password"
value="${user.pwd}"/>
  <setinputfield  description="confirm password" name="confirmPassword"
value="${pwd.confirm}"/>
  <setinputfield  description="set email" name="user.emailAddress"
value="${user.email}"/>
  <setinputfield  description="set notes" name="user.notes"
value="${user.notes}"/>
  <clickElement   description="submit new user" xpath="//[EMAIL PROTECTED] =
'createUser']"/>
  <verify.... (verify user creation, etc)


I think this adds a little flexibility to the module.  If a test only
needs to create a user as a collaborator (say, to test user teams), the
test author only needs to provide user.name (which must be unique) in
order to use module, since the author probably doesn't care about the
current values for the other properties).  However, a test that focuses
on user creation could override all the properties in order to test
various validation (within a PropertyTable block, for instance).

Does this make sense to anyone?  Do these capabilities exist and I
simply haven't discovered them?




-John Kercher
_______________________________________________
WebTest mailing list
[email protected]
http://lists.canoo.com/mailman/listinfo/webtest

Reply via email to