Login | Register
My pages Projects Community openCollabNet

Discussions > dev > Re: [maxq-dev] IAgent - pluggable HTTP agents

maxq
Discussion topic

Hide all messages in topic

All messages in topic

Re: [maxq-dev] IAgent - pluggable HTTP agents

Author fcohen
Full name Frank Cohen
Date 2004-10-18 19:19:08 PDT
Message Works for me. -Frank


On Oct 18, 2004, at 6:47 PM, Oliver Bock wrote:

> On 19/10/2004, at 11:29, Frank Cohen wrote:
>>> What is the advantage of this more complicated approach? Why should
>>> the class factory for IAgents need to know about proxies? The point
>>> of the Config.java class is that it provides configuration to the
>>> other classes. What purpose does an extra layer serve?
>>
>> It's not a big point on my list, it's just that I would like to have
>> the extra flexibility to make a method call, rather than having to
>> mess with the config file (manually) and then restart.
>
> Here is how I understand Config:
>
> 1. Config loads its base configuration from maxq.properties in its
> static initialisation.
>
> 2. Whoever is invoking MaxQ can override bits of its configuration by
> calling the Config.setXxxxx() functions. Examples:
> a. When running from the command line, Main.java calls setPort() if
> it sees "--port" on the command line.
> b. When we make it work again, the Configuration dialog will also
> call setXxxx() functions.
> c. If invoking MaxQ directly from its .jar file (as I think you
> do), you can call the setXxxx() functions to override configuration
> dynamically.
>
> 3. When MaxQ runs, its classes read their configuration from the
> Config class.
>
> So I think perhaps you can get what you want by adding a
> setProxySettings() function to the Config class. This keeps all
> configuration in one place and allows you to change proxy
> configuration dynamically, without complicating the IAgent
> implementations.
>
> Does this work for you?
>
>
> Oliver
>
>
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe at maxq dot tigris dot org
> For additional commands, e-mail: dev-help at maxq dot tigris dot org
>
>
---
Frank Cohen, PushToTest, http://www.PushToTest.com, phone: 408 374 7426
Author of "Java Testing and Design: From Unit Tests to Automated Web
Tests"
from Prentice Hall, details at http://thebook.pushtotest.com


--------------------​--------------------​--------------------​---------
To unsubscribe, e-mail: dev-unsubscribe at maxq dot tigris dot org
For additional commands, e-mail: dev-help at maxq dot tigris dot org

Re: [maxq-dev] IAgent - pluggable HTTP agents

Author oliverbock
Full name Oliver Bock
Date 2004-10-18 18:47:04 PDT
Message On 19/10/2004, at 11:29, Frank Cohen wrote:
>> What is the advantage of this more complicated approach? Why should
>> the class factory for IAgents need to know about proxies? The point
>> of the Config.java class is that it provides configuration to the
>> other classes. What purpose does an extra layer serve?
>
> It's not a big point on my list, it's just that I would like to have
> the extra flexibility to make a method call, rather than having to
> mess with the config file (manually) and then restart.

Here is how I understand Config:

1. Config loads its base configuration from maxq.properties in its
static initialisation.

2. Whoever is invoking MaxQ can override bits of its configuration by
calling the Config.setXxxxx() functions. Examples:
    a. When running from the command line, Main.java calls setPort() if
it sees "--port" on the command line.
    b. When we make it work again, the Configuration dialog will also
call setXxxx() functions.
    c. If invoking MaxQ directly from its .jar file (as I think you do),
you can call the setXxxx() functions to override configuration
dynamically.

3. When MaxQ runs, its classes read their configuration from the Config
class.

So I think perhaps you can get what you want by adding a
setProxySettings() function to the Config class. This keeps all
configuration in one place and allows you to change proxy configuration
dynamically, without complicating the IAgent implementations.

Does this work for you?


    Oliver


--------------------​--------------------​--------------------​---------
To unsubscribe, e-mail: dev-unsubscribe at maxq dot tigris dot org
For additional commands, e-mail: dev-help at maxq dot tigris dot org

Re: [maxq-dev] IAgent - pluggable HTTP agents

Author fcohen
Full name Frank Cohen
Date 2004-10-18 18:29:00 PDT
Message On Oct 18, 2004, at 4:46 PM, Oliver Bock wrote:

