harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sian January" <sianjanu...@googlemail.com>
Subject Re: [jira] Commented: (HARMONY-617) [classlib][luni] HttpURLConnection does not support persistent connections
Date Thu, 22 Feb 2007 11:20:10 GMT
Hi Alexander,

On 22/02/07, Alexander Kleymenov <kleymenov@gmail.com> wrote:
>
> Hi Sian,
>
> Sian January wrote:
> >
> > My latest patch (luni3.patch) fixes Alexander's tests to comply with the
> > RI on how proxied connections are reused. I have not yet separated out
> > the tests that are implementation specific but I am planning to move
> > them into a separate class in the same package (e.g.
> >
> org.apache.harmony.tests.internal.net.www.protocol.http.PersistenceTest)
> > unless anyone disagrees.
>
> Thank you for the improvement! Everything works fine with your latest
> patch.
> In addition to it I've added patch implementing new test cases
> for persistent https connections. Please, check them and give me know if
> there are any questions or issues.


Thanks for this - I have had a look and the new https tests look great.

In additions to existing test cases it could be suitable for us to
> implement test cases checking for security issues
> (related to checkConnect, getProperty and others).


Yes - I had thought about this too.

What's regarding new test - I agree with package name, but to fully comply
> with "Testing Conventions Used in the Apache Harmony Class Library" [1] we
> should place implementation specific tests in luni/src/test/impl
> directory. It seems that luni module does not comply with conventions,
> but it's a good chance for us to start moving it in right direction.


That's a good idea - I didn't realise there were conventions for test
names.  I will make this change and write some security tests and then
upload a final patch.

Regards,

Sian


Another point for discussion could be test cases using connections to
> external web servers. I agree with necessity of such a 'real world'
> operation testing, but such the tests are more like system tests, not
> unit. Among the other things with such tests they require some external
> environment [pre]configuration: access to the internet or (in case of
> its unavailability) local web server launching.  Parameters of
> such a configuration (in our case it is address, port and, perhaps,
> proxy used for connection) should be passed to the test before
> its execution. Only in this case such tests can operate correctly and do
> what is expected.
>
> As I know there is no means for implementation of such a tests
> on classlib yet. Although there were related discussions turned on this
> problem,
> but did not reached final resolution (see [2] for example).
>
> I could suggest the mechanism resolving this.
> It can be implemented similar to DRLVM regression testing framework:
> To launch system test cases we can implement Ant's scripts
> checking/making required environment configuration and starting the test
> with
> passing required parameters. In our case we can check for internet
> connection and use external web server, or launch Jetty if it is
> unavailable.
> There is no need in code duplication for test cases differing from each
> other only by external system configuration. In our case the test cases
> checking real-world operation could look like follows:
>
>    1. Launch Jetty before execution:
>
>       <target name="test" depends="launch-jetty">
>
>           <run-junit-test "o.a.harmony.test.HttpURLConnectionTest"
>                vmarg="-Dserver.address=${http.jetty.address}"/>
>
>       </target>
>
>    2. Executed only in case of direct internet access:
>
>       <target name="test" if="internet.connection.exists">
>
>           <run-junit-test "o.a.harmony.test.HttpURLConnectionTest"
>                vmarg="-Dserver.address=${http.web.address}">
>
>       </target>
>
>
> Our JUnit test will remain as is in the same location as now, but new
> system
> test cases (like above) will use it from different perspective - not as
> a unit functional, but as a system functional test.
>
> Such an approach is simple, quite universal, does not require much coding
> work,
> does not depend on new external tools and libraries, and could be easily
> integrated into current repository/build/testing system.
> What does Community think of it?
>
> Thank you,
> Alexander
>
>
> [1] "Testing Conventions Used in the Apache Harmony Class Library":
>    http://harmony.apache.org/subcomponents/classlibrary/testing.html
>
> [2] [testing] code for exotic configurations
>    Somewhere at:
>    http://mail-archives.apache.org/mod_mbox/harmony-dev/200601.mbox/thread
>



-- 
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message