单元测试的投入和产出

Jerry在晚上10点打电话过来，把即将进入梦乡的我召唤回现实。除了唠唠家常外，我们自然的又谈到敏捷开发的话题上来。这次谈话终于在单元测试的问题上让他了解并认同了我的看法。对于大多数的中国的软件开发团队来说，难以实现敏捷的最重要问题是人的素质问题。一个敏捷团队要求每个成员都有较好的OOP和OOD的能力。试想你正在努力的重构有坏味道代码的同时，你的team中却有另一个新手在不断的写出新的充满坏味道的代码会是什么样的后果？这是一个难以完结的循环，不是么？单元测试能带给敏捷什么帮助是我和Jerry一直最有分歧的地方。我承认，单元测试只是软件众多测试方式中的一种。静态的看，单元测试包括其他的测试方法需要付出的成本和雇用低廉的人力进行测试的成本相比可能还高一些。但单元测试能带给我们的帮助不仅仅是在重构过程中，保证对复用代码的修改不会波及其他的调用那么简单。通过编写测试，我们可以发现代码中结构的问题并优化之。当然这建立在团队成员对OO的认识基础上，OO能力不足的程序员遇到难以测试的代码时，往往不会想着或者没有能力去将它重构为方便测试的代码。这就给我们带来一个新的管理任务，也是敏捷过程强调的一个任务，那就是培训。我们需要不断的训练我们的程序员们，使得他们能够构造出敏捷的代码。而这正是一个团队能否实现敏捷的技术关键。
在谈话的最后，我们形成的共识是，实现敏捷是一个渐进的过程。构造一个在技术上有敏捷能力的团队有两种方法，一是用足够的钱去招聘有足够能力的程序员(大部分企业没有那么多钱)。二是将现有不符合敏捷技术要求的程序员培养为合格的敏捷工作者。而在培养的路上，单元测试正是一个很好的驱动方式和实践平台。
最后，希望看到这篇文章的人们，在衡量单元测试成本的时候，将他可能需要投入的培训成本考虑进去并切实的实施这些培训，也将单元测试能对团队技术水平的提高这部分产出考虑进去。