> On 19/10/2004, at 09:40, Frank Cohen wrote:
>>>>>> 2) The interface should provide for proxy server information:
>>>>>> proxy address, port, user name, user password.
>>>>>
>>>>> Proxy information is available to implementations of IAgent (or
>>>>> whatever it will be called) via the maxq.Config class.
>>>>
>>>> It's ok with me to put this info into the config file, but I would
>>>> prefer to have an API for it too. Also, I don't see in the current
>>>> config file a facility for proxy user name and proxy user password.
>>>
>>> I'm confused because there is an API, it is the API provided by
>>> Config.java. Config.java will read the settings from
>>> maxq.properties. Is this what you meant?
>>
>> I would prefer to have an explicit method I can call to set the proxy
>> info, rather than going indirect through Config and the properties
>> file.
>
> So then the two options are:
>
> 1. During initialization, an IAgent (or whatever it will be called)
> calls Config.getProxySettings() if it supports proxies. It uses this
> information to initialize its underlying library.
>
> 2. Initialisation is a multi step process:
> a. Create IAgent-derived class.
> b. Call some setProxy() function.
> c. Call some other function so that it completes its initialisation.

Works for me.

>
> What is the advantage of this more complicated approach? Why should
> the class factory for IAgents need to know about proxies? The point
> of the Config.java class is that it provides configuration to the
> other classes. What purpose does an extra layer serve?

It's not a big point on my list, it's just that I would like to have
the extra flexibility to make a method call, rather than having to mess
with the config file (manually) and then restart.


>
>>> There is nothing in theConfig.java for proxy user name and password
>>> simply because MaxQ only supports anonymous proxies. If you do add
>>> them to Config, please also enhance the code in ProxyServer.java and
>>> HttpTestCase.java to use them so the settings are universal.
>>> Probably this is just a matter of supplying the extra information to
>>> the same APIs that are already being used.
>>
>> Doesn't Apache HTTP Client support secure proxies? I think it does.
>> In which case MaxQ should support it too.
>
> It probably does support secure proxies, and you are very welcome to
> make the change. If you do so you will also need to change the proxy
> support that is used during recording in ProxyServer.java.
>

Yep. Thanks for the pointer. I'll make the change when I get that far.
For right now I'm concentrating on getting my new generator to work.
Thanks.



>
> Oliver
>
>
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe at maxq dot tigris dot org
> For additional commands, e-mail: dev-help at maxq dot tigris dot org
>
>
---
Frank Cohen, PushToTest, http://www.PushToTest.com, phone: 408 374 7426
Author of "Java Testing and Design: From Unit Tests to Automated Web
Tests"
from Prentice Hall, details at http://thebook.pushtotest.com


--------------------​--------------------​--------------------​---------
To unsubscribe, e-mail: dev-unsubscribe at maxq dot tigris dot org
For additional commands, e-mail: dev-help at maxq dot tigris dot org

Re: [maxq-dev] IAgent - pluggable HTTP agents

Author oliverbock
Full name Oliver Bock
Date 2004-10-18 16:46:26 PDT
Message On 19/10/2004, at 09:40, Frank Cohen wrote:
>>>>> 2) The interface should provide for proxy server information:
>>>>> proxy address, port, user name, user password.
>>>>
>>>> Proxy information is available to implementations of IAgent (or
>>>> whatever it will be called) via the maxq.Config class.
>>>
>>> It's ok with me to put this info into the config file, but I would
>>> prefer to have an API for it too. Also, I don't see in the current
>>> config file a facility for proxy user name and proxy user password.
>>
>> I'm confused because there is an API, it is the API provided by
>> Config.java. Config.java will read the settings from
>> maxq.properties. Is this what you meant?
>
> I would prefer to have an explicit method I can call to set the proxy
> info, rather than going indirect through Config and the properties
> file.

So then the two options are:

1. During initialization, an IAgent (or whatever it will be called)
calls Config.getProxySettings() if it supports proxies. It uses this
information to initialize its underlying library.

2. Initialisation is a multi step process:
   a. Create IAgent-derived class.
   b. Call some setProxy() function.
   c. Call some other function so that it completes its initialisation.

