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
