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 2003/01/02 14:29:34 UTC

Python for testing

> The first thing I'd like to write [NNTP] tests

> Have been looking at a few options for tests.

> - Protocol Simulator for testing RFC compilance.
> - Writing JUnit test like POP3Test/SMTPTest under testing.
> - Other scripting languages like Python.
> Python has a an excellent nntp client library.
> I could write good tests in a short span of time. I was thinking of using
jython.

Having tests for our own uses is paramount, even if we learn from mistakes
and then re-do them.

> Python seems to be the most productive way forward. I was wondering what
> everybody thought.

I think that you should go ahead and get tests ready ASAP.  We can learn
from them if we decide that we need to re-implement them in something other
than python.

	--- Noel


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Python for testing

Posted by Harmeet Bedi <ha...@kodemuse.com>.
----- Original Message -----
From: "Charles Benett" <ch...@apache.org>
> Harmeet,
> Can you turn this into a HowToTestNNTP.txt and stick it in cvs? I'm sure
> other people would have the same question.

Sure Charles, I can put something together, although there is no NNTP
Specific testing. I was actually testing SMTP/POP3 with this.

What I'll do is this:
- Put a doc together to explain some existing test ideas
- Specific examples for protocols - SMTP/POP3/NNTP/IMAP.

Others may desire to add to it too. Darrell has some interesting stuff in
the proposals area.

Harmeet


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Python for testing

Posted by Charles Benett <ch...@apache.org>.
Harmeet,
Can you turn this into a HowToTestNNTP.txt and stick it in cvs? I'm sure 
other people would have the same question.
Charles

Harmeet Bedi wrote:

>>I thought was how a
>>junit TestCase works (that it will execute all methods that begin with
>>the word test).
>>    
>>
>
>That is one way but it does not provide much control. Junit can construct a
>test suite for you based on method signature or you can create a custom test
>suite with your own Test objects in the suite. I have followed the latter,
>with the twist that you can specify methods that comprise the test suite,
>the number of repetitions (see Junit RepeatedTest)  and number of concurrent
>threads(see Junit ActiveTestSuite) declaratively via XML file.
>
>
>
>Take a look at
>http://cvs.apache.org/viewcvs.cgi/jakarta-james/tests/src/conf/sampleconf.xm
>l?rev=1.1&content-type=text/vnd.viewcvs-markup
>
>and the program that runs tests.
>http://cvs.apache.org/viewcvs.cgi/jakarta-james/tests/src/java/org/apache/ja
>mes/testing/Main.java?rev=1.2&content-type=text/vnd.viewcvs-markup
>
>The difference here is create tests from BaseTest. Implement methods and the
>compose a test via XML file. The XML file can be used to control how the
>test is executed.sampleconf.xml represents a working example and format.
>
>These are advantages
>- Configurable tests. No need to hardcode things like what host/port to
>connect to or any other parameter
>- Control test sequence.
>- Compose test suite via XML.
>- Control the number of repetitions
>- Control the number of parallel threads.
>
>Each of the <testmethod> tags in sampleconf.xml represent a Junit test.
>
>Here is how you invoke the test suite.
>java org.apache.james.testing.Main <testconfigfile>
>
>
>It took me a little while to get my head around and satisfy requirements
>that unit tests in a test suite should be
>- configurable
>- composable
>- repeatable
>- and could run in parallel.
>There could be  other more elegant solutions. If you don't find this
>structure powerful or useful, you could contribute a different one or write
>straight JUnit tests.
>
>Harmeet
>
>
>Relevant Javadocs
>TestSuite - allows cutom sequencing of tests:
>http://www.junit.org/junit/javadoc/3.7/index.htm/allclasses-frame.html/junit
>/framework/TestSuite.html.
>ActiveTestSuite - allows concurrent tests:
>http://www.junit.org/junit/javadoc/3.7/index.htm/allclasses-frame.html/junit
>/extensions/ActiveTestSuite.html
>RepeatedTest - allows test repetitions:
>http://www.junit.org/junit/javadoc/3.7/index.htm/allclasses-frame.html/junit
>/extensions/RepeatedTest.html
>
>----- Original Message -----
>From: "Kenny Smith" <ke...@journalscape.com>
>To: "James Developers List" <ja...@jakarta.apache.org>
>Sent: Thursday, January 02, 2003 3:40 PM
>Subject: Re: Python for testing
>
>
>  
>
>>Hi Harmeet,
>>
>>I looked at BaseTest and SMTPTest, but I'm a little confused. I don't
>>see any methods in them that start with "test" which I thought was how a
>>junit TestCase works (that it will execute all methods that begin with
>>the word test). Are you using some cool thing about junit that I don't
>>know or what am I missing?
>>
>>Thanks,
>>Kenny Smith
>>
>>Harmeet Bedi wrote:
>>
>>    
>>
>>>----- Original Message -----
>>>From: "Kenny Smith"
>>>
>>>      
>>>
>>>>some premade smtp or pop junit
>>>>tests.
>>>>        
>>>>
>>>take a look at some existing James Tests at
>>>
>>>      
>>>
>http://cvs.apache.org/viewcvs.cgi/jakarta-james/tests/src/java/org/apache/ja
>  
>
>>>mes/testing/
>>>
>>>In particular look at EndToEndTest, POP3Test and SMTPTest.
>>>
>>>You may also want to look at tests under
>>>
>>>      
>>>
>http://cvs.apache.org/viewcvs.cgi/jakarta-james/proposals/imap2/test/org/apa
>  
>
>>>che/james/
>>>
>>>
>>>      
>>>
>>>>Is anyone working on junit tests that I should collaborate with
>>>>        
>>>>
>>>Hopefully everybody. Most developers have done some tests.
>>>
>>>
>>>      
>>>
>>>>or shall
>>>>I charge boldly forward?
>>>>        
>>>>
>>>Tests are of course always wellcome.
>>>
>>>Harmeet
>>>
>>>
>>>--
>>>To unsubscribe, e-mail:
>>>For additional commands, e-mail:
>>>
>>>      
>>>
>>--
>>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>
>
>
>  
>




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Python for testing