What is the advantage of this more complicated approach? Why should
the class factory for IAgents need to know about proxies? The point of
the Config.java class is that it provides configuration to the other
classes. What purpose does an extra layer serve?

>> There is nothing in theConfig.java for proxy user name and password
>> simply because MaxQ only supports anonymous proxies. If you do add
>> them to Config, please also enhance the code in ProxyServer.java and
>> HttpTestCase.java to use them so the settings are universal.
>> Probably this is just a matter of supplying the extra information to
>> the same APIs that are already being used.
>
> Doesn't Apache HTTP Client support secure proxies? I think it does. In
> which case MaxQ should support it too.

It probably does support secure proxies, and you are very welcome to
make the change. If you do so you will also need to change the proxy
support that is used during recording in ProxyServer.java.


   Oliver


--------------------​--------------------​--------------------​---------
To unsubscribe, e-mail: dev-unsubscribe at maxq dot tigris dot org
For additional commands, e-mail: dev-help at maxq dot tigris dot org

Re: [maxq-dev] IAgent - pluggable HTTP agents

Author fcohen
Full name Frank Cohen
Date 2004-10-18 16:40:42 PDT
Message >
>
>>>> 2) The interface should provide for proxy server information: proxy
>>>> address, port, user name, user password.
>>>
>>> Proxy information is available to implementations of IAgent (or
>>> whatever it will be called) via the maxq.Config class.
>>
>> It's ok with me to put this info into the config file, but I would
>> prefer to have an API for it too. Also, I don't see in the current
>> config file a facility for proxy user name and proxy user password.
>
> I'm confused because there is an API, it is the API provided by
> Config.java. Config.java will read the settings from maxq.properties.
> Is this what you meant?

I would prefer to have an explicit method I can call to set the proxy
info, rather than going indirect through Config and the properties
file.


>
> There is nothing in theConfig.java for proxy user name and password
> simply because MaxQ only supports anonymous proxies. If you do add
> them to Config, please also enhance the code in ProxyServer.java and
> HttpTestCase.java to use them so the settings are universal.
> Probably this is just a matter of supplying the extra information to
> the same APIs that are already being used.
>

Doesn't Apache HTTP Client support secure proxies? I think it does. In
which case MaxQ should support it too.


>
> Oliver
>
>
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe at maxq dot tigris dot org
> For additional commands, e-mail: dev-help at maxq dot tigris dot org
>
>
---
Frank Cohen, PushToTest, http://www.PushToTest.com, phone: 408 374 7426
Author of "Java Testing and Design: From Unit Tests to Automated Web
Tests"
from Prentice Hall, details at http://thebook.pushtotest.com


--------------------​--------------------​--------------------​---------
To unsubscribe, e-mail: dev-unsubscribe at maxq dot tigris dot org
For additional commands, e-mail: dev-help at maxq dot tigris dot org

Re: [maxq-dev] IAgent - pluggable HTTP agents

