一
测试用例大家平时写不写？
我以前写测试用例只是针对业务接口，每个接口写一个，数据 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 个概念，这里只是示意所有的测试用例运行完，跑了所有代码行的比例。
最初心愿大家千万不能漠视测试用例，尽管有时我写的想吐，然而最初你会领会到它的甜。