单元测试对我来说听起来很棒,但我不确定我是否应该花时间真正学习它,除非我能说服其他人具有重要价值.我必须说服其他程序员,更重要的是说服管理中的bean计数器,所有额外的时间花在学习测试框架,编写测试,保持更新等等......将为自己付出代价,然后是一些.
有什么证据？有没有人真正用两个独立的团队开发相同的软件,一个使用单元测试而另一个没有,并比较结果？我对此表示怀疑.我只是应该证明这一点,"在互联网上查找,每个人都在谈论它,所以它一定是正确的做法"？
哪些证据可以说服外行人员单位测试值得付出努力？
我喜欢我的代码是有序的,即格式正确,可读,设计,测试,检查错误等.事实上我对它很狂热.(甚至可能比狂热更多...)但在我的经验中,帮助代码质量的行动很难实现.(通过代码质量,我的意思是您日常生成的代码的质量.软件质量与开发过程等的整个主题要广泛得多,而不是这个问题的范围.)
代码质量似乎并不受欢迎.我的经验中的一些例子包括
可能每个Java开发人员都知道JUnit,几乎所有语言都实现了xUnit框架,但在我所知道的所有公司中,只有很少的正确单元测试存在(如果有的话).我知道由于技术限制或紧迫的截止日期,并不总是可以编写单元测试,但在我看到的情况下,单元测试可能是一种选择.如果开发人员想为他/她的新代码编写一些测试,他/她可以这样做.我的结论是开发人员不想编写测试.
静态代码分析通常在小型项目中进行,但并不真正用于强制执行编码约定或在企业项目中发现可能的错误.通常甚至会忽略像潜在空指针访问这样的编译器警告.
会议发言人和杂志会谈论很多关于EJB3.1,OSGI,云和其他新技术,但几乎没有关于新的测试技术或工具,新的静态代码分析方法(例如SAT解决方案),有助于保持更高质量的开发流程,如何遗留代码的一些讨厌的野兽被测试,...(我没有参加很多会议,它可能在敏捷主题的会议上看起来不同,因为单元测试和CI等具有更高的价值.)
那么为什么代码质量如此不受欢迎/被认为无聊呢？
编辑:
谢谢你的回答.其中大多数涉及单元测试(并已在相关问题中进行了讨论).但是还有很多其他的东西可以用来保持代码质量很高(参见相关问题).即使您无法使用单元测试,也可以使用每日构建,向IDE或开发过程添加一些静态代码分析,尝试配对编程或强制执行关键代码的审核.