Hi Vincent,
I've been thinking of an approach of using system properties as configurable
parameters. This is hardly regular because of low parameter localization. I
mean that if you want use some system properties as user name or passsword -
there're no problems! There're global parameters and must be accessible from
anywhere by any aplication. But in the example I'd given I showed how
_local_ parameters should be specified. The only test knows about what
optional parameters may be passed!
Let me clarify an example (my recent one is rather abstract, I think).
Imagine, you should write Cactus test to test some action from
web-page.There's no matter how it is mapped between each other. Just think
it's done. Let such test be full text search over database by a keyword
specified by user on the web-page. If you hardcode this keyword within a
test via
req.addParameter("keywords", "cactus");
.. it will not be configurable. So, you test is strongly _deterministic_.
Whenever you launch it, it will bring the same result. As for automated
testing of whole application, it is acceptable. But I try to promote the
idea of customizing tests in order to increase their flexibility.
Now imagine you may launch test not only by default (internally declared)
keyword but also by keyword you specify in the address bar of your browser
(or in another way). At least, it excludes the need to recompile and
redeploy the entire application. If keyword is absent, default is used.
Cactus faq contains a question of how possible to parametrize tests. Among
the answers there's also (apart from System.getProperty()) utilization of
cactus.properties file where optional parameters are specified. I reckon
that such globalization of local parameters is irregular.
> An interesting idea. You have to remember that calling cactus tests from
> a web browser is just one way of doing it. There are lots of other front
> ends: Ant, Maven, Eclipse, manually from command line, etc. Thus the
> solution must be able to work for all these situations.
There's a redirection occurs after test lauhcned. The idea is to transfer
all the custom parameters to destination servlet without a modification.
Currently they are lost. To simplify implementation, raw query string (which
is passed to TestRunner and by which test is lauhched) is enough to pass to
test request in destination servlet.
What do you think about test customization now?
Greetings,
Ivan.
----- Original Message -----
From: "Vincent Massol" <[EMAIL PROTECTED]>
To: "'Cactus Developers List'" <[EMAIL PROTECTED]>
Sent: Monday, November 10, 2003 12:02 PM
Subject: RE: Running cactus test from web-browser with custom parameters
> Hi Ivan,
>
> An interesting idea. You have to remember that calling cactus tests from
> a web browser is just one way of doing it. There are lots of other front
> ends: Ant, Maven, Eclipse, manually from command line, etc. Thus the
> solution must be able to work for all these situations.
>
> ATM, there are already ways to pass parameters to a cactus test case.
> Here's how you can currently do it:
>
> public void beginXXXX(WebRequest req)
> {
> req.addParameter("param1", System.getProperty("param1"));
> [...]
> }
>
> Thus, I believe the best solution would be to modify the Cactus
> ServletTestRunner class so that it adds all the HTTP parameters as
> System properties. That will allow your test case to retrieve these
> properties as shown above.
>
> It has the advantage that you'll also be able to use the other front
> ends for your test and it'll still work (provided you also configure the
> other front ends to pass these parameters).
>
> Would that do it for you?
>
> Thanks
> -Vincent
>
> > -----Original Message-----
> > From: Ivan Kaschenko [mailto:[EMAIL PROTECTED]
> > Sent: 10 November 2003 09:56
> > To: Cactus Developers List
> > Subject: Running cactus test from web-browser with custom parameters
> >
> > Hi, guys!
> >
> > I have a question but couldn't find a proper location to place it in.
> > Would
> > you be so kind to skim it though and, maybe, give me some links where
> I
> > can
> > get information I need?
> >
> > As specified in Cactus documentation, running test from web-browser
> must
> > be
> > performed as follows:
> >
> > http://server:port/webapp/ServletTestRunner?suite=testcasename
> >
> > It would be extremely convinient to parametrize tests from such
> requests.
> > I
> > mean adding parameters list in a way as http GET request syntax
> specifies:
> >
> >
> http://server:port/webapp/ServletTestRunner?suite=testcasename¶m1=va
> lu
> > e1
> > ¶m2=value2 etc.
> >
> > Optional parameters are custom ones and must be passes to request
> (within
> > test) without any modification. They must be accessible via
> > WebRequest.getParameter(String) call. Default value must be provided.
> For
> > example:
> >
> > public void beginXXX(WebRequest theRequest) throws Exception {
> > String param1 = theRequest.getParameter("search_keyword");
> > if (param1 == null)
> > theRequest.addParameter("search_keyword", "Cactus");
> > [...]
> > }
> >
> > General benefit is test parametrization which doesn't require
> recompiling
> > and redeploying web-application (you understand it may be
> time-consuming).
> >
> > Greetings,
> > Ivan.
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
