harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <ge...@apache.org>
Subject Re: where to put tests?
Date Thu, 22 Dec 2005 13:11:28 GMT

On Dec 22, 2005, at 7:18 AM, Tim Ellison wrote:

> Does anyone have an opinion about where JUnit tests should be stored
> under enhanced/classlib/trunk/ ?  These will be new tests for bug  
> fixes etc.
>
> The current layout looks like this, with a couple of options marked:
>
> enhanced/classlib/trunk/
>     depends/  <- 3rd-party stuff + some resources
>     doc/      <- doxygen output
>     java-src/
>         archive/
>             src/ <- java code for archive component
>             <<option-1>>
>     native-src/
>         linux.IA32/ <- linux native code
>         win.IA32/   <- windows native code
>     <<option-2>>
>
>
>
> I don't have a strong feeling either way.
>
> <<option-1>> says put the unit tests into a folder alongside the
> implementation of each component of the class library (archive, math,
> etc.)  That way the tests live with the implementation, and there is a
> good incentive for the two to be maintained simultaneously.  It does,
> however, make the packaging a bit more interesting because the tests
> have to be separated -- this is not a big deal though.

This is sort of the way I'm familiar with, but a little different to  
ensure that all tests are in a separate tree.  This is closer to your  
option 2.

I mean :

java-src/
    src/
        archive/
           org/
             apache/
               harmony/
                  classlib/
                      archive/
                          Foo.java
        luni/  <- peer to archive...
        net/
        ...
     test/    <- peer to src
        archive/
            org/
             apache/
                harmony/
                   classlib/
                       archive/
                            TestFoo.java
         luni/
         net/

It's fairly easy to handle when packaging as you can package the  
entire test/ tree separate from src/ w/ no problems.  It's also a  
fairly common convention around here - the only diff from what I've  
worked with in the past is there is a module-like architecture w/o  
java-src, namely the segmentation by archive, net, luni, etc.


What I'm used to, using the names we have is something like

modules/
    luni/
      src/
        java/
        test/
    archive/
      src/
       java/
       test/
    net/
      src/
       java/
       test/

In our case, we have the complication of native code as well.  Does  
it make sense to commit completely by module, where each module is  
has all the java, multi-platform native and test code under one root  
in the tree?

modules/
    luni/
       src/
         java/
            src/
            test/
         native/
            win32/
               src/
               test/
            linux32/
               src/
               test/
            osX/
               src/
               test/
    archive/
       src/
         java/
            src/
            test/
         native/
            win32/
               src/
               test/
            linux32/
               src/
               test/
            osX/
               src/
               test/

And module is every module that we have, like port, launcher, etc.   
Some don't have Java, but that's ok - you get a very good high-level  
view of the produced artifacts by looking in the modules directory.

modules/
    archive/
    luni/
    io/
    math/
    launcher/
     port/

whatever we come up with.

Also, it means that if a module has some specific build need, that is  
handled right there by the build config w/in the module - the build  
for the classlib is a top level that kicks off each module in a  
standard way, but then each module build is specific to the module.   
Otherwise, we need a global all-knowing build that spans all modules,  
which sounds like we could run into maintenance problems in the future.

It also means any special test framework for a module is also the  
business of just that module.

What do you thinK?


>
> <<option-2>> says put the tests into a parallel hierarchy at the same
> level as the java and native code, e.g.
> .../trunk/java-tests/archive/src/ and so on.  This makes the packaging
> of the tests simpler since they are out of the way and allows us to
> treat them as separate components.
>
> FWIW:  I see that the HARMONY-16 contribution has the equivalent of
> <<option-2>>.
>
> Thoughts?
> Tim
>
> -- 
>
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>

-- 
Geir Magnusson Jr                                  +1-203-665-6437
geirm@apache.org



Mime
View raw message