harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Zhang" <zhanghuang...@gmail.com>
Subject Re: [jira] Commented: (HARMONY-617) [classlib][luni] HttpURLConnection does not support persistent connections
Date Thu, 22 Feb 2007 11:16:49 GMT
On 2/22/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.
> 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).
> 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.
> 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>

Hi Alexander, why not launch jetty in embedded mode, say, in the test code?
We had a long discussion about jetty, and agreed to use it as a embedded web
server for harmony test, although I'm not sure whether it works for
persistent connections. iirc, someone(Tony Wu/Richard Liang?) has already
used jetty for network test. Your thoughts? Thanks!

   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

Best regards,
Andrew Zhang

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