我以前写测试用例只是针对业务接口，每个接口写一个，数据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个概念，这里只是表示所有的测试用例运行完，跑了所有代码行的比例。
最后希望大家千万不能忽视测试用例，虽然有时我写的想吐，但是最后你会体会到它的甜。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
