单元测试的噩梦

不存在楼上所指的问题。
采用这种方式是有约定的，简单地说是：所有已经CHECK IN的代码都保证其测试是通过的。
我想你理解错了，gigix指的是已经完成并check in 的代码，不包括所有人正在写的

这个只能说明你的测试代价（特别是时间代价）太高，并不能说明有意义的应用不能够每10分钟把所有测试跑一边

不过，构建测试和它的目的有紧密联系，因此，并不是说你花比较多的时间运行测试就是差或者不好，关键是你是否获得乐你的利益

所有check in的代码的测试都跑一边？我不知道你这个规模是多大的。如果不对测试集进行分割(虽然未必是正交的)，对于大的应用(10人年以上)，从重新构建到测试完成的时间要大于10分钟，怎么样才能每10分钟"全部"跑一边？


hehe,也许你指的有意义的应用和我前面说的根本就不是一个东西. 测试代价太高，关键在于测试的东西，总部能因为测试时间长而削减把

好吧，我承认，对于100万人/年的大型应用，无论如何我是不可能花10分钟时间跑完这100万人/年所生产出来的所有测试的。

首先，我所说的是单元测试，单元测试是可以做到很小的代价来运行的。
其次，所指的全部也是一个范围的概念，对于10人年以上的项目，我想并不代表会把这10人年生产出来的所有代码都放到一个集合中，出于降低复杂度的考虑项目本身就会做分割以便分团队或者分批完成，分割后自然就是相对独立的部分，各个部分的单元测试完全没有必要在开发的时候集合在一起跑（集成测试等其它类型测试另当别论）。

简单解释几句，不说乐。

我想说，“十分钟单元测试”是一个好东西，十分理想，但是根本实现不了，具体的开发中会遇到这样那样的问题，相比做过单元测试的朋友都有体会。如果单元测试的频率是十分钟，那么必然要求checkin代码的频率也是十分钟，测完一次已完成并checkin的代码后，这些代码中的一部分就会再被checkout出来继续修改，十分钟后再单元测试，我如果一天不checkin代码，同时不停单元测试，那有什么意义呢？

你以为我不是每过半小时（也没有10分钟那么夸张）就check in一次代码的么？

半小时checkin一次代码－－这个代码肯定包括单元测试代码，再运行一次单元测试，再根据单元测试结果重构或者修改代码。这个成本得多高？项目进度如何保障？存在可操作性吗？国内有几个公司可以花费这么多成本在单元测试上？我希望以事实说话，我不敢说你说的半小时checkin是不是会对其他人造成误导，但是以我的经验，实际情况是，每天晚上做一次单元测试，几乎是极限了，而且晚上做单元测试也是比较科学的做法，因为不占用工作时间，第二天早上看报告，改代码，顺利成章。当老板得知你的team有1/3的工作时间都在忙单元测试，他会允许吗？

这个看你的目的了
如果你做单元测试的目的仅仅是验证，那么间隔时间长一些是可以的
如果你做单元测试的目的是为了改善代码，那么间隔就要短，通过单元测试来保证和驱动你不断逼近更好的设计
至于1/3的时间用来忙单元测试成本太高，这个是个心理问题。首先测试会帮助你集中注意力，提高你的生产率。其次，bug发现的越早，改正的成本越小。
单元测试的间隔时间长了，似乎花在测试上的时间少了，但是会相当程度上被调试的时间，以及注意力分散的时间所抵消掉

未必是一次运行所有的单元测试。也许只是相关的一部分TestCase组成的TestSuite。

其实关于单元测试，我自己也有很多困惑。随着开发的深入，单元测试代码越来越多，变更发生的时候，难以保证及时更新单元测试代码。其实这并不是一个技术问题，而是由于项目进度，无法保证有足够时间维护单元测试，给我足够的时间，单元测试就没问题。任何好的技术或者实践都需要存在的土壤，在工期压地你透不过气的时候，单纯技术层面上的讨论都显得无能为力。我们的开发理念是“交付第一，质量第二”，所以任何事情都得为进度让步。说到底，又说到公司的管理和经营理念上了，而这些又和市场紧密相关，市场又和政策政治相关，说着说着话题就大了。