我目前正在单元测试一个不是很好地支持单元测试的应用程序,很多依赖项,重构和构建应用程序的开发人员在开始开发时没有想到单元测试.我的工作是进行单元测试研究,对应用程序进行单元测试,并将单元测试纳入组织.
当我正在处理应用程序并编写单元测试时,有时候很难保持良好的动机并为代码的困难部分编写好的测试.
现在我的问题是:
1.你怎么能保持自己的积极性来编写好的单元测试？(对于遗留代码)
2.激励您的同事编写单元测试是否重要？
3.作为雇主,您如何让您的员工积极参与编写良好的单元测试？
人们因为福利而受到激励.人们不想做他们认为更多工作的事情.单元测试意味着无需工作.这意味着更多地和女孩一起出去.它意味着更多地放置,因为你不必每晚编码到晚上11点.这意味着更多的假期.这意味着可以更快地为不感兴趣的人们制作软件.
我发现当我开始做TDD(早在2002年或2003年)时,它有点奇怪......但即便只有几天,我开始注意到巨大的生产力优势.
TDD的最大好处是你可以将你的程序重构为更好的设计......或者只是更改某个名称...只要该设计不会破坏测试,你就可以百分之百地相信你的改变没有破坏什么.
显然,项目获得的价值越高,价值越大.对于大规模的项目,这是节省时间的绝对天赐之物.
另一个很大的好处是,如果您应该在系统中创建一个错误,您将立即知道.没有花时间跟踪它.谁喜欢跟踪错误？我不.你的同事也没有.
TDD的目标是编写测试,编写代码并运行测试.如果您在添加一些新代码时发现一大堆测试中断...那么您立即知道导致它的原因.实际上不需要调试器或在程序中放置打印语句以找出错误.节省了这么多时间!
另一个很大的好处是,您可以从您想要的设计开始 - 在高级别,并且在开始编码之前不用担心实现.随着您的进展,您可以努力获得更细粒度的细节.这意味着你的类的设计必然比从自下而上的设计中做事更正确.这意味着不必为了得到你想要的设计而重构它,因为你无法通过树木看到森林.
另一个惊人的好处是你对整个代码更有信心.你知道它有效.事实证明.虽然它不能证明你不会有任何错误,但它确实证明了你想象中可能发生的所有预期问题都得到了解决.
随着经验的积累,你会想出越来越多的方法来打破这个系统.每次你提出一个,你编写一个测试来打破它,然后你编写代码来修复它.在为你想到的一切做到这一点之后,你的系统必将是坚如磐石的.从本质上讲,它只是盲目编码所不能提供的.
这意味着您可以获得成功,而且您不必担心要求您重新开始工作以修复关键错误的电话.
无论如何,这是我对TDD的推销.实惠!