You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by "Noel J. Bergman" <no...@devtech.com> on 2002/10/22 04:47:38 UTC
IMAP (and other) testing
Nathan,
Yes, you are reading me correctly
FWIW, I've exchanged some thoughts with the BSF folks (should be a Jakarta
project within two weeks), and spoke with Paul Hammant last night about
Beanshell. I think that we can make good use of those script enabling
technologies to build a test bed, and I am also thinking of authoring a
BSFMatcher and BSFMailet to allow those items to be written as scripts. I'm
going to put off the latter until after we get a chance to discuss Mailet
API v2, just because I don't know what impact the API changes will have, but
I did want to mention the idea as a "heads up" for comments.
Actually, in terms of a test bed, I think that there are two areas: one is
the external test driver, the other would be a facility for running test
scripts within James, itself, to test integrated operation internally. The
one we're focusing on right now is the external driver.
--- Noel
-----Original Message-----
From: Nathan Carter [mailto:nathancarter@gmx.net]
Sent: Monday, October 21, 2002 22:17
To: James Developers List
Subject: Re: Steps to get IMAP starting
Harmeet Bedi wrote:
> I have started thinking about writing some tests for IMAP. I was thinking
> that tests that work with other IMAP Server would be a good way to
validate
> RFC match.
Yes, but as Noel said well last week, testing real-world client
compliance and RFC compliance are somewhat separate things. I've begun
to write up some rough plans for the testing architecture that he was
talking about, and I think that a careful reading of the RFCs to produce
functional tests will give us excellent coverage for the full range of
RFC functionality. As a separate step, we will need to record scripts
of client server behavior between existing clients and existing IMAP
servers, and find a way to incorporate the peculiarities we find into
our testing infrastructure.
Noel, am I reading you right? Corrections welcome :)
-Nathan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: IMAP (and other) testing
Posted by Harmeet Bedi <ha...@kodemuse.com>.
----- Original Message -----
From: "Nathan Carter" <na...@gmx.net>
> So it looks like we must go with the proxy solution for that part of our
> testing . . .
I was thinking about nat like fowarding proxy or a socks proxy may be good.
Log files for email clients etc. also work well.
Either way we should try to get some good record and replay scripts and then
build IMAP Server to validate against them.
Added the first one to test for login(bad and good) and status of "INBOX".
imaplogin.protocolsession is derived from mail client log.
Harmeet
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: IMAP (and other) testing
Posted by Nathan Carter <na...@gmx.net>.
The tcpdump stuff (based on the jpcap project(s)) doesn't look promising
- I've spent a few hours this afternoon looking at it and jpcap is
forked all over the place - there is a project in Japan, one on
sourceforge, as well as others - and it doesn't really run on Windows
that well, or so it seems.
So it looks like we must go with the proxy solution for that part of our
testing . . .
-Nathan
Harmeet Bedi wrote:
> ----- Original Message -----
> From: "Nathan Carter" <na...@gmx.net>
>
>>OK, so:
>>
>>1) external tests = functional tests which mimic client behavior
>>according to RFC or a "recorded script"
>>
>>2) internal tests = unit tests which largely follow James
>>class/component structure?
>>
>>And I'm thinking that load/stress tests should share a lot of code with
>>1), so that even load/stress tests are less ad hoc
>>
>>Thoughts?
>
>
> Good point added parameters to ProtocolSimulator to specify simulation
> iterations and number of parallel worker threads.
>
>
>
>>As a separate step, we will need to record scripts
>>of client server behavior between existing clients and existing IMAP
>>servers, and find a way to incorporate the peculiarities we find into
>>our testing infrastructure.
>
>
> Started doing that a bit. Downloaded ipswitch IMAP server. How is your
> tcpdump going. It would be useful. Alternatively I have been thinking of a
> simple foward and record communication proxy.
>
> Harmeet
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: IMAP (and other) testing
Posted by Harmeet Bedi <ha...@kodemuse.com>.
----- Original Message -----
From: "Nathan Carter" <na...@gmx.net>
> OK, so:
>
> 1) external tests = functional tests which mimic client behavior
> according to RFC or a "recorded script"
>
> 2) internal tests = unit tests which largely follow James
> class/component structure?
>
> And I'm thinking that load/stress tests should share a lot of code with
> 1), so that even load/stress tests are less ad hoc
>
> Thoughts?
Good point added parameters to ProtocolSimulator to specify simulation
iterations and number of parallel worker threads.
> As a separate step, we will need to record scripts
> of client server behavior between existing clients and existing IMAP
> servers, and find a way to incorporate the peculiarities we find into
> our testing infrastructure.
Started doing that a bit. Downloaded ipswitch IMAP server. How is your
tcpdump going. It would be useful. Alternatively I have been thinking of a
simple foward and record communication proxy.
Harmeet
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: IMAP (and other) testing
Posted by Nathan Carter <na...@gmx.net>.
Noel,
Noel J. Bergman wrote:
> Nathan,
>
> Yes, you are reading me correctly
>
> FWIW, I've exchanged some thoughts with the BSF folks (should be a Jakarta
> project within two weeks), and spoke with Paul Hammant last night about
> Beanshell. I think that we can make good use of those script enabling
> technologies to build a test bed, and I am also thinking of authoring a
> BSFMatcher and BSFMailet to allow those items to be written as scripts. I'm
> going to put off the latter until after we get a chance to discuss Mailet
> API v2, just because I don't know what impact the API changes will have, but
> I did want to mention the idea as a "heads up" for comments.
>
> Actually, in terms of a test bed, I think that there are two areas: one is
> the external test driver, the other would be a facility for running test
> scripts within James, itself, to test integrated operation internally. The
> one we're focusing on right now is the external driver.
>
OK, so:
1) external tests = functional tests which mimic client behavior
according to RFC or a "recorded script"
2) internal tests = unit tests which largely follow James
class/component structure?
And I'm thinking that load/stress tests should share a lot of code with
1), so that even load/stress tests are less ad hoc.
Thoughts?
-Nathan
> --- Noel
>
> -----Original Message-----
> From: Nathan Carter [mailto:nathancarter@gmx.net]
> Sent: Monday, October 21, 2002 22:17
> To: James Developers List
> Subject: Re: Steps to get IMAP starting
>
> Harmeet Bedi wrote:
>
>>I have started thinking about writing some tests for IMAP. I was thinking
>>that tests that work with other IMAP Server would be a good way to
>
> validate
>
>>RFC match.
>
>
> Yes, but as Noel said well last week, testing real-world client
> compliance and RFC compliance are somewhat separate things. I've begun
> to write up some rough plans for the testing architecture that he was
> talking about, and I think that a careful reading of the RFCs to produce
> functional tests will give us excellent coverage for the full range of
> RFC functionality. As a separate step, we will need to record scripts
> of client server behavior between existing clients and existing IMAP
> servers, and find a way to incorporate the peculiarities we find into
> our testing infrastructure.
>
> Noel, am I reading you right? Corrections welcome :)
>
> -Nathan
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: IMAP (and other) testing
Posted by Danny Angus <da...@apache.org>.
> Mailet
> API v2, just because I don't know what impact the API changes
> will have
IMO the changes will hide Avalon from Mailets, provide repository services through the mailet context, add serialisable attributes to Mails, and enhance logging.
Related changes to James will include more user friendly and secure classloading provision for mailets, and bounce functionality refactored into a mailet application.
d.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>