junit

#2017-2018-2 学号20165329 实验二《Java面向对象程序设计》实验报告 ##一、实验内容及步骤 ###(一)单元测试 ####（1）三种代码 举例：我们要在一个MyUtil类中解决一个百分制成绩转成“优、良、中、及格、不及格”五级制成绩的功能。 测试结果： ####(2)TDD(Test Driven Devlopment, 测试驱动开发) TDD的一般步骤： 明确当前要完成的功能，记录成一个测试列表 快速完成编写针对此功能的测试用例 测试代码编译不通过 编写产品代码 测试通过 对代码进行重构，并保证测试通过 循环完成所有功能的开发 基于TDD，我们不会出现过度设计的情况，需求通过测试用例表达出来了，我们的产品代码只要让测试通过就可以了。 TDD的编码节奏： 增加测试代码，JUnit出现红条 修改产品代码 JUnit出现绿条，任务完成 测试结果： ###(二)面向对象三要素 抽象 抽象一词的本意是指人在认识思维活动中对事物表象因素的舍弃和对本质因素的抽取。抽象是人类认识复杂事物和现象时经常使用的思维工具，抽象思维能力在程序设计中非常重要，"去粗取精、化繁为简、由表及里、异中求同"的抽象能力很大程度上决定了程序员的程序设计能力。 抽象就是抽出事物的本质特征而暂时不考虑他们的细节。对于复杂系统问题人们借助分层次抽象的方法进行问题求解；在抽象的最高层

#前言   随着期末的到来，对于面向对象程序设计课程的学习也迎来了尾声。在最后一个月的从课程中，笔者对于面向对象程序规格实现层面的单元测试、正确性论证以及使用UML图描述程序的设计进行了深入的学习。通过对类和方法进行规格实现进行单元测试以及论证，检查并确认实现的正确性，使得相应代码拥有更高的可靠性。通过使用UML类图、时序图、状态图对系统的功能、结构、行为等层面进行描述，使面向对象程序具有更清晰的结构设计，提高程序的质量。本文通过对相关知识进行调研，就电梯调度系统这一案例绘制UML图并作分析。在本文的最后笔者还会对本学期所学的面向对象程序设计知识进行总结。 ##正确性论证与测试 单元测试：   在作业中，笔者就已经以电梯调度系统为案例进行了全覆盖的单元测试。运用 JUnit4 为每个类中的每个方法设计单元测试样例。通过覆盖方法中每行代码与每个分支，设置测试点，从而检测方法运行的正确性。这一环节能够对方法进行比较全面的检测，检查代码运行结果是否符合预期。笔者也在单元测试的过程中，发现了方法中选择分支设置上的问题。 正确性论证：   在最近的一次作业，笔者对于电梯调度系统每个类和方法进行了实现层面的正确性论证。从抽象对象实现的有效性、对象有效性、方法实现有效性三个方面对系统实现层面有效性进行了逻辑证明。在抽象对象层面，论证类的抽象对象对于数据管理的有效性；在对象有效性层面