Author oliverbock
Full name Oliver Bock
Date 2004-10-18 16:33:03 PDT
Message On 19/10/2004, at 09:19, Frank Cohen wrote:
>> On 19/10/2004, at 02:41, Frank Cohen wrote:
>>> 1) I use the term "agent" in TestMaker a lot to encompass the
>>> business logic in a test. The test agent embodies the behavior of an
>>> archetypal user. (I talk about this a lot in my book Java Testing
>>> and Design, see http://thebook.pushtotest.com) So I would prefer to
>>> call the interface something other than 'agent'. How about
>>> 'connection'?
>>
>> In the terminology of the HTTP standard, browsers are known as "user
>> agents", which is where I got the name. I felt that "browser" was
>> too literal. I think "connection" it is too general---applying
>> equally well to recording as playing---and is thus not very
>> memorable. Any other suggestions?
>
> How about host, client, consumer... (I don't feel strongly about this.)

Hmm, I think I'll hold out for further suggestions. This is only a
proposal so far.

>>> 2) The interface should provide for proxy server information: proxy
>>> address, port, user name, user password.
>>
>> Proxy information is available to implementations of IAgent (or
>> whatever it will be called) via the maxq.Config class.
>
> It's ok with me to put this info into the config file, but I would
> prefer to have an API for it too. Also, I don't see in the current
> config file a facility for proxy user name and proxy user password.

I'm confused because there is an API, it is the API provided by
Config.java. Config.java will read the settings from maxq.properties.
Is this what you meant?

There is nothing in theConfig.java for proxy user name and password
simply because MaxQ only supports anonymous proxies. If you do add
them to Config, please also enhance the code in ProxyServer.java and
HttpTestCase.java to use them so the settings are universal. Probably
this is just a matter of supplying the extra information to the same
APIs that are already being used.


    Oliver


--------------------​--------------------​--------------------​---------
To unsubscribe, e-mail: dev-unsubscribe at maxq dot tigris dot org
For additional commands, e-mail: dev-help at maxq dot tigris dot org

Re: [maxq-dev] IAgent - pluggable HTTP agents

Author fcohen
Full name Frank Cohen
Date 2004-10-18 16:19:00 PDT
Message On Oct 18, 2004, at 3:00 PM, Oliver Bock wrote:

> On 19/10/2004, at 02:41, Frank Cohen wrote:
>> 1) I use the term "agent" in TestMaker a lot to encompass the
>> business logic in a test. The test agent embodies the behavior of an
>> archetypal user. (I talk about this a lot in my book Java Testing and
>> Design, see http://thebook.pushtotest.com) So I would prefer to call
>> the interface something other than 'agent'. How about 'connection'?
>
> In the terminology of the HTTP standard, browsers are known as "user
> agents", which is where I got the name. I felt that "browser" was too
> literal. I think "connection" it is too general---applying equally
> well to recording as playing---and is thus not very memorable. Any
> other suggestions?
>

How about host, client, consumer... (I don't feel strongly about this.)



>> 2) The interface should provide for proxy server information: proxy
>> address, port, user name, user password.
>
> Proxy information is available to implementations of IAgent (or
> whatever it will be called) via the maxq.Config class.
>

It's ok with me to put this info into the config file, but I would
prefer to have an API for it too. Also, I don't see in the current
config file a facility for proxy user name and proxy user password.


>> 3) The interface should have timing value getters. For example,
>> totaltime to make the request, set-up-time to marshall the request.
>
> Timers are not required by MaxQ or by the scripts MaxQ generates
> therefore I have not included them in the interface. If you build an
> IAgent using TOOL then you can include timers, and your scripts will
> be able to use them. The interface specifies the minimum required of
> agents, but does not limit the member functions exposed. We can do
> this because we will dynamically make the agent class the base class
> of the test.
>
> I am adamant about this because I want to allow different agents to
> provide different features without polluting the core or the
> traditional features of MaxQ. Also, I think that timing with
> sufficient granularity for use in load testing could be added to an
> extension Jython class without requiring support from the agent. When
> performing load testing you are looking to see when user response
> times increase to levels that are irritating to real users. Seconds
> are a problem, but the difference between 15 microseconds and 18 is
> irrelevant. This base class would sit in between a test class and
> PyHttpTestCase in the same way that my VerifyTest.py provides the
> facility to check returned HTML without affecting anything else.
>

No prob Oliver.

>
> Oliver
>
>
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe at maxq dot tigris dot org
> For additional commands, e-mail: dev-help at maxq dot tigris dot org
>
>
---
Frank Cohen, PushToTest, http://www.PushToTest.com, phone: 408 374 7426
Author of "Java Testing and Design: From Unit Tests to Automated Web
Tests"
from Prentice Hall, details at http://thebook.pushtotest.com


--------------------​--------------------​--------------------​---------
To unsubscribe, e-mail: dev-unsubscribe at maxq dot tigris dot org
For additional commands, e-mail: dev-help at maxq dot tigris dot org

Re: [maxq-dev] IAgent - pluggable HTTP agents

Author oliverbock
Full name Oliver Bock
Date 2004-10-18 15:19:16 PDT
Message On 19/10/2004, at 04:02, hdara at primavera dot com wrote:
> Good idea. In addition to Frank's comments,
>
> - Why is getResponseText returning int? I presume it is simply a
> mistake,
> but I would make it return a byte array.

