写个代码测试一下

语句覆盖:路径:abc ,测试用例:x=3,y=2 分支覆盖:路径:aeg ,测试用例:x=4,y=-1 /** * 2016-04-09 * @author 吴思婷 * DoWork类用来根据程序流程图,写出代码(定义一个类和方法来实现) */ public class DoWork { public void doWork(int x,int y){ int k=0,j=0; if((x<4 || y>0)&&(y>1)){ y=y+1; } else { if(x&

测试 目前主流的就bdd和tdd,自己查一下差异 推荐 mocha和tape 另外Jasmine也挺有名,angularjs用它,不过挺麻烦的,还有一个选择是qunit,最初是为jquery测试写的,在nodejs里用还是觉得怪怪的. 如果想简单可以tap,它和tape很像,下文会有详细说明 mocha mocha是tj写的 https://github.com/mochajs/mocha var assert = require("assert") describe('truth',

单元测试在一个完整的软件开发流程中是必不可少的.非常重要的一个环节.通常写单元测试并不难,但有的时候,有的代码和功能难以测试,导致写起测试来困难重重.因此,写出良好的可测试的(testable)代码是非常重要的.接下来,我们简要地讨论一下什么样的代码是难以测试的,我们应该如何避免写出难以测试的代码,以及要写出可测试性强的代码的一些最佳实践. 什么是单元测试(unit test)? 在计算机编程中,单元测试(英语:Unit Testing)又称为模块测试, 是针对程序模块(软件设计的最小单位)来进

前言:代码测试,无疑是编程环节中重要一环,重要到什么程度呢?假如治理雾霾就是编程,如果想把雾霾治理好,最最重要的无非就是减少工业污染,而代码测试就是这样,它能够从根源上就杜绝bug的发生.实战经验告诉我,在编程的过程中,当你顺利的把代码敲完毕了,那么及时的跟上一次代码肉眼扫描,以及通过SVN版本库的对比,或者是和你认可的同事进行代码的检测,当你对重要的代码写一小段测试用例后,你会发现,你已经能够修正了大量的bug,如果按照bug10个量记的话,一遍代码测试能够做到7个bug的消除. 与客户患难与

第3部分 软件研发工作总结 既要写好代码,又要写好文档 对于软件相关行业,在学校或单位上,大家也许都已经注意到了,除了要编写的程序.绘制设计图之外,还有一个重要的工作便是写文档.为什么要写文档呢?因为我们要把自己做的东西展示出来,不光展示给同行看,可能还要展示给其他岗位上的工作人员看,甚至展示给用户看.如果我们只是会写程序,不会在文档中描述自己的想法,那么就真正的成为"码农"了. 工作也有一段时间了,我发现周围的同事,会写高质量文档的确实很少.李开复老师在<浪潮之巅>的序言

我在我的微博上说过这样一段话,我想在这里把我的这个观点阐述地更完整一些. @左耳朵耗子:聪明的程序员使用50%-70%的时间用来思考,尝试和权衡各种设计和实现,而用30% – 50%的时间是在忙碌着编码,调试和测试.聪明的老板也会让团队这样做.而傻逼的老板,苦逼的程序员会拿出来100%-150%的时间来忙着赶进度,返工,重构,fix 大量的bug… 所以, 越差的团队一般会越忙,而且还忙不完. 在现在这个浮躁的时期,再加上敏捷咨询师们念的歪经,他们让人感觉上就像是软件产品是可以在很短的时间内高质

前序 在工作之余浏览公司的技术网站,看到了以下这篇文章,细细读来真心觉得不错,写得有价值很实在.于是想联系下作者,问一下是否可以转载.打开钉钉一搜,作者是资深技术专家,差不多就是技术总监级别啊,这也从侧面旁征了,以下的内容是有其亲身经历,切实体会的,而不是鸡汤口号之流.相较与作者的级别,自己确实惭愧汗颜,所以没好直接聊天询问而是在文章底下留言.在得到了作者的同意后将文章的内容贴到这里,作为分享也作为自己的鞭策和提醒.在这里谢谢我的大牛同事了^_^. ....................以下内

本文是漫谈架构专栏的第八篇,作者 Kevin 举例介绍了如何写好代码.当我们有了好的架构,那就需要考虑如何将架构落地,而这个时候,代码就显得无比重要了!千万不要让代码成为架构扩展的瓶颈.文中作者提到了代码架构,细细品味吧. 在第六章中,我们得出一个结论,软件架构实际上包括了:代码架构,以及承载代码运行的硬件部署架构.实际上,硬件部署架构最终还是由代码的架构来决定.因为代码架构不合理,是无法把一个运行单元分拆出多个来的,那么硬件架构能分拆的就非常的有限,整个系统最终很难长的更大. 所以我们经常会听

比起写业务代码更不幸的是,主要工作是修 Bug,bug,buG, bUg. 在一家大的公司里,不同的人总会有不同的运气: 运气好的人遇上一个好的项目,升职加薪,从此就走上了人生的巅峰. 运气差的人摊上一个差的项目,升不了职,少加了薪,并且还获得不了技术成长. 我刚毕业那会儿,所在团队的主要工作是,维护一个『又老又旧』的系统.比起写业务代码更不幸的是,我们的主要工作是修 Bug,bug,buG, bUg. 那一年多里,尽管都是维护旧系统和少量的新需求,我们还是在飞速的成长~~.而来源主要是: 组内