Running cactus test from web-browser with custom parameters

[Ivan Kaschenko <om...@tut.by>]

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&param1=value1
&param2=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: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org

Re: Running cactus test from web-browser with custom parameters

[Ivan Kaschenko <om...@tut.by>]

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" <vm...@pivolis.com>
To: "'Cactus Developers List'" <ca...@jakarta.apache.org>
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:om600@tut.by]
> > 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&param1=va
> lu
> > e1
> > &param2=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: cactus-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org

RE: Running cactus test from web-browser with custom parameters

[Vincent Massol <vm...@pivolis.com>]

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:om600@tut.by]
> 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&param1=va
lu
> e1
> &param2=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: cactus-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: cactus-dev-help@jakarta.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org