hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: Get rid of suite() and main() methods from Test classes?
Date Wed, 21 Apr 2010 21:35:46 GMT
On Wed, 2010-04-21 at 22:00 +0100, sebb wrote:
> On 21/04/2010, Oleg Kalnichevski <olegk@apache.org> wrote:
> > On Wed, 2010-04-21 at 19:55 +0100, sebb wrote:
> >  > On 21/04/2010, Oleg Kalnichevski <olegk@apache.org> wrote:
> >  > > On Wed, 2010-04-21 at 15:20 +0100, sebb wrote:
> >  > >  > On 21/04/2010, Oleg Kalnichevski <olegk@apache.org> wrote:
> >  > >  > > On Wed, 2010-04-21 at 00:24 +0100, sebb wrote:
> >  > >  > >  > Is there any point in having suite() and main() methods
in Test classes?
> >  > >  > >  >
> >  > >  > >  > IDEs and Maven and Ant allow individual test classes
to be run quite
> >  > >  > >  > easily, so AFAICT there is no need for these methods.
> >  > >  > >  >
> >  > >  > >
> >  > >  > >
> >  > >  > > All that code is a hangover from the pre-Eclipse days of HttpClient
1.x
> >  > >  > >  and early 2.x. I was going to migrate core and client to
JUnit 4 after
> >  > >  > >  upgrading core to Java 1.5 and get rid of old stuff in the
process.
> >  > >  >
> >  > >  > I've removed the suite() and main() methods.
> >  > >  >
> >  > >  > Interesting result, as now TestBasicHttpProcessor fails.
> >  > >  >
> >  > >  > This is because the main() and suite() were wrong - they referred
to a
> >  > >  > different class, see below:
> >  > >  >
> >  > >  > -    public static void main(String args[]) {
> >  > >  > -        String[] testCaseName = { TestHttpExecutionContext.class.getName()
};
> >  > >  > -        junit.textui.TestRunner.main(testCaseName);
> >  > >  > -    }
> >  > >  > -    public static Test suite() {
> >  > >  > -        return new TestSuite(TestHttpExecutionContext.class);
> >  > >  > -    }
> >  > >  >
> >  > >  > So the test class was not being run previously.
> >  > >  >
> >  > >  > [I did a cross-check of the changes, and that seems to have been
the
> >  > >  > only class for which this was true]
> >  > >  >
> >  > >  > I'm not sure how to fix the test cases - it's not clear whether
> >  > >  > indexes which are too large should be rejected or treated as being
end
> >  > >  > of list. The HttpRequestInterceptorList interface Javadoc probably
> >  > >  > needs clarifying.
> >  > >
> >  > >
> >  > > Roland had somewhat weird ways of dong things. I remember being unhappy
> >  > >  about such uncommonly relaxed use of indices, but not fining the problem
> >  > >  severe enough to justify an argument with Roland, given his tendency
to
> >  > >  take disagreements personally. Probably at some point I changed the
> >  > >  behavior of BasicHttpProcessor but overlooked the test cases.
> >  >
> >  > I'm not sure the testAddRequestInterceptorMiddleIndex() test case is
> >  > all that useful - it certainly does not test using a "middle" index.
> >  > Perhaps there were supposed to be some other interceptors added first.
> >  >
> >
> >
> > With Roland gone, there is no way of telling what exactly those test
> >  cases were meant for. Feel free to tweak it as you see fit or delete
> >  altogether.
> >
> 
> I don't know the httpcore code well enough to know what operations are
> sensible for interceptors.
> 
> Does it make sense to try adding an interceptor part-way through the list?
> 

No, not really. One may want to enforce a particular sequence of
interceptors within the same protocol processor, but adding an
interceptor part-way through the list doesn't really help much in that
regard. 

> Or does it only make sense to add them at the start and the end?
> 

Most likely. Usually One may want to intercept messages in the
processing chain either as early as possible or as late as possible.

Oleg


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


Mime
View raw message