9

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.

EJoshuaS - Stand with Ukraine
  • 11,977
  • 56
  • 49
  • 78
Hendrik
  • 227
  • 1
  • 4
  • 14
  • see also http://stackoverflow.com/questions/55517/very-slow-compile-times-on-visual-studio/5432452#5432452 – Ian Ringrose Mar 25 '11 at 12:34
  • the simple answer is to reconsider your project structure. Define clear layers and interfaces between them such that a change in one layer doesn't "ripple" all the way up. Moving the interfaces to an assembly shared by the client and the implementation usually isolates change nicely. – Gishu Oct 04 '11 at 09:55

3 Answers3

16

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...

Daniel Hilgarth
  • 171,043
  • 40
  • 335
  • 443
  • 3
    By doing so he would end up with about 120 projects in a single solution. I can imagine the pain to maintain all this projects. By the way, I don't agree with this 'Otherwise you are creating integration tests'. – goenning Feb 17 '11 at 12:38
  • 2
    Sure, it would be a lot of projects, but remember: You should take your tests as serious as your application code. And obviously, there are good reasons for 60 application projects, so there is the same reason for 60 test projects. About the integration tests: Sure, it depends, but most likely that's the reason why he needs to reference several layers. Otherwise, he would need to reference only one layer. Maybe my answer wasn't precise at that point. I updated it. – Daniel Hilgarth Feb 17 '11 at 12:39
9

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!)

Community
  • 1
  • 1
Ian Ringrose
  • 51,220
  • 55
  • 213
  • 317
5

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.

Valentin Kuzub
  • 11,703
  • 7
  • 56
  • 93