Folks, I like Sean's suggestion - it removes a confusion while introduces minor changes. I also want to give you an option to vote against "boot" in favour of "java.injected". Personally, I prefer "boot" because it is shorter and doesn't contain dot which confuses xmlproperty mechanism.
Please, participate. Otherwise Sean and I will dare to change the conventions in ths way. Thanks. On 11/28/07, Sean Qiu <[EMAIL PROTECTED]> wrote: > My suggestion is : > > <modulename>/src/test/api // implementation-independent tests > <modulename>/src/test/impl // platform-independent > implementation-dependent tests > -common // implementation-dependent > tests > -windows // windows-specific tests > -unix // linux-specific tests > -boot // tests which should be > injected into the bootclasspath > > I totally agree with you that the src/test/api/common and src/test/api/java > are somehow duplicated in our page[1]. > We should remove one of them, and boot is more appropriate and clear than > java.injected. > > We all know that a test is either api test or impl test. (except stress > test for special purpose , am i right? ) > So, IMHO, it's more clear to divide them into two main parts first as we > have done before. > Then we can decide where they should be placed according to their special > usage. > > Any comments? Suggestions? > > [1] http://harmony.apache.org/subcomponents/classlibrary/testing.html > > 2007/11/28, Alexei Fedotov <[EMAIL PROTECTED]>: > > > > Sean, > > > > > IMHO, the most important think is to make the modification in a minimun > > extent. > > > > That's good with me. So how do you think this might be implemented? > > Please, don't hesitate to correct my suggestion [1] or post something > > completely different from it. > > > > Thanks. > > > > [1] > > // implementation-independent tests > > <modulename>/src/test/api > > // platform-independent implementation-dependent tests > > <modulename>/src/test/impl > > // tests which should be injected into the bootclasspath > > <modulename>/src/test/boot > > // windows-specific tests > > <modulename>/src/test/windows > > // linux-specific tests > > <modulename>/src/test/linux > > > > On 11/28/07, Sean Qiu <[EMAIL PROTECTED]> wrote: > > > 2007/11/28, Alexei Fedotov <[EMAIL PROTECTED]>: > > > > > > > Sean, > > > > > > > > Thanks for your letter. This is another step to achieve Harmony. > > > > > > > > You asked: > > > > > In this case, we will test them according to the behavior of RI by > > > > > tradition. where should we put this api test to ? > > > > > > > > According to my last suggestion there are two options to place > > > > platform-dependent tests. If the test pretends to run on other > > > > implementations of Java, it should be placed at > > > > <modulename>/src/test/api > > > > > > > > The platform dependency should be handled by conditional behavior of > > > > test internals because its platform independent by design. > > > > > > > > If the test is intended to be for Harmony testing, it may be placed at > > > > <modulename>/src/test/<platform> > > > > > > > > > IMHO, the most important think is to make the modification in a minimun > > > extent. > > > > > > > > > > > > > > > > In return, I want to ask you direct question: what is your vision of > > > > the ideal testing structure? I want somehow to resolve the > > > > inconsistency I've met. > > > > > > > > You wrote: > > > > > As mentioned by Tim earlier, the reason is based on their history of > > > > some > > > > > being written early, some contributed, etc. > > > > > > > > > What i want to say here is that i think the other people all konw this > > > issue. > > > The reason that we havn't taken some actions is because it is > > > somehow important but less emergent. > > > And i agree with you that the standard should become consistent first. > > > > > > > > > > > > > This is not an excuse for having an inconsistent testing standard on > > > > Harmony site. First, the standard should become consistent. Then the > > > > tests should follow if the time permits. > > > > > > > > Finally, you conclude: > > > > > we need to reach a common consensus on the strcture for our test > > before > > > > we start. > > > > > > > > > That's great, and i think i can help for this if the communitiy reach a > > > consensus. > > > > > > That's the main point I agree on. I would like to ask all people who > > > > might be affected by these standards to wake up and either agree, or > > > > suggest consistent resolution of problems I get. > > > > > > > > Thank you for your interest. > > > > > > > > On 11/28/07, Sean Qiu <[EMAIL PROTECTED]> wrote: > > > > > 2007/11/28, Alexei Fedotov <[EMAIL PROTECTED]>: > > > > > > > > > > > Hello, > > > > > > Thinking a bit further didn't help me to improve the > > understanding. > > > > > > How can we put the following examples into the testing convention? > > > > > > <modulename>/src/test/api/java.injected > > > > > > <modulename>/src/test/api/windows > > > > > > <modulename>/src/test/api/linux > > > > > > > > > > > > > > > As mentioned by Tim earlier, the reason is based on their history of > > > > some > > > > > being written early, some contributed, etc. > > > > > > > > > > IMHO, the confusion is caused by how we define *API* test. > > > > > According to the *spec*? Or according to the behavior of *RI* > > > > > The spec sounds fine in theory, but there do exist some > > functions that > > > > are > > > > > platform dependent. > > > > > Such as the some functions of File, their behavior will vary in > > > > different > > > > > platform in RI which is not mentioned in spec. > > > > > In this case, we will test them according to the behavior of RI by > > > > > tridition. > > > > > where should we put this api test to ? > > > > > > > > > > I agree that it is time to tide them up now before their scale > > become > > > > out of > > > > > control. > > > > > IMHO, we need to reach a common consensus on the strcture for our > > test > > > > > before we start. > > > > > > > > > > > > > > > > > > > > > How might platform-dependent or package-private tests fit into api > > > > > > subcategory instead of impl? The Java specification which is a > > > > > > backbone for implementation-independent tests is by design > > > > > > platform-independent and doesn't expose package-private > > information. > > > > > > > > > > > > Risking inhibiting a creative potential and an interest of this > > thread > > > > > > I'd like to suggest the following solution which collapses two > > > > > > descriptive directory layers into one: > > > > > > > > > > > > // implementation-independent tests > > > > > > <modulename>/src/test/api > > > > > > // platform-independent implementation-dependent tests > > > > > > <modulename>/src/test/impl > > > > > > // tests which should be injected into the bootclasspath > > > > > > <modulename>/src/test/boot > > > > > > // windows-specific tests > > > > > > <modulename>/src/test/windows > > > > > > // linux-specific tests > > > > > > <modulename>/src/test/linux > > > > > > > > > > > > What do you think? > > > > > > > > > > > > Thanks. > > > > > > > > > > > > > > > > > > On 11/27/07, Alexei Fedotov <[EMAIL PROTECTED]> wrote: > > > > > > > Thanks Tim, testing gurus, > > > > > > > I was looking into testing conventions [1] and got the practical > > > > > > question: > > > > > > > > > > > > > > --- citation starts --- > > > > > > > > > > > > > > Tests are not separated by functionality under test, for > > example, > > > > > > > tests against clone() methods are NOT separated from tests > > against > > > > > > > equals() methods. Classpath tests are separated from > > bootclasspath > > > > > > > tests on a directory level: > > > > > > > > > > > > > > <modulename>/src/test/api/java - Classpath tests > > > > > > > <modulename>/src/test/api/java.injected - Bootclasspath > > testsFind > > > > more > > > > > > > details below. > > > > > > > > > > > > > > Some modules might have platform specific tests that are in the > > case > > > > > > > separated on a directory level: > > > > > > > > > > > > > > <modulename>/src/test/api/common > > > > > > > <modulename>/src/test/api/windows > > > > > > > <modulename>/src/test/api/linux > > > > > > > > > > > > > > --- citation ends --- > > > > > > > > > > > > > > Imaging I have all kinds of tests, e.g. platform-specific, > > injected > > > > to > > > > > > > the boot classpath, etc. Where should I put MyTest.java > > > > > > > > > > > > > > under src/test/api/common or under src/test/api/java? > > > > > > > > > > > > > > Or should I nest common under java? Or maybe we should just > > replace > > > > > > > common with java, shouldn't we? I volunteer to prepare a patch > > to > > > > the > > > > > > > web site when we agree on. > > > > > > > > > > > > > > [1] > > > > http://harmony.apache.org/subcomponents/classlibrary/testing.html > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 11/23/07, Tim Ellison <[EMAIL PROTECTED]> wrote: > > > > > > > > Alexei Fedotov wrote: > > > > > > > > > Do I understand correctly that > > > > > > > > > working_classlib/modules/awt/src/test/api/java/ should be > > > > actually > > > > > > at > > > > > > > > > working_classlib/modules/awt/src/test/api/java.injected? Is > > it > > > > > > > > > possible to use svn move instead of preparing a monstrous > > patch? > > > > > > > > > > > > > > > > Just send along a script with the SVN commands you want the > > > > committer > > > > > > to > > > > > > > > perform, that is how people have done it in the past. > > > > > > > > > > > > > > > > > The reason why I'm asking is the following. I need to add a > > test > > > > at > > > > > > > > > working_classlib/modules/awt/src/test/api/java/ and the > > tests > > > > which > > > > > > > > > are injected to a boot classpath are in that place. I > > believe > > > > the > > > > > > > > > right way to solve the problem is to move injected test > > cases to > > > > the > > > > > > > > > proper place first. What do you think? > > > > > > > > > > > > > > > > Sounds good. > > > > > > > > > > > > > > > > Regards, > > > > > > > > Tim > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > With best regards, > > > > > > > Alexei, > > > > > > > ESSD, Intel > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > With best regards, > > > > > > Alexei, > > > > > > ESSD, Intel > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Sean Qiu > > > > > http://xiaoxia.turendui.com > > > > > > > > > > > > > > > > > -- > > > > With best regards, > > > > Alexei, > > > > ESSD, Intel > > > > > > > > > > > > > > > > -- > > > Sean Qiu > > > http://xiaoxia.turendui.com > > > > > > > > > -- > > With best regards, > > Alexei, > > ESSD, Intel > > > > > > -- > Sean Qiu > http://xiaoxia.turendui.com > -- With best regards, Alexei, ESSD, Intel
