In MVC/MVP style applications that have Controller/Presenter classes within the Client Application assembly and then a Services layer assembly containing Service classes, where do people recommend storing their unit tests?
For ease of execution it'd be nice to have a single Test assembly that references both the Client and Services, and contains tests for both. But is anything about a dual responsibility Test assembly considered bad design?
Where are other people storing their unit test code?
I usually create a unit test project per .NET assembly tested.
It's pretty important that you keep unit test projects isolated to only one System Under Test (SUT). If required, you can have more than one unit test project that exercises the same SUT, but not the other way around.
The reason for this is that if you have a single unit test project that exercises multiple SUTs, you are artificially coupling those two SUTs together. This means that you will never be able to migrate one of the SUTs without the other.
In the case of a web application, you may find such concerns irrelevant if you don't plan to reuse any of your libraries, but imagine that you are unexpectedly asked to implement a web service based on the same business logic as the web site currently uses. Your service layer sounds like a good candidate for code reuse, so you may want to reuse it without the MVC-based UI.
The problem now is that you can't, because the single unit test project drags along the unwarranted UI project.
Having a one-to-one relationship between SUTs and their unit tests just makes your life a lot easier.