I did initially think it should be a String because this makes things
simpler and because the cost of unnecessarily converting to a String is
small enough to be irrelevant in comparison to the time we must wait
for network connections. However there may also be an issue with
non-single-byte character sets and the chance that the response is a
binary file so I think you are right. byte[] it is. I have renamed
the function to getResponseBytes() and think that the Jython base class
will provide a response() function that converts it to a PyString.
(For a moment there I was tempted to call it getResponseText(). I
think I am being infected by the unpleasant preference Java programmers
have for long names. I think this would be a mistake in Python
interfaces; Python thrives on concision.)

> - How about allowing these methods to throw some exceptions, such as
> IOException, or network related ones? You could also think about
> create a
> wrapper exception as part of the interface.

Another good point. get() and post() now throw Exception. If
implementors want to convert their native exceptions into something
more readable then they should use Utils.UserException.

> - get() and post() accepting Object type array is a bit obscure. How
> would
> one pass name and value pairs? Also, can you pass null if you don't
> have
> any parameters? Could you clarify on this?

It now reads:

  params Must contain an array of PyTuples. Each PyTuple contains a
parameter name and a parameter value. Null will be interpreted as an
empty list of parameters.

My intention is that this data structure can be written in Jython using
this compact syntax:

[('name', 'value'), ('name2', 'value2')...]

> - How about having setters for configuring proxy information too (Frank
> just asked for getters).

Proxy configuration is available reading in maxq.Config. This is
simpler than requiring whoever constructs the agent to call a set
function.


    Oliver


--------------------​--------------------​--------------------​---------
To unsubscribe, e-mail: dev-unsubscribe at maxq dot tigris dot org
For additional commands, e-mail: dev-help at maxq dot tigris dot org

Re: [maxq-dev] IAgent - pluggable HTTP agents

Author oliverbock
Full name Oliver Bock
Date 2004-10-18 15:00:14 PDT
Message On 19/10/2004, at 02:41, Frank Cohen wrote:
> 1) I use the term "agent" in TestMaker a lot to encompass the business
> logic in a test. The test agent embodies the behavior of an archetypal
> user. (I talk about this a lot in my book Java Testing and Design, see
> http://thebook.pushtotest.com) So I would prefer to call the interface
> something other than 'agent'. How about 'connection'?

In the terminology of the HTTP standard, browsers are known as "user
agents", which is where I got the name. I felt that "browser" was too
literal. I think "connection" it is too general---applying equally
well to recording as playing---and is thus not very memorable. Any
other suggestions?

> 2) The interface should provide for proxy server information: proxy
> address, port, user name, user password.

Proxy information is available to implementations of IAgent (or
whatever it will be called) via the maxq.Config class.

> 3) The interface should have timing value getters. For example,
> totaltime to make the request, set-up-time to marshall the request.

Timers are not required by MaxQ or by the scripts MaxQ generates
therefore I have not included them in the interface. If you build an
IAgent using TOOL then you can include timers, and your scripts will be
able to use them. The interface specifies the minimum required of
agents, but does not limit the member functions exposed. We can do
this because we will dynamically make the agent class the base class of
the test.

I am adamant about this because I want to allow different agents to
provide different features without polluting the core or the
traditional features of MaxQ. Also, I think that timing with sufficient
granularity for use in load testing could be added to an extension
Jython class without requiring support from the agent. When performing
load testing you are looking to see when user response times increase
to levels that are irritating to real users. Seconds are a problem,
but the difference between 15 microseconds and 18 is irrelevant. This
base class would sit in between a test class and PyHttpTestCase in the
same way that my VerifyTest.py provides the facility to check returned
HTML without affecting anything else.


    Oliver


--------------------​--------------------​--------------------​---------
To unsubscribe, e-mail: dev-unsubscribe at maxq dot tigris dot org
For additional commands, e-mail: dev-help at maxq dot tigris dot org

Re: [maxq-dev] IAgent - pluggable HTTP agents

Author hdara at primavera dot com
Full name hdara at primavera dot com
Date 2004-10-18 11:02:51 PDT
Message Good idea. In addition to Frank's comments,

