由于编译速度缓慢，使用TDD开发大型C#解决方案几乎是不可能的。

Question

我正在处理一个包含60个程序集的大型解决方案。有许多程序集为该解决方案定义了共同部分，然后有几个入口点程序集用于系统。

目前，由于测试程序集引用了解决方案的各个层次，因此在最低域层进行单行更改就会强制重新构建整个解决方案，因此TDD几乎不可能实现。

如何做到最佳实践，将构建时间从当前的75秒降至5秒左右？这将使TDD再次成为可能。

在进行单元测试时，某些类需要由其他程序集中的接口定义的模拟对象，并且必须在测试程序集中引用它们。因此，在解决方案的最低层级别上，仅有一个对其他程序集的引用并不总是可行的。

- Hendrik

---

请看：https://dev59.com/jHVD5IYBdhLWcg3wNIrc#5432452 - Ian Ringrose

简单的答案是重新考虑你的项目结构。定义清晰的层和它们之间的接口，使得一个层的变化不会“涟漪”到所有上层。将接口移动到客户端和实现共享的程序集通常可以很好地隔离变化。 - Gishu

Answer 1

我认为问题出在这里：“因为测试组件引用了解决方案中的各个层次。”
你应该为要测试的每个程序集创建一个测试组件。
当你在每个测试组件中引用许多程序集时，就会面临不同的问题：你正在创建集成测试。这不是TDD中想要做的。

除了对你问题的更新：
通常情况下，你应该将接口定义在与实现分开的另一个程序集中。所以对底层类的实现进行更改不应该影响使用这些接口的高层次类...

- Daniel Hilgarth

---

这样做会在一个解决方案中得到大约120个项目。我可以想象维护所有这些项目的痛苦。顺便说一句，我不同意这种“否则你正在创建集成测试”的说法。 - goenning

当然，这将是很多项目，但请记住：您应该像对待应用程序代码一样认真对待测试。显然，有60个应用程序项目的充分理由，因此也有60个测试项目的同样理由。 关于集成测试：当然，这取决于情况，但最有可能的原因是他需要引用几个层次。否则，他只需要引用一个层次。也许我的回答在那一点上不够精确。我已经更新了它。 - Daniel Hilgarth

Answer 2

其他人可能会告诉你要进行重构等操作，如果你能做到的话那是很好的…

还有一些其他的事情可以更容易地实现：

• 将小项目合并成大项目，因为每个项目都需要建立一个解决方案，这会带来较大的开销。（如果需要控制跨层调用，可以使用nDepend，规则可以在“代码查询语言”中定义，然后作为构建的一部分进行检查）

• 使所有项目都构建到同一个输出目录中，然后在所有项目引用上设置“复制本地”为false——这可以减少IO，从而加快速度。

• 关闭病毒扫描程序，看看是否有显著的差异；如果有，请找一个更快的病毒扫描程序，或者将“热门”文件夹排除在病毒扫描程序之外。

• 使用Perforce Monitor和Sys Internal工具，查看为什么编译时间如此之长。

• 考虑使用RAM磁盘将输出目录放在上面。

• 考虑使用SSD，这会带来很大的收益，而且价格也越来越便宜。

• 更多的内存有时可能会产生很大的影响——（如果通过删除一些内存来降低机器性能，你可能可以通过添加更多内存来获得更快的速度）

• 删除不需要的项目引用（可能需要先删除不需要的“using”）

（构建速度更快也会使重构更快！）

- Ian Ringrose

Answer 3

把整个解决方案拆分成更小的基于层次结构（甚至更具体）的解决方案，并让每个解决方案都有一组特定的单元测试。谁会想要在一个解决方案中处理60个项目？这个问题不是开玩笑吧？你需要在一个小时内修改其中的10个项目吗？

使用TDD和大型项目时，通常测试运行速度缓慢才是问题，而不是编译时间。让特殊的构建机器来处理整个构建过程，并且只在提交代码时进行完整的构建和全部单元测试。

这将使您恢复正常的TDD开发。

- Valentin Kuzub