The Old Joel on Software Forum: Part 3 (of 5)

JUnit and packages

As I'm beginning to use the JUnit support in Eclipse, I'm trying to organize somehow my test cases (they were previously sort of scattered on my hard disk).
How do you organize your test cases ? Would it be a good idea to create a package for them ? What if I want to test a class in the default package of my application ?
(http://www.clarkware.com/articles/JUnitPrimer.html#organize and http://junit.sourceforge.net/doc/faq/faq.htm#organize seem to take opposite ways).

Pakter
Monday, October 13, 2003

Under what conditions would you have two source files, describing classes in different packages, in the same source directory?

Under what conditions would you have two source files, describing classes in the same package, in different source directories?

Are your test classes part of the package that they test?

Danil
Monday, October 13, 2003

We have a parellel tree (src and test), and place the tests in the same package as the class they test, but in the other tree. All private data is package private so that the tests can access it. It's not perfect, but it works pretty well.

Mike Swieton
Monday, October 13, 2003

>Under what conditions would you have two source files, describing classes in different packages, in the same source directory?
I'm not sure the compiler would allow this (well, maybe with a funny classpath ?). Anyway, putting more classes in the same directory does not seem particularly desirable.

>Under what conditions would you have two source files, describing classes in the same package, in different source directories?
I think Mike is describing this organization. It seems reasonable ; I wonder if I could easily do so inside Eclipse.

>Are your test classes part of the package that they test?
This is one of the questions I'm asking myself. So far, I've got the choice.

Pakter
Monday, October 13, 2003

I do the same thing that Mike does, and it works here too.

Another option is to put your test classes in your main source tree and filter them out of the deploy process using ant (or whatever your build tool is). But I find this awkward, hence the second source tree named 'test'.

Joe Blandy
Monday, October 13, 2003

There are two typical ways to do this.

1. The parallel test source tree, metioned up thread. So if you've got src/com/example/package, you'll have another directory for tests in test/com/example/package.

2. Test subpackages (this is what my company uses). Tests are in the same source tree as your code, but tests for a package are in a "test" subpackage. So if you've got src/com/example/package, it will have a "test" package at src/com/example/package/test

Both work pretty much the same. They're equally easy to filter with Ant if you want to do that (we actually include them in our jar).

Luke Francl
Monday, October 13, 2003

At first sight, I favour the first solution : I'd rather not be forced to make methods public just to test them.

Any experience from WSAD/Eclipse users ? Maybe I should use Eclipse 2.1 instead of 2.0 to organize my packages.

Pakter
Tuesday, October 14, 2003

> I'd rather not be forced to make methods public just to test them.

I agree with this, although it is a bit controversial. Some folks feel that you should *only* test public methods. You can find their reasoning in several places on the Web (eg, the c2 wiki) so I won't go into it here.

I personally try to use unit testing wherever it will help, and if that means testing non-public methods, then so be it. Since I go faster with unit tests, I'm not much worried about the overhead of having the tests around afterwards. If they're no longer useful (eg, we've refactored the code) then throw them away, they've served their purpose.

Portabella
Tuesday, October 14, 2003

We do the same as Luke..

>So if you've got src/com/example/package, it will have >a "test" package at src/com/example/package/test

But after years of doing this -- I think I would prefer to just have the tests right in the same package. That way the class and it's junit are right next to each other. Makes it easy to update a class and test at the same time. No extra navigation into the test package to edit it.

I did this on some of my pet projects and it works better for me.

Junits Rock
Tuesday, October 14, 2003