TDD with a large C # solution is almost impossible due to the slow compilation speed

Question

I am working on a big solution with 60 builds. There are many assemblies that define the common parts for the solution, and then several nodes of the entry point into the system.

TDD is almost impossible at the moment, because changing one line in the layer with the smallest domain forces to rebuild almost the entire solution, since the test assembly refers to different levels of the solution.

What is the best practice to reduce build time from the current 75 seconds to a more acceptable 5 seconds or so? This will do TDD again.

When performing unit tests, some classes require layouts defined by interfaces from other assemblies, and as such should be specified in the test assembly. Therefore, having a single reference to other assemblies is not always possible, with the exception of the lowest level solution.

Answer 1

IMHO the problem is here: "because the test assembly refers to different levels of solution."
You must have one test assembly per assembly that you want to test.
When you still refer to many assemblies in each of the test assemblies, you have another problem: you create integration tests. This is not what you want to do in TDD.

In addition to updating your question:
Typically, you define interfaces in a different assembly than the implementation. Therefore, a change in the implementation of a low-level class should not affect the higher-level classes that use these interfaces ...

Answer 2

Other people told you refactoring, etc., great if you can ...

There are several other things that are easier to do:

• Combine small projects with larger projects, as the project overhead has been exceeded to create one project. (Use nDepend , if necessary, to control the call through the layers, the rules can be defined in the " Code Request Language" and then marked as part of your assembly)

• Make all projects embedded in some output directory, and then set "copy local" to false in all links to the project - this can lead to high speed due to a decrease in IO.

• Turn your virus scan to see if it matters; if so find a faster virus scan or exclude "hot" folders from the virus scan scan

• Use the perforce monitor and sys internal tool to see how your compilers take so long.

• Think about how disk with disk puts your output directory.

• Consider using SSDs, this is a big win and they are getting cheaper.

• More memory can have a big effect at times - (reduce the drum in the car, if you slow down greatly by removing a small ram, you can get more speed by adding more)

• Remove unnecessary references to projects (you may have to remove unnecessary "usings" first)

(Fast builds will also make your refactoring faster!)

Answer 3

Divide the entire solution into smaller layer-based solutions (or even more specific ones), and let each of them have a specific set of unit tests. You can’t take 60 projects in a single decision seriously, why would anyone want to work with him? Is it a common task for you to make changes to 10 of them within an hour?

With TDD and large projects, test runs are usually slow, rather than compilation time. Let the whole assembly process be handled by some special assembly machine and complete the whole assembly, and the whole unit test is launched only during verification.

This will return your development to normal TDD.