[Webtest] Starting up

[Ben Cox]

Carlton Nettleton wrote:

>Three, I have never used ANT (or Java for that matter) before.  ANT is a
>nice tool, but what is the ANT property referenced in troubleshooting
>section about keeping your tests clean?  I understand how to use the XML
>"includes", but this ANT property thing is confusing me.  How do they help
>keep your tests clean.  Again, the documentation in webTest and the ANT site
>just glosses over these ideas.  Any help out there?
>
This one I can help you with :-)
I trust you are referring to the following paragraph:

Put all the references that occur more than once into an ANT 
<http://webtest.canoo.com/webtest/manual/troubleshooting.html#ANT> 
property. Consider putting shared properties into a properties file. Use 
the ant and antcall tasks to extract reusable logik into subbuild files 
and subtargets. Use XML 
<http://webtest.canoo.com/webtest/manual/troubleshooting.html#XML> 
entities for textual includes. See the samples on how to do this.

Let's take this one sentence at a time:

 > Put all the references that occur more than once into an ANT 
<http://webtest.canoo.com/webtest/manual/troubleshooting.html#ANT> property.
What the doc refers to as "references" are any name, label, etc. that 
won't change.  For example, suppose you have a "Login" button, and you 
wish to click it using WebTest.  Given that you have to log into the 
system to test anything, you'll likely be clicking "Login" a great many 
times.  Suppose, also, that you have an internationalization scheme that 
replaces "Login" with another name from a resource bundle for that 
language.  Clearly, putting <clickbutton label="Login"/> all throughout 
your WebTest file would be a blunder, because it would require a 
separate buildfile (identical except the Strings) for each language. 
 Ant allows you to define properties such that the XML to click that 
button would now look like: <clickbutton 
label="${button.login.label}"/>, or similar.  See the Ant doco for the 
many ways these can be defined.  There are a number of uses for this 
that don't have to do with internationalization.  For example, imagine 
an application where the buttons, etc, change depending upon the user...

 > Consider putting shared properties into a properties file.
If you do create properties, as in the previous explanation, these will 
probably prove useful in more than one buildfile, especially as your 
entire test suite gets larger and you need to break it down into smaller 
buildfiles in order to stand a chance of managing them. Ant allows you 
to load properties from an external file, and subsequently reference 
them in the buildfile.  If you have, say, three or four WebTest 
buildfiles, each testing a different portion of your system, you may 
require that a particular element, say, the Login button, be used in all 
of them.  Defining such properties in an external file, and loading them 
in each buildfile, allows you to change these (say, to "Sign On") all in 
one place without having to go through all of your buildfiles 
individually.  Additionally, you could set up the name of the properties 
file you load based on yet another property which you set on the command 
line.  This would make the internationalization concept complete.

 > Use the ant and antcall tasks to extract reusable logik into subbuild 
files and subtargets.
Remember how I mentioned breaking down the test suite into smaller 
buildfiles?  That's where this comes in.  You can call another target in 
the same buildfile, or in another buildfile, using the <ant> and 
<antcall> tasks in Ant.  Thus, you can create a master buildfile called 
TestSuite.xml, and a series of smaller buildfiles (called, say, 
TestAccounts.xml, TestCustomer.xml, etc.), each of which is referenced 
by that master buildfile.  Furthermore, you can define often-repeated 
steps (say, "ValidateCustomerTableFormat") in individual targets, and 
call these targets from within other targets (say, "AdministerCustomers" 
and "ShowCustomers").

 > Use XML 
<http://webtest.canoo.com/webtest/manual/troubleshooting.html#XML> 
entities for textual includes.
Well, this is a lot like the previous one, but without the need for 
buildfiles or targets.  Say you always have to login in order to perform 
a test on your web application.  If you wish, you could create a 
subtarget called "TestLogin" and call it from your other targets before 
doing anything else.  However, this target may include a lot of 
verification (and/or test login-specific things like the error page for 
incorrect logins) which you don't need to do more than once when running 
an entire test suite.  Thus, you may prefer to pull the steps of the 
"TestLogin" target that have to do with navigating through the login 
process into an external entity, and include it into "TestLogin", as 
well as whatever other targets you create.  For example:

<target name="TestLogin">
<testspec>
  &login;
  <verifytext text="Thanks for logging on!"/>
  <verify...>
...
</testspec>
</target>

<target name="TestAccountSelection"/>
<testspec>
  &login;
  <clickbutton label="Select Account"/>
  <verifytext text="Please select your account:"/>
  ...
</testspec>
</target>
 
The entity that's included as "&login;" is a separate file which looks like:

<invoke url="http://myserver.com/login.html"/>
<setinputfield name="username" value="myname"/>
<setinputfield name="password" value="mypass"/>
<clickbutton label="${button.login.label}"/>

The upshot of all this is the ability to create tests in as granular a 
fashion as you are creative enough to design.  When my partner and I 
used WebTest (to attempt acceptance testing of our webapp), we did use 
cases by having each test login to the server and perform the activities 
required to get to and test the portion of the system that we are 
interested in.  Many steps would be repeated, and these made up a host 
of external entity files with from two to twenty tags in each.
Hope this helps,

  Ben

>Carlton Nettleton
>carlton@edubusinesssolutions.com
>
>
>_______________________________________________
>WebTest mailing list
>WebTest@lists.canoo.com
>http://lists.canoo.com/mailman/listinfo/webtest
>  
>