一

测验用例大家平常写不写？

我以前写测验用例仅仅针对业务接口，每个接口写一个，数据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个概念，这儿仅仅表明一切的测验用例运转完，跑了一切代码行的比例。

最终希望大家千万不能忽视测验用例，尽管有时我写的想吐，可是最终你会体会到它的甜。