Hen*_*rik 9 c# tdd performance compilation
我正在研究目前有60个组件的大型解决方案.有许多程序集定义了解决方案的公共部分,然后是系统的一些入口点程序集.
TDD实际上是不可能的,因为最低域层中的单线变化迫使几乎整个解决方案的重建,因为测试组件引用了解决方案的各个层.
什么是最佳实践,将构建时间从当前的75秒降低到更可接受的5秒左右？这将使TDD再次可行.
在进行单元测试时,某些类需要由其他程序集的接口定义的模拟,因此必须在测试程序集中引用.因此,除了解决方案的最低级别之外,并不总是可以单独引用其他程序集.
Dan*_*rth 16
恕我直言,问题在于:"因为测试组件引用了解决方案的各个层."
每个要组装的程序集应该有一个测试程序集.
当您仍在每个测试程序集中引用许多程序集时,您会遇到另一个问题:您正在创建集成测试.这不是你想要在TDD中做的事情.
除了对您的问题的更新:
通常,您将在另一个程序集中定义接口而不是实现.因此,对低级别类的实现的更改应该对使用这些接口的更高级别类没有影响...
其他人告诉你重构等,如果你能够 ......
还有一些其他更容易做的事情:
将小项目合并到更大的项目中,因为构建解决方案的每个项目开销很大.(如果需要,可以使用nDepend控制跨层调用,可以在" 代码查询语言 "中定义规则,然后在构建过程中进行检查)
将所有项目构建到某个输出目录中,然后在所有项目引用上将"copy local"设置为false - 这可能会因IO减少而导致大幅加速.
转动你的病毒检查器,看它是否有很大的不同; 如果是这样找到一个更快的病毒检查程序,或从病毒检查程序扫描中排除"热"文件夹
使用perforce监视器和sys内部工具来查看编译所花费的时间.
考虑使用ram磁盘放置输出目录.
考虑使用SSD,这是一个很大的收获,而且它们越来越便宜.
更多的内存有时会产生很大的影响 - (如果你通过移除一个小的ram来减慢机器内的ram,你可以通过增加更多来加快速度)
删除不需要的项目引用(您可能必须先删除不需要的"usings")
(更快的构建也将使您的重构更快!)
将整个解决方案拆分为基于层(或更具体)的较小解决方案,并让每个解决方案都有一组特定的单元测试.你真的不能认真对待这个问题60个项目在一个解决方案中为什么有人想要使用它？您是否在一小时内对其中的10个进行更改是一项常见任务？
对于TDD和大项目,通常测试运行缓慢是问题,而不是编译时间.让整个构建过程由一些特殊的构建机器处理,并且仅在签入时执行整个构建和整个单元测试运行.
这将使您的开发恢复正常TDD.
| 归档时间： |
|
| 查看次数： |
905 次 |
| 最近记录： |