关键字：JUnit，Ant，单元测试 终于把JUnit+Ant构建单元测试的大概了解了，其实我实践的过程是对了，只是指导博客（看到这里不懂请看我上一篇博客）本身的错误“成功”把我带入“坑”，有时候网友发布的教程也不是百分百正确。接下来的内容记录了我从解决上一篇遗留的问题到进行新的单元测试。 指导博客的错误： 对于一个三角形，应该返回一个1而不是返回0，所以在测试程序的时候这里是测试失败的，所以才导致我上一篇博客的一系列错误。正确的有效类测试应该将0改为1，这样测试出来的结果才正确并通过。所以，简单总结一下就是：首先确保自己正确了解整个程序的运行过程，如果连怎么调试这个程序都是模棱两可的话，给指导博客你按部就班都没有用。其次，就是当出现bug的时候注意看一下错误提示，是哪里出现了问题，该怎么解决，看自己的需要测试的代码和测试用例有没有写错，没办法解决的话某度会给你答案。最后，善于总结很重要，谁也不希望在跌倒过的地方再次跌倒吧！ 一篇简单完整的JUnit+Ant构建自动的单元测试如下： 1.创建项目——创建需要测试的类 我这里以需要测试的类test为例 public class test { public int judgeScore( int x) { if (x>=90 ) return 1 ; else if (x>=80 ) return 2 ; else if (x>=70

​ 随着第四单元UML第二次作业的结束，本学期的OO学习也宣告结束了（但还得写博客），下面就对本单元和本次作业做一个总结。 第四单元两次作业的架构设计 ​ 本单元是对UML的结构进行解析，第一次作业是对UML类图的解析，主要的难度是UML各种元素之间较为复杂的从属以及其他关系。我的类图设计如下： ​ 我自己创建了ClassModel类来统领两个子类ClassClass和InterfaceClass，分别代表类和接口，其中实现了添加、储存、处理类和接口的各种下设参数的方法和变量，让类和接口的类继承同一个父类非常重要，因为类和接口有很多相似的地方，再进行输入处理时也有很多不易区分也不用区分是类还是接口的情况，所以这样处理极大地方便了程序对这两个类地储存和管理。对于方法我创建了OperationClass来添加储存和管理方法的各种属性，然后ClassClass和InterfaceClass就只用储存和管理OperationClass即可，对于其他的属性由于没有更多的层次，所以就直接使用接口提供的UML类来进行储存和管理即可。 ​ 在进行输入处理的过程中，由于其结构的层次性，应该将各种属性的UML_ELEMENT分批来处理，我首先识别处理了UML_CLASS,UML_INTERFACE,UML_OPERATION, UML_ASSSOCIATION_END,

问题： What are unit tests, integration tests, smoke tests, and regression tests? 什么是单元测试，集成测试，冒烟测试和回归测试？ What are the differences between them and which tools can I use for each of them? 它们之间有什么区别，我可以为每个工具使用哪些工具？ For example, I use JUnit and NUnit for unit testing and integration testing. 例如，我将JUnit和NUnit用于单元测试和集成测试。 Are there any smoke testing or regression testing tools? 有烟雾测试或回归测试工具吗？ 解决方案： 参考一： https://stackoom.com/question/2BI8/什么是单元测试-集成测试-冒烟测试和回归测试 参考二： https://oldbug.net/q/2BI8/What-are-unit-tests-integration-tests-smoke-tests-and-regression-tests 来源： oschina 链接： https://my.oschina.net/u

引入maven依赖 <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>${junit.version}</version> <scope>test</scope> </dependency> 创建测试用例（建议以方法为单位编写单元测试用例） Demo.java public class Demo { public String method() { return "This is a demo method."; } } DemoTest.java 来源： oschina 链接： https://my.oschina.net/u/4267236/blog/4261026

Spring框架提供了测试工具spring-test <dependency> <groupId>org.springframework</groupId> <artifactId>spring-test</artifactId> <version>${spring.version}</version> <scope>test</scope> </dependency> spring-test可以结合JUnit很轻松的进行单元测试 import org.junit.runner.RunWith; import org.springframework.test.context.Contex 来源： oschina 链接： https://my.oschina.net/u/4390958/blog/4261027

传统的Spring做法是使用.xml文件来对bean进行注入或者是配置aop、事物，这么做有两个缺点： 1、如果所有的内容都配置在.xml文件中，那么.xml文件将会十分庞大；如果按需求分开.xml文件，那么.xml文件又会非常多。总之这将导致配置文件的可读性与可维护性变得很低。 2、在开发中在.java文件和.xml文件之间不断切换，是一件麻烦的事，同时这种思维上的不连贯也会降低开发的效率。 为了解决这两个问题，Spring引入了注解，通过"@XXX"的方式，让注解与Java Bean紧密结合，既大大减少了配置文件的体积，又增加了Java Bean的可读性与内聚性。 不使用注解： 先看一个不使用注解的Spring示例，在这个示例的基础上，改成注解版本的，这样也能看出使用与不使用注解之间的区别，先定义一个老虎： package com.spring.model; public class Tiger { private String tigerName="TigerKing" ; public String toString(){ return "TigerName:"+ tigerName; } } 再定义一个猴子： package com.spring.model; public class Monkey { private String monkeyName =

0. 前言 　　这段时间完成了第二阶段的Java作业练习，第一阶段是入手，那么这个阶段则是这之后的学习打基础；这几次作业主要是加强我们对面向对象的封装性、继承性、多态性特征的理解，下面是我对此次作业的总结分析。 1.作业过程总结 （1） 三次作业之间的知识迭代关系 　　第4次作业涉及数据检验及处理，类的继承。要求我们依题设计正确的正则匹配，实现多种数据格式的检验及处理，还有就是理解继承特性。 　　第5次作业是在作业4的铺垫下，让我们加强理解类的继承、多态性；第6次作业相对于前两次来说，更加简单，也是在前者的练习过后，更加理解了类的多态使用方法，而且这次作业还加入了接口的应用，让程序处理更加多样了。 （2） 通过作业逐步理解面向对象的封装性、继承性、多态性特征 　　作业不会刻意的说用到这几个特征，但代码实现上就会反映出这些特征，这也是面向对象编程的重要体现。理解见下文中的对这三个特性的理解。 （3） 作业过程中遇到的问题及解决方法 　　①作业4中题一对输入的数据进行有效性校验要求较高，因此在应对数据的格式测试上挺让人头疼的。具体如下： 　　 　　既然有这么多种不同的格式，这就需要不断地细分，对一条信息进行数据校验、对各种不同数据进行校验、对不同数据的不同格式进行校验……具体的实现就不一一罗列了，总之就是不断地切分功能，最后整合到一起。 　　②作业5题二、使用类的继承

准备好的依赖包 把依赖包拷贝到我们的pom.xml内 新建test包，然后按照下面路径建包 首先演示command，那就先创建command包 创建CommandDemo 继承HystrixCommand指定泛型为String，然后实现Run方法。 上面之所以还会报错，是因为还需要构造函数，然后把name传递进来。 把name属性初始化，然后提供getter和setter方法 构造函数传递进来的name就赋值给我们内部的属性name run方法就是单词请求调用的业务方法 run方法就是在架构图中的这个位置。run方法就是Command业务的执行。 返回这个result 使用command 创建测试类。 我们现在要做的事情就是执行execute() 这里面有两个方法，一个是run方法，一个是execute。执行run方法就不去执行前面那一堆的逻辑 execute在前面。run在后面。 如果直接执行run。前面那些熔断都执行不到了。所以在这里我们不会执行run方法。 输出我们的返回值 加上Junit测试的注解 执行测试 command构建大概就是这样 结束 来源： oschina 链接： https://my.oschina.net/u/4397293/blog/4260687