公司不给上外网啊...木有办法只好用这样的方式了.
今天由于家里还是不能上网,所以果断来公司加班以防止在家成为胡子拉碴的宅男过一天跟AI三国杀的日子.
来到办公室发现没有什么人,于是想起这周的工作成果还没有编写单元测试.提起键盘创建了xxxTest类才发现不知道该从何下手.于是随手抄起JUnit in Action读了一章,对TDD大有感悟,但是对我继续开展工作毫无益处.
还是先把读书的感悟留在这里吧.
TDD讲究的是快速高效的开发高质量的代码,也就是不会"腐烂变质"的代码. 接到一个需求之后要先对其进行设计,这里面肯定有对API的设计,即这个类对外的接口.这样一来,根据API就可以创建单元测试类了.在TDD里面,开始着手写代码之前要先进行单元测试类的编写,这个单元测试类是失败的.在随后的开发过程中,要做的事情就是--使这个失败的单元测试成功.这样一来,我们可以保证我们的目的是从最初的API着手,而且还会带来信心.而另一个写单元测试的好处是,如果一个单元测试是成功的,那么我们在重构代码的时候,如果保持着单元测试的成功,那么我们就没有因为重构而破坏原有的代码,这一点其实很重要.至少就我现在而言,提起重构2个字,看到臃肿无比的过程式代码,或者杂乱无章的无层次的业务代码,完全不敢下手更改,只敢利用IDE提供的功能来RENAME几个变量的名字,以在代码整洁的道路上迈进那么一下步.
所以以后再写代码的时候,还是要尽可能的遵循TDD的原则,先写单元测试,再写实现代码,这样才可以保证质量.
俗话说,万事开头难.写博客是一件快乐的事,但是写单元测试就不是了,至少现在对我而言~
现在的问题是:如何对已有的代码写单元测试?什么是有效的单元测试?
原文地址：https://www.jb51.cc/javaschema/287147.html
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