Posted by Harmeet Bedi <ha...@kodemuse.com>.
> I thought was how a
> junit TestCase works (that it will execute all methods that begin with
> the word test).

That is one way but it does not provide much control. Junit can construct a
test suite for you based on method signature or you can create a custom test
suite with your own Test objects in the suite. I have followed the latter,
with the twist that you can specify methods that comprise the test suite,
the number of repetitions (see Junit RepeatedTest)  and number of concurrent
threads(see Junit ActiveTestSuite) declaratively via XML file.



Take a look at
http://cvs.apache.org/viewcvs.cgi/jakarta-james/tests/src/conf/sampleconf.xm
l?rev=1.1&content-type=text/vnd.viewcvs-markup

and the program that runs tests.
http://cvs.apache.org/viewcvs.cgi/jakarta-james/tests/src/java/org/apache/ja
mes/testing/Main.java?rev=1.2&content-type=text/vnd.viewcvs-markup

The difference here is create tests from BaseTest. Implement methods and the
compose a test via XML file. The XML file can be used to control how the
test is executed.sampleconf.xml represents a working example and format.

These are advantages
- Configurable tests. No need to hardcode things like what host/port to
connect to or any other parameter
- Control test sequence.
- Compose test suite via XML.
- Control the number of repetitions
- Control the number of parallel threads.

Each of the <testmethod> tags in sampleconf.xml represent a Junit test.

Here is how you invoke the test suite.
java org.apache.james.testing.Main <testconfigfile>


It took me a little while to get my head around and satisfy requirements
that unit tests in a test suite should be
- configurable
- composable
- repeatable
- and could run in parallel.
There could be  other more elegant solutions. If you don't find this
structure powerful or useful, you could contribute a different one or write
straight JUnit tests.

Harmeet


