old faithful (was: Re: newbie to project-where to start from)
Geir Magnusson Jr wrote: Tim Ellison wrote: Pick a module [1] that interests you and from there the test code is in module_name/src/test/java/org.apache.harmony.tests.pkg.typeTest.java where pkg and type are the package and type under test; see here [2] for an example. I'm not convinced that we should only use this package convention for tests. One should certainly be able to put a test in the same package as the class being tested... ah that old favourite ;-) I'm sure that I don't need to repeat myself, but, 'oh go on then' - you cannot put code in java.* packages without running them on the bootclasspath. - I am *strongly* opposed to running tests on the bootclasspath - the code is subject to different rules c.f. app classpath - our target apps don't run there so the API tests are bogus - I agree with putting helpers into the bootclasspath to expose implementation classes that are tested (by tests on the app class path) - I would like to see a separation of java API tests and impl tests, so we know which ones we expect to pass on any compliant impl. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: old faithful
Tim Ellison wrote: Geir Magnusson Jr wrote: Tim Ellison wrote: Pick a module [1] that interests you and from there the test code is in module_name/src/test/java/org.apache.harmony.tests.pkg.typeTest.java where pkg and type are the package and type under test; see here [2] for an example. I'm not convinced that we should only use this package convention for tests. One should certainly be able to put a test in the same package as the class being tested... ah that old favourite ;-) We never resolved it. I'm sure that I don't need to repeat myself, but, 'oh go on then' - you cannot put code in java.* packages without running them on the bootclasspath. - I am *strongly* opposed to running tests on the bootclasspath - the code is subject to different rules c.f. app classpath - our target apps don't run there so the API tests are bogus I support this argument for code that tests the API as a client would - i.e. as app code uses the API. As for testing internals of java.foo. - I agree with putting helpers into the bootclasspath to expose implementation classes that are tested (by tests on the app class path) - I would like to see a separation of java API tests and impl tests, so we know which ones we expect to pass on any compliant impl. Yes - I agree with the last bit. So how do we move forward? Is it worth investigating some kind of test harness that gives us the control we need for security and classloader issues so we can split of tests that want to be java.foo and those that are o.a.h.x.test geir geir
