There are two schools of thinking when it comes to unit tests and what package to put them in. Generally speaking, a test class usually exists one to one with an actual implementation class. This is not a given, but it is a common pattern you see.

In the VisualAge world, when we made tests, we would put those tests in to a separate application from the application that contained the real code, eg:

MyRealProgramApp and MyRealProgramTestApp

The reason for this was simple - separating out the tests at 'package' time is difficult and annoying. Especially when you create 'Release' configuration maps.

So when Steve Aldred and I moved over to VisualWorks in our spare time, we copied across the same pattern. We'd put our tests in to a different package to the package that contained the code. This allowed us to simply not load those packages when we wanted to package.

But things for us have changed since then. We're now distributing production code /with/ its test cases - ie: we don't strip out the test cases. Why? - So that we can verify that in the production environment the tests still behave as expected. This is a huge win.

As well as that, we learnt a lot more about the packager in VisualWorks - more specifically, we learnt how little it does for you when you want to strip things. So, we use scripts to drive the packager and our scripts can do things like filter tests out of the image regardless of what package they're in.

So that means that our assumption that it's difficult to remove tests from a package is now no longer true. And our assumption that you may not want to deliver the tests in a production piece of code are also no longer true.

On top of this, that charismatic person called Travis Griggs opened my eyes to a different pattern - leave the tests in the package where the real code is. I initially found this to be annoying. It cluttered up the package in ways I wasn't expected. I was taken aback, I didn't know what to do.. I was confronted with something that I thought was wrong.

But after breaking away my assumptions, I started to appreciate Travis's pattern more. It means that the tests are always -right there- where the code I'm writing is. The built in testing tool is easier to use when the tests are -right there- too - you don't have to go looking for them after you've changed some code.

So.. I now put the tests in to package that contains the code.

What do you do?