程序员为什么不喜欢写单元测试很多程序员在早期学习编程期间，养成了写单元测试的良好习惯，并且在工作中继续保持。但还有一些程

很多程序员在早期学习编程期间，养成了写单元测试的良好习惯，并且在工作中继续保持。但还有一些程序员是不愿意去写单元测试的，尤其是一些经验丰富的程序，对于TDD（测试驱动开发）持有强烈反对意见。

闲暇时间和几个朋友聊天，反对者持有以下几个观点：

1.dead line是第一生产力

是项目工期太长，还是没人催进度。天天加班实在没空写单元测试，一个功能肝完，稍微测测就提测。都是老司机，代码有啥问题都心中有数，也就小白认认真真写单元测试。

对于一些初学者，不知道如何正确的写好的测试代码，觉得有点难。随着业务代码逐渐增多，团队也没有好的规范。久而久之，更习惯于手动测试。时间越久，就越抗拒。

在之前的团队中，有要求要写单元测试。但是现在的团队没有要求要写，大家都不写，也就没人写了。老板催的是项目进度，觉得有bug是正常的事情，对质量要求不高。

实行敏捷开发，原始需求一变再变。导致需求经常变更，实现代码改完，还得改测试代码，可能花费在测试代码上的时间比实现代码都多，不得不放弃写测试代码。

下面谈谈为什么提倡单元测试：

很多人不愿意写单元测试觉得麻烦，其实忽略了手动测试更加麻烦。随着功能越来越复杂，测试的时间成本也会越来越高。最初编写的单元测试，会一直生效。即使项目运行几年后，接手的开发者，也可以快速的对功能进行测试，而不是熟悉功能，手动测试。

如果团队没有写单元测试的规范，不妨先开始试试。短期来说，可能时间成本增加。将视野放到项目的整个生命周期中，编写单元测试会让代码更加健壮。并且在编写时，如果已经思考好如何测试，在进行逻辑设计时，会减少更多漏洞。

现有的各种语言都提供几种主流的测试工具，如Java中的JUnit。每一种测试工具都有自己的特色，团队可以花费时间尝试不同的开发工具。选择更适合自己的工具。