用junit5编写一个类ZeroCode的测试框架
发布时间：2020-03-19 19:33:08 所属栏目：资源 来源：站长网
导读：技术 点： 最近笔者在尝试基于应用日志来自动生成 测试 用例 。这其中就需要一个配套的简易测试框架。梳理了一下，其中的技术点有： 0.使用csv文件来定义测试用例及步骤 1.使用自定义测试注解来定义测试用例（参考ZeroCode) 2.使用 Junit5 提供的extension
|
技术点： 最近笔者在尝试基于应用日志来自动生成测试用例。这其中就需要一个配套的简易测试框架。梳理了一下，其中的技术点有： 0.使用csv文件来定义测试用例及步骤 1.使用自定义测试注解来定义测试用例（参考ZeroCode) 2.使用Junit5提供的extension机制来实现测试执行 3.使用简单工厂类提供执行驱动 4.使用OpenCsv来实现解析 5.使用Lombok来定义Java Bean 6.使用Junit5提供的参数化测试解决方案junit-jupiter-params来实现测试用例集 来自ZeroCode的参考 ZeroCode是一个轻量级的开源测试框架。它通过使用JSON或者YAML文件格式来定义测试用例，进而让测试用例的编写变得更为容易。 以下是其github项目首页提供的案例 其中test_customer_get_api.yml中就描述了这个接口测试用例的全部要素，具体如下： 这个YAML文件中包括了http接口测试中所需要的请求（含url、head、类型)以及返回、验证模式等内容，是一个不错的用例DSL。本身这是一个很好的开源测试框架，涵盖的测试类型也比较多，参与维护的人员和更新速度也不错。 实际项目中的需求 在实际的测试过程中，对于文本格式的测试用例，往往有以下的需求： 测试用例的步骤描述通常是自定义的，而不是根据工具提供的DSL来编写。 用例编写尽可能少一些冗余的内容，以便节约用例编写时间。例如在前述接口测试案例中的head,Content-Type等等，在某个系统的接口规范中，往往都是规定了固定格式的。 可能的话，@Test之类的Java代码也不用写了。测试人员只写用例文件，框架通过扫码文件目录和文件来执行用例。 为了实现上述需求，这就要求根据测试的特点，来定制一个类似的简易测试框架。 使用文件来定义测试用例和步骤 当设计一个自动化测试用例框架时，有一个很重要的三联问问题: 如何定义一个用例？如何定义用例的步骤？如何定义一个用例集？ 在本案例中，我们约定 一个文件（csv)是一个用例 文件中的一行是用例的一个步骤 包含若干文件的目录，组成了一个用例集 至于用csv文件来作为用例的载体，而不是json/yaml等更新的文件类型，或者xml/excel等传统文件类型，主要是基于以下两方面考虑 接口自动化测试，尤其是面向业务功能的测试，其请求、入参、出参的结构相对固定。 csv擅长表达结构固定的数据内容，且格式冗余最小。 因此，如果以前述ZeroCode的接口为例，一个简单的接口自动化测试的用例格式可以是 读者可能会问，那么head,content-type这些不要了么？status code 都等于200么？实际项目中经常用到的token怎么没有体现？等等问题。 这里我们假设， head,content-type,token这些内容在功能测试时，基本属于不变化的内容。 status code =200,如果有业务层面的错误，在response中可以通过errorCode的方式体现。 每个框架都有其应用场合。上面这样的框架，主要是应用于业务层面的测试，而不是接口自身的鲁棒性测试等场合。这样简单的格式，也非常适合不太能写代码的同学来写自动化测试用例。 以下是编写完成以后的一个测试用例的样例 其中的sample.csv中的内容就是前述表格中的内容 [未完待续] 自定义注解 我们来看下测试用例中的注解的具体实现： 通过@Scenario 在某个方法上的注解，可以调用 @ExtendWith(ScenarioExtension.class) 中的具体功能。这也是JUnit5提供的一种回调机制，来扩展Junit5测试框架的功能。 具体的Extension JUnit5提供了非常友好的扩展性，最常用的是Before/After配套的一些Callback接口上，如下图所示： 这里我们就使用了一个BeforeTestExecutionCallback的接口来进行扩展，在被注解的用例执行之前，Junit5会首先调用该接口，实现自定义的功能。 通过实现BeforeTestExecutionCallback 接口中的beforeTestExecution方法，可以将传入的用例文件内容（测试步骤）进行解析，并交给一个Runner进行执行。 执行器Runner相关 再来看一下Runner接口 其中的run接口用于具体的执行。作为示例，这里先给一个MockRunner 实际工作中可以使用Rest-Assured等工具来实现HTTP接口的调用，并进行结果的验证。如果是TCP等类型的接口，换一种具体实现即可。 有经验的读者可能已经想到了，这就是一个典型的工厂设计模式的使用场景。我们用一个简单工厂作为示例： 目前这个工厂只提供MockRunner一种实现。 业务Bean -TestStep 测试步骤的Bean 如下： 通过Lombok极大地简化了代码。而通过opencsv,可以极为方便地实现csv文件和bean之间地转换。 只要通过opencsv5.0提供的建造者方法一行代码就能完成了。 小节 至此，一个简单的自定义文件的测试框架就构建完毕了，从测试用例来看，测试方法体可以是ZeroCode,基本实现了全部测试用例在文件中体现的目标。总结一下使用到的技术点: 0.使用csv文件来定义测试用例及步骤 1.使用自定义测试注解来定义测试用例（参考ZeroCode) 2.使用Junit5提供的extension机制来实现测试执行 3.使用简单工厂类提供执行驱动 4.使用OpenCsv来实现解析 5.使用Lombok来定义Java Bean 至于参数化构建，我们将在后续完成。 （编辑：武汉站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |