We recently discussed (think: hotly debated) where to put the unit tests for an assembly at work. My preference is to put them in their own assembly and reference the assembly under test. My colleague, at a bare minimum, wants them in the same assembly as the classes under test, but ideally would put the test fixture for a particular class in the same file as the class, surrounded by a #if UNITTESTS compilation flag and hidden in a region at the bottom of the file.
Each has its benefits. The former keeps the tests logically and physically separated from the library under test so that there are no references missing later on, keeps both the tests and classes under test clean of clutter and it forces one to think about only the public API, which is a large part of TDD in the first place. The latter has the advantage that internal types can be tested more thoroughly; and the presence of the test right there in the file is self-documenting in the sense that the developer responsible for the assembly, not necessarily the assembly’s creator, sees them right away; so doesn’t have to be told that they exist in some other, far-flung assembly.
You know the face you make when you smell something unpleasant? That’s the face I make when I hear of the latter alternative. So I put the question to you, my two faithful readers, where do you put them? And why?
I wrote something about this a while ago and wish I could find it. I don’t have time to expound completely, but here’s why I STRONGLY agree with you and here’s why.
1. It forces you to develop your classes with the consumer of the class in mind. Someone using the class won’t have the benefit of accessing private members, so why should your unit test? If a class is difficult to test, it forces you to refactor it so that it’s more usable. To test protected classes, I just inherit from them in the test with a "wrapper" class.
2. It keeps things organized. There’s a lot to be said for this. You don’t want to accidentally ship or move code with unit tests to prod.
3. Testing internally doesn’t mean inner classes are tested more thoroughly. It means they can be tested more DIRECTLY. If a path of an inner class isn’t tested via the public API, what’s it doing there? It’s not being used at all.
4. Unit tests are a form of documentation. I try to keep the comments up to date in my unit tests and even use NDoc to generate MSDN style documentation. These unit tests are great for documenting how to use the classes you are testing.
5. Because I said so. 😉
HOWEVER: This is difficult to do if you’re writing an EXE as you can’t reference an EXE (via VS.NET 2003 but you can via CSC.exe). Of course, you could have most of your code in a dll assembly and have the EXE reference that and test the dll assembly. (sorry for incoherency, I’m in a hurry).
Actually, you’re more coherent than I am in the original post. 🙂 I vaguely touched on 1-3 in the original post, but you’re much more precise.
But I’m curious about 4: my first thoughts are that documentation for the class should be with the class, including any examples of how they are to be used; I have in mind the .NET framework docs as an example of the end result. Although, after I think about it, the unit test should show EVERY possible usage of the class, and therefore would be an excellent place to go for a thorough example of how to use the class. However, if you’re dealing with a class with a lot of state, say, whose methods return very different results based on the state, the unit test could be a big bloated mess, even with refactoring already done (after writing that, a little voice in my head told me that I hadn’t refactored enough).
Steve Maine had a post about this back in June: http://hyperthink.net/blog/PermaLink,guid,b41ea129-baf4-4af7-8a3f-3255836380ca.aspx that touches on this very thing.
Have you got an example of a unit test fully doc’ed?