Relevant Javadocs
TestSuite - allows cutom sequencing of tests:
http://www.junit.org/junit/javadoc/3.7/index.htm/allclasses-frame.html/junit
/framework/TestSuite.html.
ActiveTestSuite - allows concurrent tests:
http://www.junit.org/junit/javadoc/3.7/index.htm/allclasses-frame.html/junit
/extensions/ActiveTestSuite.html
RepeatedTest - allows test repetitions:
http://www.junit.org/junit/javadoc/3.7/index.htm/allclasses-frame.html/junit
/extensions/RepeatedTest.html

----- Original Message -----
From: "Kenny Smith" <ke...@journalscape.com>
To: "James Developers List" <ja...@jakarta.apache.org>
Sent: Thursday, January 02, 2003 3:40 PM
Subject: Re: Python for testing


> Hi Harmeet,
>
> I looked at BaseTest and SMTPTest, but I'm a little confused. I don't
> see any methods in them that start with "test" which I thought was how a
> junit TestCase works (that it will execute all methods that begin with
> the word test). Are you using some cool thing about junit that I don't
> know or what am I missing?
>
> Thanks,
> Kenny Smith
>
> Harmeet Bedi wrote:
>
> > ----- Original Message -----
> > From: "Kenny Smith"
> >
> > >some premade smtp or pop junit
> > >tests.
> >
> >
> > take a look at some existing James Tests at
> >
http://cvs.apache.org/viewcvs.cgi/jakarta-james/tests/src/java/org/apache/ja
> > mes/testing/
> >
> > In particular look at EndToEndTest, POP3Test and SMTPTest.
> >
> > You may also want to look at tests under
> >
http://cvs.apache.org/viewcvs.cgi/jakarta-james/proposals/imap2/test/org/apa
> > che/james/
> >
> >
> > >Is anyone working on junit tests that I should collaborate with
> >
> >
> > Hopefully everybody. Most developers have done some tests.
> >
> >
> > >or shall
> > >I charge boldly forward?
> >
> >
> > Tests are of course always wellcome.
> >
> > Harmeet
> >
> >
> > --
> > To unsubscribe, e-mail:
> > For additional commands, e-mail:
> >
>
>
> --
> 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: Python for testing

Posted by "Noel J. Bergman" <no...@devtech.com>.
Kenny,

> I looked at BaseTest and SMTPTest, but I'm a little confused. I don't
> see any methods in them that start with "test" which I thought was how
> a junit TestCase works

Most of the tests that I've looked at are external, ad hoc, and drive James
by acting as a protocol client.

	--- Noel


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Python for testing

Posted by Kenny Smith <ke...@journalscape.com>.
Hi Harmeet,

I looked at BaseTest and SMTPTest, but I'm a little confused. I don't 
see any methods in them that start with "test" which I thought was how a 
junit TestCase works (that it will execute all methods that begin with 
the word test). Are you using some cool thing about junit that I don't 
know or what am I missing?

Thanks,
Kenny Smith

Harmeet Bedi wrote:

> ----- Original Message -----
> From: "Kenny Smith"
>
> >some premade smtp or pop junit
> >tests.
>
>
> take a look at some existing James Tests at
> http://cvs.apache.org/viewcvs.cgi/jakarta-james/tests/src/java/org/apache/ja
> mes/testing/
>
> In particular look at EndToEndTest, POP3Test and SMTPTest.
>
> You may also want to look at tests under
> http://cvs.apache.org/viewcvs.cgi/jakarta-james/proposals/imap2/test/org/apa
> che/james/
>
>
> >Is anyone working on junit tests that I should collaborate with
>
>
> Hopefully everybody. Most developers have done some tests.
>
>
> >or shall
> >I charge boldly forward?
>
>
> Tests are of course always wellcome.
>
> Harmeet
>
>
> --
> To unsubscribe, e-mail:
> For additional commands, e-mail:
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Python for testing

Posted by Harmeet Bedi <ha...@kodemuse.com>.
From: "Kenny Smith" <ke...@journalscape.com>
> I looked over the ProtocolSimulator and I have some questions. What is
> it primarily used for? For example, is it used for stress testing or
> functional testing (or both?)

It was for RFC compliance and simulating specific client interactions.
Repetions and stress test arguments were added to make it easier to crank up
the load and expose problems that may be stess related.

