[Dev] Questions on the Design and XML

[William Martinez Pomares]

Hi Frank.

Yes, sorry about that :) Spanish : Proyecto. I still need to proof
reading english with Luis.
Luis is working and tuning up the design, but he is posting it to CVS
still rough, so you may be reading interim versions. 
We do have some questions in a discussion held yesterday. Basically:

1. Global Arguments. In the TestScenario we have global arguments. These
tend to be very confusing to the user, since the Setup, Run and TearDown
elements may receive arguments. Thus, we are not sure which ones will
receive the parameters and which ones won't. One idea would be to
declare not global arguments but properties (like in version 3 of your
XML: ant like) and the ones to require one of those values simply refer
to them.

2. MessageSizes. These are the Payload Sizes, which are actually indexes
to a table that is not defined anywhere. It is assumed that the
user-written test methods do handle that index. So, we will need to
require the methods to accept that index, although not specified as an
argument anywhere. Or, to require the user to specify the argument
explicitly, having the argument an attribute to indicate it is not a
value but the payload size.

3. TargetHost. In TM 4.4, properties file, we can specify the target
hosts, they URLs and connection strings. Here we do not. That means that
to test against two different servers, I have to create two different
XMLs and each one will have to use different jars and those jars are the
ones that "know" where the host is?  Or should we add an element with
the host information and pass it as a names argument (just like the
payload above)? 

4. Multiple TestScenarios. Luis is designing thinking that there would
be multiple TestUseCases, each one containing several usecases. Is that
the case, or do you think (as I do) that the testScenario XML holds only
one TestUseCase with multiple usecases?

5. UseCases. Actually, we can have several use cases. In the questions
Luis sent, he explained the hierarchy based on the actual disposition in
the XML. That is, the outer cycle would be CRLevels, then Payload sizes
and then UseCases. You told him it was ok. But that doesn't make sense.
The actual order in TM4.4 is outer cycle UseCases, the CRLevels and then
PayloadSizes. That is because you want to see the behavior of the server
doing updates in several crlevel/payload combinations, not the behavior
of the server with X users in several combinations of payloads and
usecases. Right?

6. Instances. Lastly, in 223 you can create an interpreter and send the
code in a string to execute. But that I'm not sure if supports data from
one call to be accesible on the other one. Thus, calling a Setup may
update some variables and create data, but the call to Run may not have
access to it. Rememeber it is not we create an instance of the class and
call several methods from it, not sure if it actually creates an
instance of the class in every call (the 223). What do you think?

William Martinez Pomares
Architect
Avantica Technologies
Phone(US)  :+1 (650) 353-4522  Ext 131
Fax(US)        :+1 (877) 372-1955  
Phone(CR)  :+506 283-9100 Ext 131 
Fax(CR)        :+506 253-7451 
http://www.avantica.net



-----Original Message-----
From: Frank Cohen [mailto:fcohen at pushtotest.com]
Sent: Monday, February 19, 2007 10:38 PM
To: William Martinez Pomares
Subject: Project Design doc


Hi William: I read through your comments in the ProyectDesign.doc.  
I'll give it a closer read in the morning.

By the way, there is a typo in the name of the document. The 'y'  
should be a 'j' in ProyectDesign.doc.

-Frank

--
Frank Cohen, PushToTest, http://www.PushToTest.com, phone 408 374 7426
TestMaker: The open-source SOA test automation tool