我正在研究目前有60个组件的大型解决方案。有许多程序集定义了解决方案的公共部分，然后是系统的一些入口点程序集。
目前TDD实际上是不可能的，因为最低域层的单行更改会迫使重建几乎整个解决方案，因为测试程序集引用了解决方案的各个层。最佳做法是将构建时间从当前的75秒减少到更多 可以接受5秒左右？这将使TDD再次成为可行。
进行单元测试时，某些类需要由其他程序集的接口定义的模拟，因此必须在测试程序集中引用。因此，除了解决方案的最低级别之外，并不总是可以单独引用其他程序集。
答案 0 :(得分：16)
除了您的问题更新：
通常，您将在另一个程序集中定义接口而不是实现。因此，对低级别类的实现的更改应该对使用这些接口的更高级别的类没有影响...
答案 1 :(得分：9)
其他人告诉你要重构等等，如果能够那就很好......
还有一些其他更容易做的事情：
将小项目合并到更大的项目中，因为构建解决方案的每个项目开销很大。 （如果需要，可以使用nDepend来控制跨层调用，可以在“Code Query Language”中定义规则，然后在构建过程中进行检查）
将所有项目构建到某个输出目录中，然后在所有项目引用上将“copy local”设置为false - 由于IO减少，这可能会导致大幅加速。
转动病毒检查程序，看看它是否有很大差异;如果是这样，请找到faster virus checker，或从病毒检查程序扫描中排除“热门”文件夹
使用perforce监视器和sys内部工具来查看编译所花费的时间。
考虑使用ram磁盘放置输出目录。
考虑使用SSD，这是一个很大的收获，而且它们会越来越便宜。
更多的记忆力有时会产生很大的影响 - （如果你通过移除一个小的ram来减慢你的速度，你可以通过添加更多来加快速度）
删除不需要的项目引用（您可能必须先删除不需要的“使用”）
（更快的构建也会让您的重构速度更快！）
答案 2 :(得分：5)
将整个解决方案拆分为基于层（或更具体）的较小解决方案，并让每个解决方案都有一组特定的单元测试。你真的不能认真对待这个问题60个项目在一个解决方案中为什么有人想要使用它？您是否在一小时内对其中的10个进行更改是一项常见任务？
对于TDD和大型项目，通常测试运行缓慢是问题，而不是编译时间。让整个构建过程由一些特殊的构建机器处理，并执行整个构建和整个单元测试仅在签入时运行。
这将使您的开发恢复正常TDD。