I remember a discussion some years ago at my then current employer that took place (as all great developer discussions do) after our daily pilgrimage to Subway. We even used to make "Woo, woo!" sounds as the "Subway Train" left at precisely 11:30 each day, but I digress...
The discussion was about unit testing. Where should the tests go, and should they be shipped, etc?
To be honest I don't remember the outcome (yeah, very useful so far Shaw) but since I didn't think even for a second how to implement tests in the Dozing Dogs CMS I'm assuming that's because my sub-conscious mind knew the best answer.
In fact Google tells me that Alexis Smirnov agrees with me, so that's nice. I don't know Alexis but he started on Fortran like me so he must be alright. LOL, ramble, ramble..
As I've said before, I place unit tests in a sub-folder below the source called UnitTests. But compiled into the same assembly as the production code. And I ship NUnit too. That might sound crazy, but have you heard that you should always Do The Simplest Thing That Could Possibly Work?
The simplest, most maintainable thing for me to do is for me to ship my product with unit tests in it. With nunit.framework.dll.
If I get clever with build scripts and start stripping /UnitTests/*.cs files and dependencies in .csproj then I'm making my code less maintainable and more prone to break.
I've been talking to a lot of very clever people recently, both as the interviewee and interviewer, and they all agreed - less experienced developers tend to over-optimize, over-theorize and many times over-complicate. Wouldn't it be neat to make this extendable by our users by searching for methods with certain attributes and loading them at runtime? Yes, that can be really useful, but only if you have customers that do it.
Make sure you click on the links below and give yourself a few minutes to explore the links you find. I still go back and re-read them occasionally - share them with your friends over your Subway tomorrow..