长沙手机网站设计,郴州旅游,ui设计案例欣赏分析,wordpress cx udy楔子四年前我虽然也写了很多年代码#xff0c;由于公司虽然规模不小#xff0c;却并非一家规范化的软件公司#xff0c;因此在项目中严格意义上来说并没有架构设计、也不写单元测试#xff0c;后来有幸加入了一家公司#xff0c;这家公司虽然也是一家小公司#xff0c;但… 楔子四年前我虽然也写了很多年代码由于公司虽然规模不小却并非一家规范化的软件公司因此在项目中严格意义上来说并没有架构设计、也不写单元测试后来有幸加入了一家公司这家公司虽然也是一家小公司但是好歹曾经聘请过一位架构师这位架构师使用spring.net 搭建了一套基础的技术架构并在公司推广使用EnterpriseArchiture(EA)软件设计UML图但是由于种种原因他试用期还没过只是简单的设计了几个业务之后就离职了。我加入这家公司的时候距离这位架构师离职也已经有相当长的时间未能直接学习的机会但是非常还能接触到这位优秀架构师留下来的部分代码和资料这为我的职场之路打开了新的窗户从这些资料中学到了许多之前一直想学但是没机会学的内容并第一次接触到单元测试这种技术。然而值得讽刺的是在他搭建的项目架构中单元测试代码也只有一个简单的示例并没有针对业务功能编写任何的具体测试代码而实际上经手这个项目的开发者已经超过了几十个人其实这也从一个侧面说明中国相当一部分.Net 开发者跟我一样几乎都不写单元测试。甚至是不少开源代码贡献者他们贡献的开源组件也并没有设计单元测试的代码。但是再来看国外的一些优秀的开源组件往往也都会提供单元测试的代码TDD实际上正是一种非常便捷高效门槛低的设计模式。后来我经手的每一个项目都会按照TDD的方式写单元测试但是依然没有深刻领悟单元测试的精髓只是把它当做代码调试的一个入口而已。其实这种单元测试依然不合格尤其是认真的运行一下代码覆盖率报告之后就会发现单元测试的代码覆盖率只有10个点与微软的官方标准单元测试覆盖率100%相比简直就是不合格。什么是单元测试一直以来大家有一种错误的理念总是认为单元测试作为一种测试方法主要是由测试工程师来主导的一种测试手段。并非如此借用教科书上的说法单元测试作为一种最基础的测试手段其主要作用是“在计算机编程中针对程序模块最软件设计中的最小单元进行正确性检验的测试工作。”之前曾经阅读过一篇文章作者提了一个例子他说他儿子在使用乐高积木做玩偶过程中组装完一些零部件之后就会试图去测试一下部件是否能够正常运转作者说这种过程实际上就是一种单元测试。他认为单元测试的思想其实普遍存在于人类文明的发展过程中从人类开始制作工具来说就需要使用单元测试的方法对工具的可用性进行测试。尤其是进入工业时代以来传统制造业尤其重视产品质量为了提高产品质量采取了一系列措施这种例子其实不胜枚举。去年我曾经有幸为一家国企开发过一些质量管理系统并深入了解了这些企业的质量管理流程虽然从宏观层面来看以互联网经济为代表的新兴经济对以包括制造业在内的实体经济带来了许多冲击但是依然那些优秀的制造业企业依然坚定的将产品质量作为核心竞争力并通过互联网的这种模式让企业的发展获得了新的机遇。软件行业其实本质上和制造业没有那么巨大的区别以软件开发过程中由软件工程师们开发出来的每一个方法实际上就是开发者们解决虚拟世界生存问题的零部件每一个产品或应用就是这样的工具。在一个软件开发过程中往往需要涉及到多人操作经常需要调用别人编写的模块代码。尤其是在面向互联网开发中如果不能认真的对待每一行代码就有可能一些疏忽大意造成不可弥补的后果。因此做好单元测试不仅仅只是开发者们应该采用的一种测试手段而是应该是一种基本的技术手段对我们开发的每一行代码都应该使用单元测试进行覆盖自己负责的模块定义应该尽量明确模块内部的更改不会影响他模块让模块的质量得到稳定和良好的保证。为什么大家认为单元测试不合时宜当然大部分开发者也许明白这个道理但是却认为单元测试不合时宜主要包括以下几点1没有时间 ---- 在软件开发过程中往往以完成任务为第一要务而由于时间计划的安排单元测试的设计和实践均需要花费大量的时间完成过度的使用单元测试会拖延项目的进度而且花费的边界成本高昂而收效甚微。 ---- 笔者认为跟随代码一起设计和应用单元测试并不会显著的带来时间上的损害反而会让开发者更加关注代码本身的目的让输入输出和计算过程更为合理。2计划会变化需求变化快单元测试跟不上需求的变化 由于软件产品需求的不确定性导致之前设计的单元测试并非符合项目的实际功能性需求没必要花费这个精力设计这种没用的场景。 ----笔者认为需求变化与是否应用单元测试关系不大。3单元测试是用来找Bug的应该有测试来编写 单元测试作为一种测试手段是为了发现代码中存在的bug。 --- 笔者认为单元测试的目的是为了让程序作者更加快捷的发现代码中存在的问题并在第一时间发现和解决从而保障软件质量。4有程序员定义的单元测试没有意义因为程序员设定的逻辑场景就有可能不准确 单元测试作为由程序员根据实际用例出发设计的测试流程本身可能并非符合业务的实际应用需要因此单元测试应该由最了解需求的人来进行设计。而且完成单元测试设计后也需要有了解需求的人对单元测试用例和代码进行审查。 --- 笔者认为由程序员开发的单元测试没有意义那么他写的代码呢写代码本身就是为了完成指定的用例场景如果单元测试都不合理那么如何确保代码本身就合理5、TDD测试驱动不过是一种形式主义本身就不合时宜 在TDD模式中测试先于开发所以需要经过良好的设计和定义最好能够解耦合各个模块让代码更加完美的匹配测试代码。但是这种代码本身就要求经验丰富的开发者才能完成而能够完成这种能力的本身就属于优秀开发者并不需要设计单元测试代码。 -- 笔者认为优秀的开发者本身不仅仅只是因为他们出身优秀而是因为他们掌握了包括单元测试等在内的优秀学习方法并每天都在实践。好的单元测试的标准笔者最近阅读《构建之美》第一版深刻认同提出的关于好的单元测试的标准例如以下几点 1、单元测试应该在最低的功能\参数上验证程序的正确性。 2、单元测试应该由最熟悉代码的人程序的作者来写。 3、单元测试过后机器状态保持不变。---笔者认为不仅仅机器的状态应该保持不变数据中存储的数据关系也应该保持不变例如通过单元测试录入的数据应该在完成测试后自动回滚或者添加测试戳记后手动清除。 4、单元测试要快一个测试的运行时间是几秒钟而不是几分钟。 5、单元测试应该产生可重复、一致的结果。 6、单元测试具有独立性的特点单元测试的运行、通过、失败不依赖于别的测试可以认为构造数据以保持单元测试的独立性。 7、单元测试应该负载所有的代码路径。 8、单元测试应该继承到自动测试的框架中。 9、单元测试必须与产品代码一起保存和维护。何妨不试一试呢在软件企业的发展前期往往会由于技术上的一些偶发性突破取得短期的优势但是随着企业的规模发展使用更加规范化甚至成为形式化的方式确保产品的质量是必然趋势而单元测试则是一种看似简单但却效果显著的手段相信通过一段时间的实践就会深刻的领悟到其中的妙处。由于时间仓促可能没什么干货下一篇再进一步讨论单元测试、代码覆盖率的问题。原文地址https://www.cnblogs.com/xiyuanMore/p/10618130.html.NET社区新闻深度好文欢迎访问公众号文章汇总 http://www.csharpkit.com