What are the advantages of self-testing code vs separated tests?

Question

Personally, I've always put unit tests in a separate project just because that's how MSTest seems to be set up. But I'm reading Refactoring: Improving the Design of Existing Code by Martin Fowler and he seems to be advocating not only putting them in the same project, but also putting them in the same class as the method they're testing.

I'm really honestly having trouble thinking of ways this is different from having the tests in a separate area from the code itself other than philosophical differences (are tests documentation or clutter?).

Are there any clearcut reasons to choose one over another? Or is this mainly a philosophical difference?

UPDATE: I'm not necessarily convinced yet one way or another, but at least I have an idea what the arguments are. I wish I could select everybody's answer, but I had to select just one.

Answer 1

Perhaps there is some elegance to having self-testing code, but I tend to side with the same philosophy as you -- that code separation trumps some notion of abstract beauty. When you design a class, you can fundamentally break it into three parts:

• What the class does (eg, the class' definition)
• How it does it (the implementation)
• How you use it (documentation and/or test cases)

I see test cases as serving the purpose of documentation, as well as part of a safety net in a test suite. When a new programmer is looking at your code, possibly long after you've stopped working on it, the documentation is seldom the most effective way of communicating how the class should be used. It can answer questions about how the code behaves in specific situations, providing a general overview of the class and it's methods, and so on, but the test cases provide a concrete example of how the class would be used in real code.

So for that reason, I would tend to say that they should remain outside of the class itself, since this re-enforces this degree of separation.

Answer 2

Putting them in the same class being tested may break popular unit testing frameworks, as NUnit won't test types that don't have a default parameterless constructor.

Putting the tests in a different file but same project is better, but still causes your main project to reference testing frameworks like NUnit.Framework.dll as well as any mocking frameworks like Rhino.Mocks.dll.

Having your tests inside the class under test also increases the size of your distributed project.

Separate the tests out into a separate project, and you don't have any of these issues.

Answer 3

Keeping your tests in a separate area (subdirectory, project, whatever) is a good way to retain the option to deploy just the production code, which is usually what you'll want to do.