The idea was
- Get script input from RFC or snoop on traffic, say using tcpdump-ethereal.
- Generalize and code validation using PERL REGEX. Most of the validation
may be check for response code and test for protocol compliance.
- Make it easy to add a large number of validation in a tester friendly
manner. Basically one could read RFC, generate assertions and document
assertions as protcol simultion. This would give valid and coded testcases
without any need to write code.

> I'm personally inclined to just write junit tests that excersize the
> different SMTP command sequences, but I'm interested to know what
> thought processes and whatnot have already gone on that has shown that
> approach to be lacking.

This is a good approach. I just found it more work. Wrote the SMTPTest in
JUnit that is checked in and the smtp protocol simulation test. I have been
trying to find the most elegant and low cost approach to testing and have
been going to and fro. Try things out yourself, and see what works best for
you. Junit is a good safe choice.

Harmeet


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


RE: Python for testing

Posted by "Noel J. Bergman" <no...@devtech.com>.
> I looked over the ProtocolSimulator and I have some questions. What is
> it primarily used for? For example, is it used for stress testing or
> functional testing (or both?)

I think that the primary need, at first, is functional testing.  Including
multiple sessions, but not necessarily stress testing at first.  We want to
make sure that the RFCs are handled properly.

FWIW, I use Russell Coker's postal (http://www.coker.com.au/postal/) to
stress test the SMTP side of James.

	--- Noel


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Python for testing

Posted by Kenny Smith <ke...@journalscape.com>.
Hi Harmeet,

I looked over the ProtocolSimulator and I have some questions. What is 
it primarily used for? For example, is it used for stress testing or 
functional testing (or both?)

I'm personally inclined to just write junit tests that excersize the 
different SMTP command sequences, but I'm interested to know what 
thought processes and whatnot have already gone on that has shown that 
approach to be lacking. Or perhaps that approach wasn't found to be 
lacking, the current one was just the preferred at the time. :)

I'm just trying to gather as much info as possible before I jump in so 
that I can use the knowledge gained from past experiences.

Thanks,
Kenny Smith
JournalScape.com

Harmeet Bedi wrote:
> ----- Original Message -----
> From: "Kenny Smith" <ke...@journalscape.com>
> 
>>I don't really have a specific area to focus on, but SMTP is at least a
>>protocol I use, so I can get excited about it. :) I'm going to spend some
>>time looking over the structure Harmeet already has (and I'm sure asking
> 
> him
> 
>>a bunch of questions) and I'll xref with the RFCs. :)
> 
> 
> For pure protocol testing, one way is to this is to simulate a protocol
> session.
> Protocol Simulator simulates telnet protocol and verifies results using PERL
> Regex. All of James' protocols build on telnet and can therefore be
> simulated. It is capable of multithreaded test simulations.
> 
> 
> take a look at
> http://cvs.apache.org/viewcvs.cgi/jakarta-james/tests/src/conf/smtp.protocol
> session?rev=1.1&content-type=text/vnd.viewcvs-markup
> 
> This protocol simulator runs this and similar scripts.
> http://cvs.apache.org/viewcvs.cgi/jakarta-james/tests/src/java/org/apache/ja
> mes/testing/ProtocolSimulator.java?rev=1.6&content-type=text/vnd.viewcvs-mar
> kup
> 
> Darrel has a bunch similar protocol simulation test scripts under
> http://cvs.apache.org/viewcvs.cgi/jakarta-james/proposals/imap2/test/org/apa
> che/james/
> 
> Usage:
> $ java org.apache.james.testing.ProtocolSimulator
>         -s, --server
>                 Remote Server Host To Test Against
>         -p, --port
>                 Remote Server Port To Test Against
>         -t, --template
>                 Protocol Session Template
>         -w, --workers
>                 Number Of Concurrent Simulations. Default Is 1.
>         -i, --iterations
>                 Number Of Protocol Simulations Iterations Per Worker. Defaul
>                 t Is 1.
>         -h, --help
>                 Usage Help
> 
> I was thinking of doing these improvements to the protocol simulator:
> - Have a template mechanism that allows script inclusion and variables.
> WebMacro/Velocity would do this well.
> - Scripts would be templates and would generate output that would be
> simulated by protocol simulator
> Was also thinking of have
> - Commands to retry/sleep. This would allow protocol simulation of say
> remotemanager, pop3 and smtp interaction with sleep-retry.
> 
> Was hoping to have RFC testing as a subproject in James and potentially
> interest other opensource projects to pool test effort. The main advantage
> would be mulitple projects get tests baseline. James would have the
> additional benefit that it knows when it has beat exim or sendmail or at
> least where it stands relative to others. This maybe interesting to
> commercial organizations too. Testing as a separate sub-project has been
> deferred, but not rejected.
> 
> 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: Python for testing

