junit

Junit 4.11里增加了指定测试方法执行顺序的特性 测试类的执行顺序可通过对测试类添加注解 “@FixMethodOrder(value)” 来指定,其中value 为执行顺序 三种执行顺序可供选择：默认（MethodSorters.DEFAULT），按方法名（MethodSorters.NAME_ASCENDING）和JVM（MethodSorters.JVM） 当没有指定任何顺序时，按默认来执行 Sorters 1. MethodSorters.DEFAULT 默认顺序由方法名hashcode值来决定，如果hash值大小一致，则按名字的字典顺序确定 由于hashcode的生成和操作系统相关(以native修饰），所以对于 不同操作系统，可能会出现不一样的执行顺序 ，在某一操作系统上，多次执行的顺序不变 实现代码: /** * DEFAULT sort order */ public static Comparator<Method> DEFAULT = new Comparator<Method>() { public int compare(Method m1, Method m2) { int i1 = m1.getName().hashCode(); int i2 = m2.getName().hashCode(); if (i1 != i2) { return i1

Brief Junit 4.11里增加了指定测试方法执行顺序的特性 测试类的执行顺序可通过对测试类添加注解 “@FixMethodOrder(value)” 来指定,其中value 为执行顺序 三种执行顺序可供选择：默认（MethodSorters.DEFAULT），按方法名（MethodSorters.NAME_ASCENDING）和JVM（MethodSorters.JVM） 当没有指定任何顺序时，按默认来执行 Sorters 1. MethodSorters.DEFAULT 默认顺序由方法名hashcode值来决定，如果hash值大小一致，则按名字的字典顺序确定 由于hashcode的生成和操作系统相关(以native修饰），所以对于 不同操作系统，可能会出现不一样的执行顺序 ，在某一操作系统上，多次执行的顺序不变 实现代码: /** * DEFAULT sort order */ public static Comparator<Method> DEFAULT = new Comparator<Method>() { public int compare(Method m1, Method m2) { int i1 = m1.getName().hashCode(); int i2 = m2.getName().hashCode(); if (i1 != i2) {

由于需要做自动化测试，所以需要比较完善的单元测试。但是又因为某些测试的执行依赖另外一个测试产生的结果，所以希望所写的test case按照自己希望的顺序来执行。 随后博主查阅资料发现了FixMethodOrder注解，可以有三种方式可以控制test执行顺序。 　　/** * Sorts the test methods by the method name, in lexicographic order, with {@link Method#toString()} used as a tiebreaker */ NAME_ASCENDING(MethodSorter.NAME_ASCENDING), /** * Leaves the test methods in the order returned by the JVM. Note that the order from the JVM may vary from run to run */ JVM(null), /** * Sorts the test methods in a deterministic, but not predictable, order */ DEFAULT(MethodSorter.DEFAULT); 大概上就是上面三种，很多大佬的博客上都对这几种有讲解以及示例，博主在这里就不啰嗦了

转自： JUnit中按照顺序执行测试方式 很多情况下，写了一堆的test case，希望某一些test case必须在某个test case之后执行。比如，测试某一个Dao代码，希望添加的case在最前面，然后是修改或者查询，最后才是删除，以前的做法把所有的方法都集中到某一个方法去执行，一个个罗列好，比较麻烦。比较幸福的事情就是JUnit4.11之后提供了MethodSorters，可以有三种方式对test执行顺序进行指定，如下： /** * Sorts the test methods by the method name, in lexicographic order, with {@link Method#toString()} used as a tiebreaker */ NAME_ASCENDING(MethodSorter.NAME_ASCENDING), /** * Leaves the test methods in the order returned by the JVM. Note that the order from the JVM may vary from run to run */ JVM(null), /** * Sorts the test methods in a deterministic, but not predictable,

敏捷测试策略 在敏捷环境中，我们在短期冲刺或迭代中工作，每个sprint只关注一些需求或用户故事，因此文档在数量和内容方面可能不会那么广泛。 之前我们得出的结论是，由于时间限制，我们可能不需要在每个sprint的敏捷项目中都有一个广泛的测试计划，但我们确实需要一个高级敏捷测试策略作为敏捷团队的指导。 敏捷测试策略文档的目的是列出团队可以遵循的最佳实践和某种形式的结构。请记住，敏捷并不意味着非结构化。 在这里，我们来看一个敏捷测试策略样本以及文档中包含的内容。 有关： 测试策略通常有一个任务陈述，可能与更广泛的业务目标和目标相关。 典型的使命宣言可能是： 通过提供快速反馈 和 缺陷预防而不是缺陷检测，不断提供满足客户需求的工作软件 。 支持者： 在我们首次定义其验收标准/测试之前，不会为故事编写代码 在所有验收测试通过之前，故事可能不被认为是完整的 在敏捷测试策略文档中，我还会提醒每个人关于质量保证 质量保证是一系列活动，旨在确保产品以系统，可靠的方式满足客户要求。 在SCRUM（敏捷）QA是每个人的责任，而不仅仅是测试人员。质量保证是我们为确保新产品开发过程中的正确质量而开展的所有活动。 测试级别 敏捷测试象限 单元测试 为什么： 确保代码正确开发 世卫组织： 开发人员/技术架构师 内容： 所有新代码+遗留代码的重新分解以及Javascript单元测试 时间： 一旦编写新代码 地点

你可能会用单元测试框架，python的unittest、pytest，Java的Junit、testNG等。 那么你会做单元测试么！当然了，这有什么难的？ test_demo.py def inc(x): return x + 1 def test_answer(): assert inc(3) == 4 inc() 是定义的一个被测函数， test_anserver() 用于测试上面的一段代码。 通过pytest运行上面的代码： > pytest test_demo.py ====================== test session starts ======================= platform win32 -- Python 3.7.1, pytest-5.0.1, py-1.8.0, pluggy-0.12.0 rootdir: D:\vipcn\demo plugins: cov-2.7.1, forked-1.0.2, html-1.20.0, metadata-1.8.0, ordering-0.6, parallel-0.0.9, rerunfailures-7.0, xdist-1.28.0, seleniumbase-1.23.10 collected 1 item test_demo.py . [100%] ==============

实现方式 直接使用quartz的CronExpression#isSatisfiedBy(Date date)来判断 在自己程序中创建一个工具类来实现，代码使用quartz的CronExpression 原因： 项目中使用的Spring boot的注解式定时任务，并没有使用quartz，所以为了使用一个CronExpression#isSatisfiedBy(Date date)而引入整个quartz不太合适 quartz的CronExpression类完全可以单独拿出来使用，所以在自己项目中使用同名类，代码使用org.quartz.CronExpression的代码 import org.junit.Assert; import org.junit.Test; import org.quartz.CronExpression; import java.text.SimpleDateFormat; public class TestCron { @Test public void cron() throws Exception { SimpleDateFormat simpleDateFormat = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss"); CronExpression cronExpression = new

Maven通过 Maven Surefire Plugin 插件执行单元测试。（通过 Maven Failsafe Plugin 插件执行集成测试） 在pom.xml中配置JUnit,TestNG测试框架的依赖，即可自动识别和运行src/test目录下利用该框架编写的测试用例。surefire也能识别和执行符合一定命名约定的普通类中的测试方法（POJO测试）。 生命周期中test阶段默认绑定的插件目标就是surefire中的test目标，无需额外配置，直接运行mvn test就可以。 基本配置如下，下文中的配置项如无特殊说明，都位于pom文件的<configuration>节点中。 <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-surefire-plugin</artifactId> <version>2.18.1</version> <configuration> ......　　　　　　配置内容　　　　　　...... </configuration> </plugin> 常用通用配置 跳过测试阶段 <skipTests>true</skipTests> 或者 mvn install -DskipTests 或者 （Compliler插件也会根据该参数跳过编译测试类） mvn

　　maven的重要职责之一就是自动运行单元测试，它通过maven-surefire-plugin与主流的单元测试框架junit和testng集成，并且能够自动生成丰富的结果报表。 　　maven并不是一个单元测试框架，他只是在构建执行打特定的生命周期阶段的时候，通过插件来执行JUnit或testNG的测试用例，这个插件就是maven-surefire-plugin，也叫做测试运行器。maven-surefire-plugin会自动执行测试源码路劲下（src/test/java）的所有符合以下命名模式的测试用例 　　**/Test*.java：任何子目录下的所有命名以Test开头的java类 　　**/**Test.java：任何子目录下的所有命名以Test结尾的java类 　　**/**TestCase.java：任何子目录下的所有命名以TestCase结尾的java类 　　只要将测试类按上述模式命名，maven就能自动运行它们，用户也就不再需要定义测试集合（testsuite）来聚合测试用例了。 　　当然也可以自定义来包含一些不符合上述命名规则的测试类，以下定义以Tests结尾的用例： 1 2 3 4 5 6 7 8 9 10 < plugin > < groupId >org.apache.maven.plugin</ groupId > < artifactId

百度：单元测试（unittesting），是在计算机编程中，针对程序模块（软件设计的最小单位）来进行正确性检验的测试工作。程序单元是应用的最小可测试部件。对于单元测试中单元的含义，一般来说，要根据实际情况去判定其具体含义，如C语言中单元指一个函数，Java里单元指一个类，图形化的软件中可以指一个窗口或一个菜单等。总的来说，单元就是人为规定的最小的被测功能模块。单元测试是在软件开发过程中要进行的最低级别的测试活动，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。通常来说，程序员每修改一次程序就会进行最少一次单元测试，在编写程序的过程中前后很可能要进行多次单元测试，以证实程序达到软件规格书要求的工作目标，没有程序错误。 老师在第二堂课就指出了我的缺点，在一个概念出现的时候，主要注重都是自己的理解，而却忽略了概念本身要表达的意思。这是我一直所缺陷的，所有的概念都是一知半解就以为全都明白，就出去解决问题，弄得遍体鳞伤，回过头来才发现是基本功太不扎实，下面我将用我的话重述单元测试。 JackMing：是最低级别的测试活动，目的是检查软件是否达到最初是的工作目标，所谓单元，根据不同的编程语言，单元划分的方法并不相同，但是可以肯定的是，所划分的单元是最小的被测功能模块，因为再小的话，似乎就没有测试的意义了，那只能叫检查了。程序员每修改一次程序都要进行至少一次单元测试