neven7的专栏

一.Hamcrest是什么？Hamcrest is a library of matchers, which can be combined in to create flexible expressions of intent in tests.Hamcrest 是一个为了测试为目的，且能组合成灵活表达式的匹配器类库。二.Hamcrest jar包hamcrest-c

（1）背景：之前《JUnit4执行cases背后的故事(1)—JUnitCore源码分析》介绍了JUnit4执行测试用例默认的执行器是BlockJUnit4ClassRunner，它内部是怎么实现的呢？本文将介绍该执行器执行流程，并会举个实例，继承BlockJUnit4ClassRunner，自定义执行器。（2）org.junit.runners.BlockJUnit4ClassRunner是什么？

JUnit执行cases背后的故事—JUnitCore源码分析（1）背景：平常我们执行JUnit用例时，可以使用命令行或在IDE中使用Run As: JUnit Test，直接得到测试结果；但是背后的执行过程是怎么样的，值得我们深思，理解框架代码逻辑，有助于更好的使用该框架（或二次开发），本文将通过分析JUnitCore.java源码一一道来。（2）org.junit.runner.JUnitCor

一.背景：承接上一篇自动化二期（拓展TAOBAO TOAST框架）---支持自定义测试环境；maven工程使用surefire插件，执行"mvn -Dtest=测试类 test"命令，stdout并不支持输出成功用例和skipped用例（JUnit中被注解为@Ignore的类或方法）的信息，只输出Failed和error的用例信息，如下：，故前端无法根据stdout解析出成功的

前言： 在testerhome社区中，有人评论说直接使用TestNG，就可以实现多线程，是的，但是方式不一样；我们是按照自己的需求对JUnit4自定义多线程Runner，直接在某个类加上相应的注解即可，运行该类就行，支持类和方法级别；TestNG只在方法上有注解 @Test(threadPoolSize = m, invocationCount = n, timeOut = i)实现了对这个方法进

一.背景多线程执行用例能很大的节约时间，而JUnit4(org.junit.experimental.ParallelComputer)本身是支持多线程的（以后会专门写一篇介绍JUnit的多线程执行），但是experimental实验性质的，本文多线程执行用例是自己构造线程池，一个线程去执行一个用例，当然这要求你的用例间不能有交集。只运行上一次失败的用例，JUnit4(org.junit.

1.背景之前一篇文章介绍过 JUnit4—实践三：支持多线程，失败重试执行测试case的方法， 是ant 执行用例结束后，根据输出日志（类似：TEST-com.weibo.cases.suite.HugangTestSuite.txt），正则匹配找出错误用例，执行用例（JUnitCore），写结果（Result.txt），并将本次结果失败的用例回写到输出日志（TEST-com.weibo.case

总结一下JUnit4中使用的注解功能：1.@RunWith:一个JUnit4类添加@RunWith或继承的父类添加@RunWith时，JUnit会调用@RunWith指定的class来执行该JUnit4类中的测试方法，而不是JUnit中固定的Runner。JUnit4默认的Runner为BlockJUnit4ClassRunner，当你在Eclipse中新建一个JUnit Test Case时

一.需求（小组内接口自动化由junit4+重试[用例]+多线程[执行用例]+数据库连接池[测试账号]组成，由ant生成junit报告）最近，小组内有人提出了，是否能单独运行某些失败的cases，因为在eclipse中只能运行一个类的全部cases或某个cases； 不能指定跑单个类某些方法或多个类的某些方法。juint4中有@RunWith(Suite.class) 和 @Suite.Suit

一.背景之前介绍过：JUnit4---实践一：运行指定类的某些测试方法，当重跑用例较少时，可以手工添加指定的测试方法，但是测试方法较多且在多个不同的类时，手工添加就比较头大，有必要自动生成指定测试方法。想着有2种方法：1.JUnitCore添加监听器RunListener，获得第一次执行的结果，根据结果聚合出指定的测试方法；2.通过扫结果日志，找到FAILED和ERROR，聚合

一.需求ant junitreport内生的报告中TestCase部分，只包含4部分:Name, Status, Type, Time(s), 分别代表方法名，运行结果，失败信息，运行时间，如下： 但是仅靠Type信息（只打印assertThat错误信息：期望和实际，错误堆栈），无法确认用例具体的失败，只能回到测试工程重新执行用例，再定位失败原因； 故新增CASEID和CASEDESC分别描述