You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Richard Dallaway <ri...@dallaway.com> on 2003/02/07 12:29:12 UTC
[latka] ways to handle common tests
Does anyone have any ideas on good ways to handle units of common test
code in Latka?
For example: login to an application. You may need to have a test user
log in to an application before running certain tests, and it would be
good to be able to code this common HTTP request in just one place and
reuse it across many tests. E.g.,
<session>
LOGIN-MAGIC-HERE
<request>
... other tests here
</request> ....
</session>
It's hackable (maybe) with a DTD/entity ("&login"), but I'm not
comfortable with that. I wondering if there's a mechanism for some kind
of "include" expression? Something like: <include file="login.xml"/>
for the login magic?
Another option might be to call the login magic from a JUnit setUp()
method, but it seems more natural (to me) to have it in a Latka .xml file.
Any thoughts would be much appreciated
Richard
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [latka] ways to handle common tests
Posted by Morgan Delagrange <md...@yahoo.com>.
My company has a large body of common tests, and we
declare those tests via a DTD. I don't think it's a
hack, it's just XML. :)
- Morgan
--- Richard Dallaway <ri...@dallaway.com> wrote:
> Does anyone have any ideas on good ways to handle
> units of common test
> code in Latka?
>
> For example: login to an application. You may need
> to have a test user
> log in to an application before running certain
> tests, and it would be
> good to be able to code this common HTTP request in
> just one place and
> reuse it across many tests. E.g.,
>
> <session>
> LOGIN-MAGIC-HERE
> <request>
> ... other tests here
> </request> ....
> </session>
>
> It's hackable (maybe) with a DTD/entity ("&login"),
> but I'm not
> comfortable with that. I wondering if there's a
> mechanism for some kind
> of "include" expression? Something like: <include
> file="login.xml"/>
> for the login magic?
>
> Another option might be to call the login magic from
> a JUnit setUp()
> method, but it seems more natural (to me) to have it
> in a Latka .xml file.
>
> Any thoughts would be much appreciated
> Richard
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> commons-dev-help@jakarta.apache.org
>
=====
Morgan Delagrange
http://jakarta.apache.org/taglibs
http://jakarta.apache.org/commons
http://axion.tigris.org
http://jakarta.apache.org/watchdog
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [latka] ways to handle common tests
Posted by Janek Bogucki <ya...@studylink.com>.
Hi Richard,
> Does anyone have any ideas on good ways to handle units of common test
> code in Latka?
>
> For example: login to an application. You may need to have a test user
> log in to an application before running certain tests, and it would be
> good to be able to code this common HTTP request in just one place and
> reuse it across many tests. E.g.,
>
> <session>
> LOGIN-MAGIC-HERE
> <request>
> ... other tests here
> </request> ....
> </session>
>
> It's hackable (maybe) with a DTD/entity ("&login"), but I'm not
> comfortable with that. I wondering if there's a mechanism for some kind
> of "include" expression? Something like: <include file="login.xml"/>
> for the login magic?
>
> Another option might be to call the login magic from a JUnit setUp()
> method, but it seems more natural (to me) to have it in a Latka .xml file.
>
> Any thoughts would be much appreciated
> Richard
Why not use an entity (as you suggest)? It's functionally indentical to the
<include> element.
Otherwise, you may want to explore the Jelly integration work, available via
CVS, which as far as I know will give you some options to do this sort of
thing in a scripting fashion.
Janek
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [latka] ways to handle common tests
Posted by Kurt Schrader <ks...@karmalab.org>.
I write my Latka tests as Jelly file and then run them in order using
somthing like this:
<j:jelly xmlns:j="jelly:core">
<j:include uri="RegisterStudent.jelly"/>
<j:include uri="ApproveRegistrantTest.jelly"/>
<j:include uri="DeleteRegistrantTest.jelly"/>
</j:jelly>
I'm assuming that something like that would work for what you want to do.
-Kurt
On Fri, 7 Feb 2003, Richard Dallaway wrote:
> Does anyone have any ideas on good ways to handle units of common test
> code in Latka?
>
> For example: login to an application. You may need to have a test user
> log in to an application before running certain tests, and it would be
> good to be able to code this common HTTP request in just one place and
> reuse it across many tests. E.g.,
>
> <session>
> LOGIN-MAGIC-HERE
> <request>
> ... other tests here
> </request> ....
> </session>
>
> It's hackable (maybe) with a DTD/entity ("&login"), but I'm not
> comfortable with that. I wondering if there's a mechanism for some kind
> of "include" expression? Something like: <include file="login.xml"/>
> for the login magic?
>
> Another option might be to call the login magic from a JUnit setUp()
> method, but it seems more natural (to me) to have it in a Latka .xml file.
>
> Any thoughts would be much appreciated
> Richard
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org