关于java:测试用例千万不能随便记录由一个测试用例异常引起的思考

一

测试用例大家平时写不写？

我以前写测试用例只是针对业务接口，每个接口写一个，数据case也只是测一种。能跑通就能够了。要不同的场景case，那就改数据。从新跑一遍。简略省事。

然而自从我业余时间开始保护开源后，开始加深了对测试用例的了解。甚至我当初曾经把测试用例的位置晋升了与外围代码一样重要的位置，我曾戏称过光写外围代码不写测试用例代码的都是耍流氓行为。

开源我的项目面对的是的所有人，每个人每个公司的环境都不同，我的项目构造也不一样，jdk，spring体系的版本，第三方依赖包都不一样。所以开源框架必须要在所有的场景下都工作失常。这么多功能点，这么多场景，哪怕我是作者，光靠相熟度是不可能记起来那么多细节点的，这时候测试用例就显得十分重要了，它是整个我的项目的最要害的品质保障。很多时候，我都是靠测试用例来发现一些边缘细小的bug的。目前我的开源我的项目领有870个测试用例，笼罩了大略90%以上的场景。

这篇文章探讨一个由测试用例引发的测试用例运行机制的问题。

二

事件的起因是一个群里的小伙伴发现某一个单元测试用例在配置项谬误的时候，spring上下文居然执行了2次，而在正确配置的状况下，是失常只启动了一次。这让他很不解，认为是框架出了问题。

他之所以感觉spring启动了2次，是看到日志中呈现了2次springboot的logo打印，2次截然不同的报错：

  .   ____          _            __ _ _ /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \ \\/  ___)| |_)| | | | | || (_| |  ) ) ) )  '  |____| .__|_| |_|_| |_\__, | / / / / =========|_|==============|___/=/_/_/_/ :: Spring Boot ::        (v2.0.5.RELEASE) com.yomahub.liteflow.exception.ELParseException: 程序谬误，不满足语法标准，没有匹配到适合的语法,最大匹配致[0:7]    at com.yomahub.liteflow.builder.el.LiteFlowChainELBuilder.setEL(LiteFlowChainELBuilder.java:124) ~[liteflow-core-2.8.2.jar:na]    at com.yomahub.liteflow.parser.helper.ParserHelper.parseOneChainEl(ParserHelper.java:391) ~[liteflow-core-2.8.2.jar:na]    at com.yomahub.liteflow.parser.el.XmlFlowELParser.parseOneChain(XmlFlowELParser.java:20) ~[liteflow-core-2.8.2.jar:na]    at java.util.ArrayList.forEach(ArrayList.java:1259) ~[na:1.8.0_292]    at com.yomahub.liteflow.parser.helper.ParserHelper.parseDocument(ParserHelper.java:217) ~[liteflow-core-2.8.2.jar:na]    at com.yomahub.liteflow.parser.base.BaseXmlFlowParser.parse(BaseXmlFlowParser.java:40) ~[liteflow-core-2.8.2.jar:na]      .   ____          _            __ _ _ /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \ \\/  ___)| |_)| | | | | || (_| |  ) ) ) )  '  |____| .__|_| |_|_| |_\__, | / / / / =========|_|==============|___/=/_/_/_/ :: Spring Boot ::        (v2.0.5.RELEASE) com.yomahub.liteflow.exception.ELParseException: 程序谬误，不满足语法标准，没有匹配到适合的语法,最大匹配致[0:7]    at com.yomahub.liteflow.builder.el.LiteFlowChainELBuilder.setEL(LiteFlowChainELBuilder.java:124) ~[liteflow-core-2.8.2.jar:na]    at com.yomahub.liteflow.parser.helper.ParserHelper.parseOneChainEl(ParserHelper.java:391) ~[liteflow-core-2.8.2.jar:na]    at com.yomahub.liteflow.parser.el.XmlFlowELParser.parseOneChain(XmlFlowELParser.java:20) ~[liteflow-core-2.8.2.jar:na]    at java.util.ArrayList.forEach(ArrayList.java:1259) ~[na:1.8.0_292]    at com.yomahub.liteflow.parser.helper.ParserHelper.parseDocument(ParserHelper.java:217) ~[liteflow-core-2.8.2.jar:na]    at com.yomahub.liteflow.parser.base.BaseXmlFlowParser.parse(BaseXmlFlowParser.java:40) ~[liteflow-core-2.8.2.jar:na]

测试用例代码为：

