Where to put unit tests?

[Chris]

We currently create JUnit test classes and put them in a separate
"testbench" package. This makes it easy to keep test code separate from
production code. The trouble, though, is that it makes it impossible for the
unit tests to call protected methods in the class being tested.

So we would have to put test and production classes in the same package to
make this work. To take it one step further, though, it would be nice to be
able to call private methods. To do this, the test code would have to go
into the production classes themselves.

What do most people do? Put unit tests in a different package, same package
but different class, or in the class being tested itself?

 

[Chris Smith]

We currently create JUnit test classes and put them in a separate
"testbench" package. This makes it easy to keep test code separate from
production code. The trouble, though, is that it makes it impossible for the
unit tests to call protected methods in the class being tested.

So we would have to put test and production classes in the same package to
make this work. To take it one step further, though, it would be nice to be
able to call private methods. To do this, the test code would have to go
into the production classes themselves.

What do most people do? Put unit tests in a different package, same package
but different class, or in the class being tested itself?

I put unit tests in the same package, but in a different source tree.
(Feasibility depends on your development tools; in Eclipse it works
great!) That allows unit testing of all interface elements that are
available from outside the class, without mixing unit tests into the
main code tree. I haven't seen enough advantage in test private methods
to justify giving up that advantage.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Bent C Dalager]

I put unit tests in the same package, but in a different source tree.

As do I.

One thing I have been pondering, but not implemented yet, is using
reflection to gain access to private methods as well.

Cheers
Bent D

 

[Adam Maass]

We currently create JUnit test classes and put them in a separate
"testbench" package. This makes it easy to keep test code separate from
production code. The trouble, though, is that it makes it impossible for the
unit tests to call protected methods in the class being tested.

So we would have to put test and production classes in the same package to
make this work. To take it one step further, though, it would be nice to be
able to call private methods. To do this, the test code would have to go
into the production classes themselves.

What do most people do? Put unit tests in a different package, same package
but different class, or in the class being tested itself?

Put the unit tests in the same package as the code being tested, but in a
different source tree.

From an XP perspective, private methods probably don't need to be separately
unit tested. Developers will write private methods as utilities for the
other methods that the class exposes (public, default, or protected). Those
are the methods you write unit tests for, and also happen to be exactly
those that you can get at with a unit test in the same package. So some code
path in the more-visible methods should exercise each branch of the private
methods -- else why would that branch of that private method have been
written to begin with?

Of course, that's the XP perspective. YMMV.

-- Adam Maass

 

[brougham3]

I put unit tests in the same package, but in a different source tree.

Same here.

I'll change complex private methods to package protected if I really want my
test classes to be able to test them.