- Why is getResponseText returning int? I presume it is simply a mistake,
but I would make it return a byte array.
- How about allowing these methods to throw some exceptions, such as
IOException, or network related ones? You could also think about create a
wrapper exception as part of the interface.
- get() and post() accepting Object type array is a bit obscure. How would
one pass name and value pairs? Also, can you pass null if you don't have
any parameters? Could you clarify on this?
- How about having setters for configuring proxy information too (Frank
just asked for getters).

Thanks,
Hari

Oliver Bock <oliver at g7 dot org> wrote on 10/18/2004 01:14:06 AM:

> Here is a first suggestion for a Java interface that identifies the
> minimum facilities that must be provided by HTTP libraries. This is
> motivated by a desire to experiment with HttpUnit without throwing away
> HttpClient. It may also be a useful way for Frank to invoke his own
> libraries while keeping MaxQ "clean".
>
> My intention is that the PyHttpTestCase would be extended to provide
> the helper methods currently provided by HttpTestCase, without knowing
> which HTTP library was in use. Examples of the helper functions
> include assert(), userConfirm(), responseContains(), etc.
>
> Thoughts?
>
>
> Oliver
>
> --
> package com.bitmechanic.maxq.agent;
>
> /**
> * This interface must be implemented by classes that act as agents
> (virtual
> * web browsers) for MaxQ scripts. An agent is created when a script
> is run.
> * As a minimum, it must support HTTP GET, POST and cookies.
> *
> * This interface is simpler than that typically provided by agent
> * implementations such as Jakarta HttpClient and HttpUnit. This keeps

> MaxQ
> * scripts simple. Implementors may expose other methods for use by
> more
> * sophisticated users who do not mind that their scripts will only
> work with
> * one agent. (e.g users who want HttpUnit's ability to look into the
> response
> * body.)
> *
> * MaxQ will "mix in" an implementations of this interface with the
> Jython base
> * class it provides for test (PyHttpTestCase). That is, it will
> dynamically
> * use the IAgent implementation as the top-level base class for the
> MaxQ
> * scripts.
> */
> public interface IAgent {
> /**
> * Performs an HTTP GET
> */
> public void get(String url, Object[] params);
>
> /**
> * Performs an HTTP POST
> */
> public void get(String url, Object[] params)
>
> /*
> * The headers from the response to the previous request.
> */
> public PyDictionary getResponseHeader();
>
> /*
> * The HTTP response code from the previous request (get()/post()).
> */
> public int getResponseCode();
>
> /*
> * The body of the response from the previous request
> (get()/post()).
> */
> public int getResponseText();
> }
>
>
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe at maxq dot tigris dot org
> For additional commands, e-mail: dev-help at maxq dot tigris dot org
>


--------------------​--------------------​--------------------​---------
To unsubscribe, e-mail: dev-unsubscribe at maxq dot tigris dot org
For additional commands, e-mail: dev-help at maxq dot tigris dot org

Re: [maxq-dev] IAgent - pluggable HTTP agents

Author fcohen
Full name Frank Cohen
Date 2004-10-18 09:41:39 PDT
Message Good thoughts Oliver. Some feedback:

1) I use the term "agent" in TestMaker a lot to encompass the business
logic in a test. The test agent embodies the behavior of an archetypal
user. (I talk about this a lot in my book Java Testing and Design, see
http://thebook.pushtotest.com) So I would prefer to call the interface
something other than 'agent'. How about 'connection'?

2) The interface should provide for proxy server information: proxy
address, port, user name, user password.

3) The interface should have timing value getters. For example,
totaltime to make the request, set-up-time to marshall the request

-Frank



On Oct 18, 2004, at 1:14 AM, Oliver Bock wrote:

