• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Project directory structure that facilitates all kinds of developer testing

 
Trailboss
Posts: 23778
IntelliJ IDE Firefox Browser Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Follow this link to see an article I'm writing about unit tests. That article will link to this thread asking for people to comment on the suggested directory structure.

After all, any putz with a web site can stand up and declare whatever they want. But this is an area riddled with so many problems, I think it would benefit all of us if we could say "yes, that's spot on" or "I agree with all of it except" or ... whatever. Let's figure out at least what we do agree on!

There will be several threads tying back to that article. This thread is only about the section about the directory structure.
 
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
One thing in the presented directory structure that got my attention is that you've got production code ("<ROOT>/src") and test code ("<ROOT>/test") living in separate top-level directory trees. Personally, I prefer having them within a single directory tree like "<ROOT>/src/main" and "<ROOT>/src/test". While this does lengthen the overall file paths by 5 characters (shocking, isn't it...), it also tends to simplify any scripts that need to deal with source code--because you only need to specify one path, not two, in order to cover all your source code. Again, this is a rather minor thing and definitely a matter of personal preference.
 
paul wheaton
Trailboss
Posts: 23778
IntelliJ IDE Firefox Browser Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Lasse Koskela:
One thing in the presented directory structure that got my attention is that you've got production code ("<ROOT>/src") and test code ("<ROOT>/test") living in separate top-level directory trees. Personally, I prefer having them within a single directory tree like "<ROOT>/src/main" and "<ROOT>/src/test". While this does lengthen the overall file paths by 5 characters (shocking, isn't it...), it also tends to simplify any scripts that need to deal with source code--because you only need to specify one path, not two, in order to cover all your source code. Again, this is a rather minor thing and definitely a matter of personal preference.



A matter of taste I suppose.

I guess to me "src" means production source. So I wanna keep all my test related junk out of there.
 
Ranch Hand
Posts: 775
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I used to be a big advocate of keeping functional source and test source in separate directory hierarchies, although didn't necessarily necessarily care about the specific scheme used. Always created it that way, always recommended it that way, made sense that they be kept separate so a junior developer wouldn't make functional source depend upon test source, etc.... until I ended up on a project with some people who continually would only make sure the functional source compiled because they never wrote or ran tests. They'd just configure their editor/IDE to only look at the functional source, so wouldn't even realize they'd made the test code uncompilable, and didn't care if anybody bitched at them about it.

Ever afterwards all I've care about is that there is *some* convention for keeping track of which resources are which, and if file naming conventions get me that, I'm content. Ant does just fine with file name patterns when I need to create clean functional vs test build products for release. While keeping the test stuff separate makes sense to me, having it not compile was more grief than any hypothetical issue associated with not having separate directories. When the files are in one directory hierarchy, bad practices of others have less impact on you. The hacks that won't run tests don't quite so constantly break everybody else's test-driven work approach.
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I really don't think that the directory structure is *that* important.

Above all, I wonder about the subject line of this thread - how does the directory structure *facilitate* testing?

We have all our (J)unit tests in the production code source directory, and the functional (FitNesse) tests are in its own (eclipse) project. I don't think that changing that structure would lead to better testing.

In fact I'd argue that seeing a "test" package right beside the class you are currently writing is a motivation to write a unit test for it. If the tests were in its own directory structure, you wouldn't see that.
 
Lasse Koskela
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I see your point, Ilja, about the tests being "in your face".
I've done that on some small projects as well ("small" as in "just prototyping something that will go to the trash can after I'm done") but I quickly reached a point where I had trouble getting a "visual" of what's in a package when there were 2-3 classes containing test stuff (test classes, mock implementations) per each production class.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Lasse Koskela:
I quickly reached a point where I had trouble getting a "visual" of what's in a package when there were 2-3 classes containing test stuff (test classes, mock implementations) per each production class.



Well, the test classes still are separated from the production classes - they are in a separate package.

One of my coworkers has written a small Eclipse plugin to visually distinguish between test- and non-test-packages: http://www.jave.de/eclipse/labeldecorator/ - that might help a bit, too.
 
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
As for directory structure, what I like to do is have the production code in "src", the unit tests in "test", and the mock objects in "mock_src". Putting them in three different directories makes it cleaner, to me.
As far as not compiling unit tests, well, that's why we use cruisecontrol. We also use cobertura for unit test coverage, and I keep upping the "totalbranchrate" and "totallinerate" whenever we add a bunch more unit tests.
 
Ranch Hand
Posts: 76
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Our original project relied on make.
People had created test programs in a test directory underneath the directory of the classes to be tested.

This became a problem when it was time to move to production because we didn't want the test programs to be in production. We first branched the make files, which wasn't a great thing to do.

Later, we used an environment variable as a switch for what goes and doesn't go. But, each make file still needed this variable.

Later, when we started using JUnit, we made sure we had a parallel test directory structure. This allowed us to control all tests with the environment variable to be sure the test directory did not go into production.

So, we have carried on this tradition.

Now, we are creating a new development environment. So, it is good to see the discussion on these items.
 
blacksmith
Posts: 1332
2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Reid M. Pinchback:
Ant does just fine with file name patterns when I need to create clean functional vs test build products for release. While keeping the test stuff separate makes sense to me, having it not compile was more grief than any hypothetical issue associated with not having separate directories. When the files are in one directory hierarchy, bad practices of others have less impact on you.



I have to agree with this. Keeping different types of code in parallel directory structures seems seductively sensible, but in practice, it's more of a pain than it's worth. In my experience, on real projects, it's much less hassle to keep all the code in the same directory structure, reflecting the package structure. You can ensure that your production code doesn't depend on your test code by having your integration tests run a target that compiles only the production code - easy to do, since the tests have to be identifiable to run them anyway.
 
Lasse Koskela
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Warren Dew:
You can ensure that your production code doesn't depend on your test code by having your integration tests run a target that compiles only the production code - easy to do, since the tests have to be identifiable to run them anyway.


Well, it's easy to separate them with file patterns if they're identifiable but it's not just about "Test*" and "*Test"--there are also numerous "Mock*", "InMemory*", "*Matcher", etc. prefixes/suffixes that one easily introduces throughout a project. Again, it's just a personal preference, but I prefer keeping parallel source trees and not worry about having forgotten or overdone some file pattern thing in the build script.
 
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
About keeping your jars inside your project, and keeping development (test) separate from production...

Our agile XP shop runs three teams at once, each with a different project. We have a
c:\java\libraries
folder checked into CVS that keeps all the development teams in sync, and our ant build copies each of the desired jars out of the libraries into our build folders (/test or /libraries). The ant build then references the build directory classpaths to do the compile.

This approach simplifies keeping all the jars for all the projects in one place and in sync. We end up having several versions of jars in c:\java\libraries as we upgrade and each project picks what they need. One of the guys even wrote a test to make sure the IntelliJ project file and the Ant classpaths both had the same jars so that Ant didn't get out of sync with Intellij. Referencing a jar in your IntelliJ project without adding it to the ant build breaks a test. A simple and effective way to keep all your jars in one place and in sync. Currently managing just under 200 jars. Works great if you want to attach the jars source too!
 
Lasse Koskela
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Dave, your solution sounds a lot like Maven. I wonder if you ever evaluated Maven as an alternative to your homegrown system?
reply
    Bookmark Topic Watch Topic
  • New Topic