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, 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 <[EMAIL PROTECTED]>:
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 <[EMAIL PROTECTED]>: >> >> >> Mikhail Loenko wrote: >> > 2006/5/24, Geir Magnusson Jr <[EMAIL PROTECTED]>: >> >> >> >> >> >> 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: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > --------------------------------------------------------------------- > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Richard Liang China Software Development Lab, IBM --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