Posted by Harmeet Bedi <ha...@kodemuse.com>.
----- Original Message -----
From: "Kenny Smith" <ke...@journalscape.com>
> I don't really have a specific area to focus on, but SMTP is at least a
> protocol I use, so I can get excited about it. :) I'm going to spend some
> time looking over the structure Harmeet already has (and I'm sure asking
him
> a bunch of questions) and I'll xref with the RFCs. :)

For pure protocol testing, one way is to this is to simulate a protocol
session.
Protocol Simulator simulates telnet protocol and verifies results using PERL
Regex. All of James' protocols build on telnet and can therefore be
simulated. It is capable of multithreaded test simulations.


take a look at
http://cvs.apache.org/viewcvs.cgi/jakarta-james/tests/src/conf/smtp.protocol
session?rev=1.1&content-type=text/vnd.viewcvs-markup

This protocol simulator runs this and similar scripts.
http://cvs.apache.org/viewcvs.cgi/jakarta-james/tests/src/java/org/apache/ja
mes/testing/ProtocolSimulator.java?rev=1.6&content-type=text/vnd.viewcvs-mar
kup

Darrel has a bunch similar protocol simulation test scripts under
http://cvs.apache.org/viewcvs.cgi/jakarta-james/proposals/imap2/test/org/apa
che/james/

Usage:
$ java org.apache.james.testing.ProtocolSimulator
        -s, --server
                Remote Server Host To Test Against
        -p, --port
                Remote Server Port To Test Against
        -t, --template
                Protocol Session Template
        -w, --workers
                Number Of Concurrent Simulations. Default Is 1.
        -i, --iterations
                Number Of Protocol Simulations Iterations Per Worker. Defaul
                t Is 1.
        -h, --help
                Usage Help

I was thinking of doing these improvements to the protocol simulator:
- Have a template mechanism that allows script inclusion and variables.
WebMacro/Velocity would do this well.
- Scripts would be templates and would generate output that would be
simulated by protocol simulator
Was also thinking of have
- Commands to retry/sleep. This would allow protocol simulation of say
remotemanager, pop3 and smtp interaction with sleep-retry.

Was hoping to have RFC testing as a subproject in James and potentially
interest other opensource projects to pool test effort. The main advantage
would be mulitple projects get tests baseline. James would have the
additional benefit that it knows when it has beat exim or sendmail or at
least where it stands relative to others. This maybe interesting to
commercial organizations too. Testing as a separate sub-project has been
deferred, but not rejected.

Harmeet


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


RE: Python for testing

Posted by Kenny Smith <ke...@journalscape.com>.
> Fair enough.  :-)

*phew* :)

> Great!  Want to take a look at the RFCs, the current tests and
> the handlers?

You bet.

> What areas of the protocols are you interested in?
> For example, there are various extensions to SMTP that we ought
> to consider adding to the handlers. Also, we need to make some
> changes to the SMTP handler to properly handle the buffering and
> pipelining issue raised a few weeks ago.  If you aren't
> interested in those, OK, what floats _your_ boat?

I don't really have a specific area to focus on, but SMTP is at least a
protocol I use, so I can get excited about it. :) I'm going to spend some
time looking over the structure Harmeet already has (and I'm sure asking him
a bunch of questions) and I'll xref with the RFCs. :)

Kenny



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