> Here is a first suggestion for a Java interface that identifies the
> minimum facilities that must be provided by HTTP libraries. This is
> motivated by a desire to experiment with HttpUnit without throwing
> away HttpClient. It may also be a useful way for Frank to invoke his
> own libraries while keeping MaxQ "clean".
>
> My intention is that the PyHttpTestCase would be extended to provide
> the helper methods currently provided by HttpTestCase, without knowing
> which HTTP library was in use. Examples of the helper functions
> include assert(), userConfirm(), responseContains(), etc.
>
> Thoughts?
>
>
> Oliver
>
> --
> package com.bitmechanic.maxq.agent;
>
> /**
> * This interface must be implemented by classes that act as agents
> (virtual
> * web browsers) for MaxQ scripts. An agent is created when a script
> is run.
> * As a minimum, it must support HTTP GET, POST and cookies.
> *
> * This interface is simpler than that typically provided by agent
> * implementations such as Jakarta HttpClient and HttpUnit. This
> keeps MaxQ
> * scripts simple. Implementors may expose other methods for use by
> more
> * sophisticated users who do not mind that their scripts will only
> work with
> * one agent. (e.g users who want HttpUnit's ability to look into the
> response
> * body.)
> *
> * MaxQ will "mix in" an implementations of this interface with the
> Jython base
> * class it provides for test (PyHttpTestCase). That is, it will
> dynamically
> * use the IAgent implementation as the top-level base class for the
> MaxQ
> * scripts.
> */
> public interface IAgent {
> /**
> * Performs an HTTP GET
> */
> public void get(String url, Object[] params);
>
> /**
> * Performs an HTTP POST
> */
> public void get(String url, Object[] params)
>
> /*
> * The headers from the response to the previous request.
> */
> public PyDictionary getResponseHeader();
>
> /*
> * The HTTP response code from the previous request (get()/post()).
> */
> public int getResponseCode();
>
> /*
> * The body of the response from the previous request
> (get()/post()).
> */
> public int getResponseText();
> }
>
>
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe at maxq dot tigris dot org
> For additional commands, e-mail: dev-help at maxq dot tigris dot org
>
>
---
Frank Cohen, PushToTest, http://www.PushToTest.com, phone: 408 374 7426
Author of "Java Testing and Design: From Unit Tests to Automated Web
Tests"
from Prentice Hall, details at http://thebook.pushtotest.com


--------------------​--------------------​--------------------​---------
To unsubscribe, e-mail: dev-unsubscribe at maxq dot tigris dot org
For additional commands, e-mail: dev-help at maxq dot tigris dot org

[maxq-dev] IAgent - pluggable HTTP agents

Author oliverbock
Full name Oliver Bock
Date 2004-10-18 01:14:06 PDT
Message Here is a first suggestion for a Java interface that identifies the
minimum facilities that must be provided by HTTP libraries. This is
motivated by a desire to experiment with HttpUnit without throwing away
HttpClient. It may also be a useful way for Frank to invoke his own
libraries while keeping MaxQ "clean".

My intention is that the PyHttpTestCase would be extended to provide
the helper methods currently provided by HttpTestCase, without knowing
which HTTP library was in use. Examples of the helper functions
include assert(), userConfirm(), responseContains(), etc.

Thoughts?


    Oliver

--
package com.bitmechanic.maxq.agent;

/**
  * This interface must be implemented by classes that act as agents
(virtual
  * web browsers) for MaxQ scripts. An agent is created when a script
is run.
  * As a minimum, it must support HTTP GET, POST and cookies.
  *
  * This interface is simpler than that typically provided by agent
  * implementations such as Jakarta HttpClient and HttpUnit. This keeps
MaxQ
  * scripts simple. Implementors may expose other methods for use by
more
  * sophisticated users who do not mind that their scripts will only
work with
  * one agent. (e.g users who want HttpUnit's ability to look into the
response
  * body.)
  *
  * MaxQ will "mix in" an implementations of this interface with the
Jython base
  * class it provides for test (PyHttpTestCase). That is, it will
dynamically
  * use the IAgent implementation as the top-level base class for the
MaxQ
  * scripts.
  */
public interface IAgent {
     /**
      * Performs an HTTP GET
      */
     public void get(String url, Object[] params);

     /**
      * Performs an HTTP POST
      */
     public void get(String url, Object[] params)

     /*
      * The headers from the response to the previous request.
      */
     public PyDictionary getResponseHeader();

     /*
      * The HTTP response code from the previous request (get()/post()).
      */
     public int getResponseCode();

     /*
      * The body of the response from the previous request
(get()/post()).
      */
     public int getResponseText();
}


--------------------​--------------------​--------------------​---------
To unsubscribe, e-mail: dev-unsubscribe at maxq dot tigris dot org
For additional commands, e-mail: dev-help at maxq dot tigris dot org
Messages per page: