TDD with large C# solution virtually impossible due to slow compile speed

I am working on a large solution with currently 60 assemblies. There are many assemblies that define common parts for the solution, and then a few entry point assemblies to the 开发者_高级运维system.

TDD is virtually impossible at the moment, as a single line change in the lowest domain layer, forces a rebuild of nearly the entire solution, as the test assembly references various layers of the solution.

What is best practice, to bring the build time down from its current 75seconds to a more acceptable 5 seconds or so? This will make TDD feasible again.

When doing unit tests, some classes require mocks defined by interfaces from other assemblies, and as such have to be referenced in the test assembly. So having a single reference to the other assemblies is not always possible, except at the lowest level of the solution.

IMHO the problem lies here: "as the test assembly references various layers of the solution."
You should have one test assembly per assembly you want to test.
When you still reference many assemblies in each of your test assemblies, you have a different problem: You are creating integration tests. That's not what you want to do in TDD.

In addition to the update to your question:
Normally, you would define the interfaces in another assembly than the implementation. So a change to the implementation of a low level class should have no impact on the higher level classes that use those interfaces...

Other people have told you to refactor etc, great if you are able to…

There are a few other things that are easier to do:

• Combine small projects into larger projects as there is a large per project overhead on building a solution. (Use nDepend if needed to control calling across layers, rules can be defined in "Code Query Language" and then checked as part of your build)

• Make all projects build into the some output directory and then set “copy local” to false on all the project references – this can lead to a large speed up due to reduced IO.

• Turn of your virus checker to see if it makes much difference; if so find a faster virus checker, or exclude the "hot" folders from the virus checker scanning

• Use perforce monitor and the sys internal tool to see way your compiles are taking so long.

• Consider a ram disk to put your output directory on.

• Consider using a SSD, this is a big gain and they are getting cheaper.

• More memory can have a big effect at times – (reduce the ram in the machine if you get a big slow down by removing a little ram, you may get a big speed up by adding more)

• Remove unneeded project references (you may have to remove unneeded “usings” first)

(Having a faster build will also make your refactoring faster!)

Split entire solution into smaller solutions that are layer based (or even more specific) and let each have a specific set of unit tests. You cant really be serious with this question 60 projects in one solution why anyone would want to work with it? Is it a common task for you to make changes in like 10 of them within an hour?

With TDD and big projects usually test runs being slow is the problem, not the compile time. Let the whole build process to be handled by some special build machine and perform whole build & whole unit test run only on checkin.

This will bring your development back to normal TDD.