故事是这样的,我最近深陷在一个刚接手不久的项目中,经过完成两轮需求上线后, 我迫切地告诉自己,需要给这个项目完善一下测试用例(原工程测试用例几乎为零), 然而事情并不是我想象的那么简单。
经过两天给项目引入EasyMock,Jmockit相关测试框架,最终我还是没有完成对其中一个任务Job的测试代码。虽然结果不如我的预期,但这种挫败感反而让我平静,让我思索这一切为何反复发生,像一部递归的电影。
现实就是,大部分程序员在其职业生涯中,半数以上的时间都是工作在别人的代码之上的。
相对于写出不可阅读的代码,写出不可测试的代码的情况更常见。
究其原因,问题还是出在测试上。
通过对相关参考书籍走马观花的阅读,我总结了以下两点书中未提及的现象。
纠正认知
在日常生活中,我们作出很多行为,并不需要考虑一个问题:如何测试行为结果是否符合预期?所以我们基本不会把生活中的未知结果,定义为不可测试。
另外一个现实是,我们进入程序员这个行业的时候,首先学会的是如何利用工具创造(软件开发),然后才衍生出如何测试。创造和测试作为两个完全独立的部分被认知,结果就是我们花更多的时间在创造上。
如今软件工程越来越庞大,业务领域越来越复杂,所以如果要将软件开发分解成创造和测试两个部分的话,我觉得在他们各自的投入上应该是五五开。
我看到的很多工程都是在完成需求上花的时间比测试更多,虽然他们声称测试很重要。
如果整个软件构建链条上的所有人员达成了共识,那么就可以借助相关的技术来完成任务。
保持风格统一
让我们再回到代码工程中,软件开发就像写作,你可以在一定的原则下完成创作,既然是创作就有风格问题。
多人协作的项目里,很容易留下开发人员的风格,所以很多团队推出了自己的工程规范,以及代码规范,比如Google Java Style Guide,尽管这些开发人员熟读了《重构 改善既有代码的设计(第2版 )》这样经典的指导书籍,但风格问题还是会在项目中出现。
当你加入一个项目时,首先要弄清现有工程的风格是什么样的,在重构的过程中尽量避免破坏好的风格,引入自己独特的风格。
总结
回到我的故事,我属于进攻型编程人员,在面对不可测试的的代码时,会让情况变得更糟糕,所以还是反复确认了几个原则:
- 能工作的代码,就尽量不要改善它。
- 在有单元测试的情况下,最小单元修改。
- 不写代码,就不会有BUG。
最后总结:术可以学习,但道却需要领悟。
—— 我是分割线 ——
下面的相关书籍,在开发,测试,重构方面提供了很好指导,值得仔细反复阅读。