[Dev] DPL idea
William Martinez Pomares
wmartinez at AVANTICATEC.NET
Fri Apr 20 14:25:41 PDT 2007
Hi.
1. I imagine a default interface (specified in text, since it could be
implemented in several languages) that must be implemented by one class.
That class, and all the supporting classes it needs, may be inside a
package/module/jar whatever the language calls it. That class is what I
call the Main class.
With this:
<dplDefType name="xdbms" library="xqueryDPL.jar" lang="java">
The xqueryDPL.jar contains a class that has the setup, tearDown,
getData, getNextData, getNextDataIndex, and getRandomData. I need to
know what's the name of that class. I can, for simplicity, add it to the
dplDefType element like this:
<dplDefType name="xdbms" library="xqueryDPL.jar" lang="java"
class="com.pushtotest.external.xquerytest">
So, I know that when the user needs the xdbms DPL, the runner must load
the xqueryDPL.jar and instantiate the xquerytest and call its setup
method with the argument xqueryFile set to "procedures.xqr".
What do you think?
2. The construct would be
<argument name="bod1" dpl="bodschema" value="getDataRandom" />
instead. Note there is no messagesize, since that is not needed (we are
fetching a random value, that is a random index).
I assume the DPL will use a random index in this one, not that the DPL
will generate a random size. That second option does not make sense when
the DPL returns SQL scripts, or other kind of data that is not
randomizable.
William.
-----Original Message-----
From: dev-bounces at lists.pushtotest.com
[mailto:dev-bounces at lists.pushtotest.com]On Behalf Of Frank Cohen
Sent: Friday, April 20, 2007 11:28 AM
To: TestMaker Developers List
Subject: Re: [Dev] DPL idea
I love it! See below for my comments. -Frank
On Apr 19, 2007, at 10:54 AM, William Martinez Pomares wrote:
> A Data Production Library is a set of classes (a jar if you wish) that
> is able to produce sample data to be used as payloads.
> Thus, its definition may include:
> 1. The jar, module, package, gem, or whatever you use as a library.
> 2. The language definition.
> 3. A standard Interface but an open setup method (that is, accepting
> whatever arguments needed).
>
> Although PushToTest may include some common ones in its tool library,
> users may be able to add their own.
>
> DPLs are related to the messagesize structure. The messagesize is just
> an index to the DPL, and its use is through the getDataIndex() method.
> An example may explain this:
> <crlevels>
> <crlevel value="1" />
> <crlevel value="2" />
> </crlevels>
> <!-- The message sizes -->
> <messagesizes>
> <messagesize value="1" />
> <messagesize value="2" />
> </messagesizes>.
>
> The above elements indicate that the testcase will run four times,
> combination of crlevel and messagesize. The first run will be executed
> using only one user (crlevel) and the message size will be 1. That is,
> the "global variable" message size will value 1. User can use that
> value
> in whatever (s)he likes, it may be passed to the method, to the setup,
> or use it in the DPL to obtain a text, an XML, and object, or a query,
> and pass that to the method (as shown below in the index attribute).
> The next iteration will have the same one user, but now messagesize
> will
> value 2.
>
> Comments on the proposal:
> 1. The dpl element needs to be clearer. For instance, it seems the
> type
> is a generic one. We would need a <dplDefType> to define user custom
> DPLs, like this:
> <dplDefType name="xdbms" library="xqueryDPL.jar" lang="java">
> <dplDefType name="rubyMessages" library="message.gem" lang="ruby">
I love it! Especially that you incorporated the lang="" attribute and
language support. That's excellent.
> with that I can then use
> <dpl name="xmldb" type="xdbms">
> <argument name="xqueryFile" value="procedures.xqr"/>
> </dpl>
> <dpl name="myMessageDPL" type="rubyMessages">
> <argument name="msg1" value="user1 at pustotest.com"/>
> <argument name="msg2" value="user2 at pustotest.com"/>
> <argument name="msg3" value="user3 at pustotest.com"/>
> </dpl>
I love it! Especially that with the above syntax I can define a DPL
entirely in the TestScenario XML document.
> Note the use of the user defined type. Also note that these will call
> the setup method in each main class (need to define how to know
> which is
> the main class). And note that the setup methods use different
> arguments.
I'm not sure I follow you about knowing which main class to call.
Would you please elaborate?
>
> 2. Need to define the type of value returned by getDataIndex. Open?
> That
> means we do know there is a getDataIndex that receives an index
> parameter, but have no idea of its return value.
For 5.0 it is fine to use String as the object type for everything.
5.1 can then introduce a type="" attribute to define the simple types.
> 3. The getNextData seems a great idea to fetch from a list of data
> items, instead of accessing by a fixed index. But then, when is the
> next
> value fetched? At each iteration of the four we defined in the example
> below? At each run (each transaction) during the time the test is run?
> Does it wrap? Need to specify this a little more.
I don't think we will good answers until we see real users using
PushToTest 5. For the moment, I am fine with getNextData returning
the next data in the DPL information set and when it reaches the end
of the set it loops-back to the first data in the info set.
One more operator comes to mind:
<argument name="bod1" dpl="bodschema" value="getDataRandom"
index="messagesize"/>
This picks a random element in the DPL information set.
-Frank
>
> Comments?
>
> William.
>
> -----Original Message-----
> From: dev-bounces at lists.pushtotest.com
> [mailto:dev-bounces at lists.pushtotest.com]On Behalf Of Frank Cohen
> Sent: Wednesday, April 18, 2007 7:08 PM
> To: TestMaker Developers List
> Subject: [Dev] DPL idea
>
>
> Here's an idea for the Data Production Library (DPL) idea for the TM5
> project.
>
> The DPL is implemented in com.pushtotest.tool.dpl in Java, but you
> could also write it in a JSR 223 scripting languages
>
> DPL Has setUp, tearDown, getData, getNextData, getDataIndex methods
>
> DPL is Extensible To Define Custom Methods
>
> PushToTest 5 Will Ship With DPLs for RDBMS access, CSV File access,
> and XML file access
>
> TestScenario.xml includes global and local argument passing parameters
>
> <data>
> <dpl name="usersdb" type="rdbms">
> <argument name="query" value="select name from users"/>
> </dpl>
>
> <dpl name="bodschema" type="bod">
> <argument name="object"
> value="com.pushtotest.schemas.bods.oagis"/>
> </dpl>
> </data>
>
> <run name="doquery" testclass="com.examples.example"
> method="sqrt" langtype="java">
> <argument name="username" dpl="usersdb" value="getNextData"/>
> <argument name="bod1" dpl="bodschema" value="getDataIndex"
> index="messagesize"/>
> <argument name="bod1" dpl="bodschema" value="getDataIndex"
> index="3"/>
> </run>
>
> What do you think?
>
> -Frank
>
> --
> Frank Cohen, PushToTest, http://www.PushToTest.com, phone 408 374 7426
> TestMaker: The open-source SOA governance and test automation tool
>
>
> _______________________________________________
> Dev mailing list
> Dev at lists.pushtotest.com
> http://lists.pushtotest.com/mailman/listinfo/dev
> _______________________________________________
> Dev mailing list
> Dev at lists.pushtotest.com
> http://lists.pushtotest.com/mailman/listinfo/dev
>
--
Frank Cohen, PushToTest, http://www.PushToTest.com, phone 408 374 7426
TestMaker: The open-source SOA test automation tool
_______________________________________________
Dev mailing list
Dev at lists.pushtotest.com
http://lists.pushtotest.com/mailman/listinfo/dev
More information about the Dev
mailing list