harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Liang <richard.lian...@gmail.com>
Subject Re: [classlib] Layout of tests in crypto module
Date Fri, 26 May 2006 06:20:11 GMT
Mikhail Loenko wrote:
> It is more preferable to have tests implementation-independent:
> we can validate them on RI, the tests will not have to be modified if we
> modify our implementation.
>
Hello Mikhail,

Agree. :-)
But I think the test 
org.apache.harmony.tests.internal.net.www.protocol.http.HttpURLConnectionTest.testGetOutputStream

can be re-write as the following. And the test should be package 
"org.apache.harmony.tests.java.net" or "tests.api.java.net".

public void testGetOutputStream() throws Exception {
        // Regression for HARMONY-482
        HttpURLConnection c = (HttpURLConnection) new 
URL("http://127.0.0.1:"
                + port).openConnection();

        c.setDoOutput(true);
        //use new String("POST") instead of simple "POST" to obtain other
        //object instances then those that are in HttpURLConnection classes
        c.setRequestMethod(new String("POST"));
        c.getOutputStream();
       
        //use new String("PUT") instead of simple "PUT" to obtain other
        //object instances then those that are in HttpURLConnection classes
        c.disconnect();
        c.setRequestMethod(new String("PUT"));
        c.getOutputStream();

        //use new String("GET") instead of simple "GET" to obtain other
        //object instances then those that are in HttpURLConnection classes
        c.disconnect();
        c.setRequestMethod(new String("GET"));
        c.getOutputStream();
    }

> The test I was talking about was impl-independent. It obtained an 
> instance of
> an internal class by impl-independent way and then did some 
> impl-independent
> things over it.
>
> I think having tests impl-independent is more preferable goal than not 
> having
> api tests in bootclasspath
>
> Thanks,
> Mikhail
>
> 2006/5/26, Richard Liang <richard.liangyx@gmail.com>:
>>
>>
>> Mikhail Loenko wrote:
>> > Hi Richard
>> >
>> > Do you mean a mock subclass of j.n.HttpURLConnection or a mock
>> > subclass of
>> > o.a.h.luni.internal....HttpURLConnection ?
>> >
>> > If it is a subclass for o.a.h... then it won't pass on RI - it would
>> > be an impl test,
>> Hi Mikhail,
>>
>> I'm sorry if my previous description made you confused. :-)
>>
>> AIUI, it IS an implementation test. Because we are testing Harmony's
>> detail implementation.
>>
>> > if it is a subclass for j.n.HUC then it won't catch a problem in
>> > o.a.h....HIC
>> >
>> > Thanks,
>> > Mikhail
>> >
>> > 2006/5/25, Richard Liang <richard.liangyx@gmail.com>:
>> >>
>> >>
>> >> Mikhail Loenko wrote:
>> >> > Yes there is.
>> >> >
>> >> > They can access protected fields (they are also package-visible).
>> >> Or they
>> >> > can test something related to class loading.
>> >> >
>> >> > Example. Recently I committed
>> >> >
>> >> 
>> modules\luni\src\test\java.injected\java\net\HttpURLConnectionAccessor.java 
>>
>> >>
>> >> >
>> >> > that is not a test though but something that is used by API test 
>> and
>> >> > that must
>> >> > be in bootclasspath. (I could refactor and put the test itself 
>> to the
>> >> > bootclasspath)
>> >> >
>> >> Hello Mikhail,
>> >>
>> >> Instead of using HttpURLConnectionAccessor, we can access protected
>> >> fields through a mock subclass of HttpURLConnection.
>> >> > Thanks,
>> >> > Mikhail
>> >> >
>> >> > 2006/5/25, Geir Magnusson Jr <geir@pobox.com>:
>> >> >>
>> >> >>
>> >> >> Mikhail Loenko wrote:
>> >> >> > 2006/5/24, Geir Magnusson Jr <geir@pobox.com>:
>> >> >> >>
>> >> >> >>
>> >> >> >> George Harley wrote:
>> >> >> >> > Hi Mikhail,
>> >> >> >> >
>> >> >> >> > That is a very good point and your suggestion of
>> >> supplementing the
>> >> >> >> class
>> >> >> >> > or package name sounds like a very straightforward
way around
>> >> the
>> >> >> >> > problem. Because there will be a number of tests
that must be
>> >> in an
>> >> >> >> > identical package name to the type under test then
it 
>> seems that
>> >> >> the
>> >> >> >> > differentiating mark needs to be added to the test
class
>> >> name. Not
>> >> >> >> > really sure what this could be. Given that we are
all 
>> settled on
>> >> >> the
>> >> >> >> > convention that a test type has the "Test" suffix,
how about
>> >> >> just add
>> >> >> >> > "Impl" to that suffix for implementation tests giving
us an
>> >> >> "ImplTest"
>> >> >> >> > suffix.
>> >> >> >> > e.g.
>> >> >> >> >
>> >> >> >> > class under test : java.lang.SomeClassTest
>> >> >> >> > implementation-independent test class :
>> >> >> >> > o.a.h.module.tests.java.lang.SomeClassTest
>> >> >> >> > Harmony-specific test class :
>> >> >> >> > o.a.h.module.tests.java.lang.SomeClassImplTest
>> >> >> >>
>> >> >> >> Or
>> >> >> >>
>> >> >> >> o.a.h.<module>.apitest.java.lang.FooTest
>> >> >> >> o.a.h.<module>.impltest.java.lang.FooTest
>> >> >> >>
>> >> >> >>
>> >> >> >> Of course, the implementation test didn't need to be on
the
>> >> >> >> bootclasspath, it would simply be
>> >> >> >>
>> >> >> >> java.lang.FooTest
>> >> >> >>
>> >> >> >> with no other garbage in the package name
>> >> >> >
>> >> >> > Hi Geir
>> >> >> >
>> >> >> > how to distinguish between bootclasspath implementation test
>> >> >> >   java.lang.FooTest
>> >> >> > and bootclasspath api test
>> >> >> >   java.lang.FooTest
>> >> >>
>> >> >> Is there such thing as an bootclasspath API test?
>> >> >>
>> >> >> geir
>> >> >>
>> >> >> 
>> ---------------------------------------------------------------------
>> >> >> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> >> >> To unsubscribe, e-mail: 
>> harmony-dev-unsubscribe@incubator.apache.org
>> >> >> For additional commands, e-mail:
>> >> harmony-dev-help@incubator.apache.org
>> >> >>
>> >> >>
>> >> >
>> >> > 
>> ---------------------------------------------------------------------
>> >> > Terms of use : http://incubator.apache.org/harmony/mailing.html
>> >> > To unsubscribe, e-mail: 
>> harmony-dev-unsubscribe@incubator.apache.org
>> >> > For additional commands, e-mail: 
>> harmony-dev-help@incubator.apache.org
>> >> >
>> >> >
>> >>
>> >> --
>> >> Richard Liang
>> >> China Software Development Lab, IBM
>> >>
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> >> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> >> For additional commands, e-mail: 
>> harmony-dev-help@incubator.apache.org
>> >>
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > Terms of use : http://incubator.apache.org/harmony/mailing.html
>> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>> >
>> >
>>
>> -- 
>> Richard Liang
>> China Software Development Lab, IBM
>>
>>
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>

-- 
Richard Liang
China Software Development Lab, IBM 



---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message