@RunWith(SpringRunner.class)@TestPropertySource(value = "classpath:/whenTimeOut/application1.properties")@SpringBootTest(classes = WhenTimeOutELSpringbootTestCase.class)@EnableAutoConfiguration@ComponentScan({"com.yomahub.liteflow.test.whenTimeOut.cmp"})public class WhenTimeOutELSpringbootTestCase {    @Resource    private FlowExecutor flowExecutor;    //其中b和c在when状况下超时，所以抛出了WhenTimeoutException这个错    @Test    public void testWhenTimeOut1() throws Exception{        LiteflowResponse response = flowExecutor.execute2Resp("chain1", "arg");        Assert.assertFalse(response.isSuccess());        Assert.assertEquals(WhenTimeoutException.class, response.getCause().getClass());    }}

开源框架在源代码层面，不可能被动去再次启动spring上下文(事实上想做我也不晓得如何去做)。而且正确配置状况下，是失常的。而且spring的@Configuration的也启动了2次，从线程堆栈上来看，也是由Junit这里触发的：

值得一提的是，报出的错是在springboot启动环节。所以压根就没进入@Test润饰的测试用例代码里。所以和代码写什么没有关系。我测试了下，如果在测试代码里抛出异样，spring上下文是只启动一次的。

所以这个问题可能到这就完结了，因为并非框架自身的问题，Junit自身在启动spring失败的状况触发了2次初始化spring的动作，可能是一种Junit的重试的机制。这并非我能管制，反正真的有错，也会抛出来，也不必care具体初始化几次，也不影响我的测试用例的整体成果的，把具体测试用例改对就行了。

三

然而我之后在解决一个测试用例时忽然想到了对于测试用例的Spring加载的机制，从而联想到之前的问题。忽然豁然开朗。

咱们用例的构造个别都是，一个测试用例代表了一个大的场景，外面的每一个办法代表了一种具体的case。假如1个类带上10个test具体用例，那么当你点击类上的Run Test的时候，spring会被初始化多少次呢。

答案是1次，springboot test为了放慢运行测试用例的过程，不可能每一个办法都去初始化一遍spring的。在这一个类里的spring的上下文都会缓存起来，这10个办法都会共享同一个spring上下文。

具体的运行机制是：在点下类的Run Test的时候，会去先初始化spring，而后开始运行一个个测试方法，当测试方法运行的时候，如果发现没有初始化spring，还会初始化一遍spring。这就解释了，当咱们独自运行办法的run test的时候，也会初始化一遍spring。

当初就能够解释前文的问题了，因为初始化失败了，在运行办法时发现还没初始化，所以又进行了初始化。

然而对于不同的Test类的话，还是会初始化多遍的。也就是说，每一个类都会初始化一遍spring。这在你运行多个测试用例时应该能发现。

四

再额定引申一个问题：有没有人碰到过运行所有测试用例时总会有几个始终报错，然而单个运行却又齐全失常的问题呢？

如果你有碰到过的话，那肯定是疏忽了以下这个留神点：

如果你抉择全副运行测试用例，尽管每个测试用例类初始化一遍spring，然而JVM从始至终却只启动了一次。而你那些定义在类里的static的变量，不会随着spring启动而发生变化。当你全副运行的时候，有可能你出错的测试用例某些援用的static变量还是上个测试用例遗留下来的数据。所以可能会报错。而单次运行的时候，则没有这种景象。

如果你碰到了这种状况，你得在测试用例里应用@AfterClass这个注解，在注解申明的办法里把这次测试用例中的static变量给清空。这样就能够一起去运行了。例如我的每一个测试用例都去去继承一个BaseTest办法，在外面写上这个办法用于清空static的缓存：

public class BaseTest {    @AfterClass    public static void cleanScanCache(){        ComponentScanner.cleanCache();        FlowBus.cleanCache();        ExecutorHelper.loadInstance().clearExecutorServiceMap();        SpiFactoryCleaner.clean();        LiteflowConfigGetter.clean();    }}

五

对于测试用例该怎么写，有什么罕用的写法。这里不作过多阐明，本人百度一下，应该能够找到一大把教程，或者有趣味，也能够去浏览我的开源我的项目LiteFlow中的测试用例。

测试用例除了能够确保你的我的项目品质，还能够清晰的看到你整个测试用例笼罩了你多少的代码行。我这里的测试用例是独自列工程去写的。用以区别外围工程包。

而后在IDEA里去独自配置执行testcase的工作：

而后去点run xxx with coverage按钮运行测试用例：

多个测试工程之间，运行好一个会弹出对话框问你是否想把这次的后果退出到总的后果里去，间接点add就能够了：

你所有的测试用例工程运行好，在右侧会得出一个如下的报告页面：

这里在最下面能够看到我整个测试用例的笼罩行数是79%。但这并不示意我的项目笼罩场景只有79%。行笼罩和性能场景笼罩是2个概念，这里只是示意所有的测试用例运行完，跑了所有代码行的比例。

最初心愿大家千万不能漠视测试用例，尽管有时我写的想吐，然而最初你会领会到它的甜。