前言

看见有同学讨论公司产品开发过程中的单元测试、集成测试、代码审查、签入、发布等问题，我来说说我以前服务过的公司的做法。

最差的情况是，没有测试、审查，直接签入、发布，所以系统不稳定。

最好的情况，我详细说说。

编码规范

某个我服务过的公司，把代码规范做到近乎极致：严格使用FxCop：多一个空格、空行、private关键字都不允许，条件判断后一行代码必须｛｝等等、等等，自己实现一套更严格的代码检测：所有字符串必须支持多语言除非写例外禁止、代码全局全文拼写错误检测，等等等等。

另外，namespace必须顺序而且System必须前面，static readonly顺序不能掉转，全局变量不允许_，引用dll不允许copy local，不允许“”只能String.Empty，所有警告视为错误，必须打开overflow check，参试列表要么同一行要么全部分列。

一般新人来会被这些要求逼疯。

代码维护

该系统比较大，2200万行代码，几千个项目，所以自己搞了一套系统，整合了TFS，自动做各种shelf/取所有项目最新版本等事情，自动判断某个项目已经最近被编译，如果是就从缓存取出来无需再编译。

单元测试/整合测试 (Unit Testing/Integration Testing)

该系统有60多万个单元/整合测试，每个项目，不管什么类型的程序（Web页面/console/windows 服务/窗体界面），不过什么什么业务，都带有测试，而且这个测试还有大量的各种严格、智能的玩法，譬如实现类要测，基类都自动测；又譬如数据库相关的测试，强制打开事务/snapshot，完成测试自动回滚，然后判断是否有差异就报错。

签入（Shelf/Check-in）

这套系统禁止手工签入(check-in)，这个禁止是系统根本不允许开发人员签入，任何开发人员必须通过shelf把代码提交到下面的自动化分布式编译/测试系统。这个好处是避免了任何人都可以随意把代码搞爆。

自动化分布式编译/测试（CI）

因为测试数量巨大，自己搞了一套分布式编译/测试系统。因为开发人员的机器配置相当高，譬如i9+1TB SSD，所以充分利用了几百台的开发人员机器，都给安装上了2个Hyper-V实例，在里面做CI。

大家可能没理解好，觉得市面上的Team City等都能分布式编译/测试，但是他们这种一般是一个提交只能在一个worker上编译和跑所有测试。但这套东西能把任意测试根据最优解自由组合，然后分布式到几百台*2个Hyper-V里面去做编译CI。譬如60万个测试里面，某几千个，是在机器001跑。

还有，这个测试不会盲目地跑所有60多万个测试，会自动判断代码的改变会影响到那些测试，才去跑相关的测试。

而且最关键的是，这套系统能最优解合并最近大家提交的shelf，然后再去做CI，都成功的话大家都pass，如果失败，再拆开单独跑失败的测试，这样就能节省大量时间。

代码审查（Review）和可用性测试

当上述的自动化分布式编译/测试通过之后，代码审阅者对代码分析、实际跑过之后，才标识该shelf通过，然后开发人员才能交给自动化分布式编译系统去签入代码。

 

版权所有

所有文章内容版权所有，任何形式的转发/使用都必须先征得本站书面同意。本站保留一切追究的权利。