RE: Python for testing

Posted by "Noel J. Bergman" <no...@devtech.com>.
Kenny,

> I really want to help out and I know that if I try to
> work on something NNTP related that I won't really be
> interested and won't give it my all. :/

Fair enough.  :-)

> I would be much more interested in SMTP or POP

Great!  Want to take a look at the RFCs, the current tests and the handlers?
What areas of the protocols are you interested in?  For example, there are
various extensions to SMTP that we ought to consider adding to the handlers.
Also, we need to make some changes to the SMTP handler to properly handle
the buffering and pipelining issue raised a few weeks ago.  If you aren't
interested in those, OK, what floats _your_ boat?

	--- Noel


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Python for testing

Posted by Kenny Smith <ke...@journalscape.com>.
Hi Noel,

I don't really know anything about the NNTP protocol and to be truely 
honest I'm not really interested in it. I think usenet is a terrible 
thing in fact. :) So, I would probably not enjoy helping much on that 
bit. It's selfish yes, but I really want to help out and I know that if 
I try to work on something NNTP related that I won't really be 
interested and won't give it my all. :/

I would be much more interested in SMTP or POP, I saw Harmeet's message 
about the tests that are already in CVS. I was going to look at those 
tonight.

Kenny Smith
JournalScape.com

Noel J. Bergman wrote:

> Kenny,
>
>
> >From: "Kenny Smith"
> >shall I charge boldly forward?
>
>
> Do you and Harmeet want to review current code status and share the duties
> on putting together a protocol test for NNTP?
>
> 	--- Noel
>
>
> --
> To unsubscribe, e-mail:
> For additional commands, e-mail:
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


RE: Python for testing

Posted by "Noel J. Bergman" <no...@devtech.com>.
Kenny,

> From: "Kenny Smith" <ke...@journalscape.com>
> shall I charge boldly forward?

Do you and Harmeet want to review current code status and share the duties
on putting together a protocol test for NNTP?

	--- Noel


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Python for testing

Posted by Harmeet Bedi <ha...@kodemuse.com>.
----- Original Message -----
From: "Kenny Smith" <ke...@journalscape.com>
> some premade smtp or pop junit
> tests.

take a look at some existing James Tests at
http://cvs.apache.org/viewcvs.cgi/jakarta-james/tests/src/java/org/apache/ja
mes/testing/

In particular look at EndToEndTest, POP3Test and SMTPTest.

You may also want to look at tests under
http://cvs.apache.org/viewcvs.cgi/jakarta-james/proposals/imap2/test/org/apa
che/james/

> Is anyone working on junit tests that I should collaborate with

Hopefully everybody. Most developers have done some tests.

> or shall
> I charge boldly forward?

Tests are of course always wellcome.

Harmeet


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Python for testing

Posted by Kenny Smith <ke...@journalscape.com>.
I've been getting into junit a lot recently, and loving it. I would love 
to help out with writing some junit protocol tests. Or come to think of 
it, I wonder if junit.org already has some premade smtp or pop junit 
tests. I'll take a look, but I doubt they have them.

Is anyone working on junit tests that I should collaborate with or shall 
I charge boldly forward?

Kenny Smith
JournalScape.com

Noel J. Bergman wrote:

> >The first thing I'd like to write [NNTP] tests
>
>
> >Have been looking at a few options for tests.
>
>
> >- Protocol Simulator for testing RFC compilance.
> >- Writing JUnit test like POP3Test/SMTPTest under testing.
> >- Other scripting languages like Python.
> >Python has a an excellent nntp client library.
> >I could write good tests in a short span of time. I was thinking of using
>
> jython.
>
> Having tests for our own uses is paramount, even if we learn from mistakes
> and then re-do them.
>
>
> >Python seems to be the most productive way forward. I was wondering what
> >everybody thought.
>
>
> I think that you should go ahead and get tests ready ASAP.  We can learn
> from them if we decide that we need to re-implement them in something 
> other
> than python.
>
> 	--- Noel
>
>
> --
> To unsubscribe, e-mail:
> For additional commands, e-mail:
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>