vlambda博客
学习文章列表

项目从了解需求 并编写验证需求的测试用例开始。由于此时代码不存在，因此测试用例将失败。然后，编写通过测试用例的代码。这个过程迭代直到测试用例和所需的代码完成以实现业务功能。 Kent Beck 有一本关于这个主题的优秀书籍 Test Driven Development by Example。在下一节中，我们将重做 Chapter 4 中的产品服务， 使用本章中的原则扩展您的云原生应用程序。但在此之前，让我们看看另一个重要的概念，BDD。

借鉴敏捷开发原则和用户故事，BDD 鼓励我们将开发视为一组场景，其中，在特定条件下，系统会以特定的、可预测的方式对设定的刺激进行行为。如果这些场景、条件和动作可以在业务和 IT 团队之间以一种易于理解的通用语言来捕捉，这将为开发带来很多清晰性，并减少犯错的机会。这是一种编写易于测试的规范的方法。

在本章中继续前进，我们将使用 Cucumber 工具获取我们的产品服务并对其应用 BDD。

A/B 测试（也称为 拆分测试）的初衷是实验 找出几个选定用户对 same 的两个不同网页的用户响应 功能。如果与另一组相比，用户对某个模式的反应良​​好，则选择该模式。

这个概念可以扩展到分阶段引入新功能。将功能、活动、布局或新服务介绍给一组受控用户并测量响应：

测试窗口结束后，将汇总结果以计划更新功能的有效性。

这种测试的策略是，对于选定的一组用户，使用 HTTP 302（临时重定向）将用户从常规网站切换到新设计的网站。这将需要在测试期间运行网站或功能服务的变体。一旦测试成功，该功能会慢慢扩展到更多用户，并合并到主网站/代码库中。

通常，被测功能依赖依赖于其他团队独立开发的组件和API，具有以下缺点：

因此，test double 的概念变得流行起来。测试替身（如电影中的特技替身）是替换实际组件并模仿其行为的组件/API。测试双重组件通常是轻量级且易于更改的组件，由构建功能的团队控制，与可能是依赖项或外部流程的真实组件不同。

Test Stubs

Test 当下游组件返回改变被测系统行为的响应时，存根很有用；例如，如果我们的产品服务要调用参考数据服务，其输出决定产品服务的行为。参考数据服务的测试存根可以模拟导致产品服务行为变化的各种响应类型：

Mock objects

下一种类型的测试替身是 Mock 对象，它记录 system 的行为方式，然后呈现记录以供验证.例如，一个 Mock 数据库组件可以检查是否没有为应该从缓存层而不是数据库响应的产品调用它。

这是 Mocks 周围生态系统的基本图表表示：

单元测试的目的是测试每个类或代码 component 并确保它执行<一个 id="id288371778" class="indexterm"> 符合预期。 JUnit 是用于单元测试的流行 Java 框架。

使用 Mock 对象模式和测试存根，可以隔离被测试服务的依赖组件，以便测试集中在被测系统，也就是服务上。

JUnit 是最流行的单元测试工具。

component 测试的目的是检查产品服务等组件是否按预期执行。

 spring-boot-test 等组件有助于运行测试套件并在 whole 组件。我们将在本章中看到这一点。

负载测试包括在一段时间内向被测系统推送大量并发请求并观察效果，​​如响应系统上的时间和错误率。如果添加更多服务实例使其能够处理 额外负载，则称该系统具有水平可扩展性。

JMeter 和 Gatling 是覆盖这个维度的流行工具。

在引入 new 功能时，不应破坏现有功能。回归测试涵盖了这一点。

Selenium 是一个基于 Web 浏览器的开放 source 工具，在这个领域很流行，用于执行回归测试。

代码的人工审查由自动代码审查工具增强。这有助于识别代码中任何可能的错误，并确保覆盖范围完整且所有路径都经过测试。

稍后我们将查看代码覆盖率工具 JaCoCo。

第一步是回忆我们产品服务的规范。在第 4 章中， 扩展您的云原生应用程序< /span>，我们在产品服务上构建了一些功能，允许我们获取、添加、修改和删除产品，并获取 product 给定产品类别的 ID。

让我们将其表示为 Cucumber 中的特征。

Spring Boot Test 扩展并简化了 Spring Framework 提供的Spring-test 模块。让我们看看编写 acceptance 测试的基本要素，然后我们可以在本章后面重新审视细节：

        <dependency> 
            <groupId>org.springframework.boot</groupId> 
            <artifactId>spring-boot-starter-test</artifactId> 
            <scope>test</scope> 
        </dependency> 

您可能已经注意到，scope 更改为 test。这意味着我们定义的依赖项对于正常运行时不是必需的，仅用于编译和测试执行。

        <dependency> 
            <groupId>info.cukes</groupId> 
            <artifactId>cucumber-spring</artifactId> 
            <version>1.2.5</version> 
            <scope>test</scope> 
        </dependency> 
        <dependency> 
            <groupId>info.cukes</groupId> 
            <artifactId>cucumber-junit</artifactId> 
            <version>1.2.5</version> 
            <scope>test</scope> 
        </dependency> 

CucumberTest class 是启动 Cucumber 测试的主类：

@RunWith(Cucumber.class) 
@CucumberOptions(features = "src/test/resources") 
public class CucumberTest { 
    
} 

RunWith 告诉 JUnit 使用 Spring 的测试支持，然后使用 Cucumber。我们给出了 .feature 文件的路径，该文件包含前面讨论的 Gherkin 中的测试用例。

Productservice.feature 文件 是包含 Gherkin 语言场景的文本文件，如前所述。我们将在这里展示两个测试用例。该文件位于 src/test/resources 文件夹中。

CucumberTestSteps 类包含将 Gherkin 中的步骤翻译成等效的 Java 代码。每个步骤对应一个方法，这些方法是根据 Gherkin 文件中的场景构建来调用的。让我们讨论与一个用例相关的所有步骤：

@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT) 
@ContextConfiguration 
public class CucumberTestSteps { 
  
    @Autowired 
    private TestRestTemplate restTemplate; 
  
    private ResponseEntity<Product> productResponse; 
    private ResponseEntity<String> errResponse; 
  
    @Given("(.*) Service is running") 
    public void checkServiceRunning(String serviceName) { 
         ResponseEntity<String> healthResponse = restTemplate.getForEntity("/health",String.class, new HashMap<>()); 
         Assert.assertEquals(HttpStatus.OK, healthResponse.getStatusCode()); 
    } 
  
    @When("get (.*) service is called with existing product id (\d+)$") 
    public void callService(String serviceName, int prodId) throws Throwable { 
         productResponse = this.restTemplate.getForEntity("/"+serviceName+"/" + prodId, Product.class, new HashMap<>()); 
    } 
  
    @Then("I should get a response with HTTP status code (.*)") 
    public void shouldGetResponseWithHttpStatusCode(int statusCode) { 
         Assert.assertEquals(statusCode, productResponse.getStatusCodeValue()); 
    } 
     
    @And("return Product details with name (.*) and category (\d+)$") 
    public void theResponseShouldContainTheMessage(String prodName, int categoryId) { 
         Product product = productResponse.getBody() ; 
         Assert.assertEquals(prodName, product.getName()); 
         Assert.assertEquals(categoryId, product.getCatId());       
    } 

@SpringBootTest 注解告诉 Spring Boot Framework 它是一个测试类。 RANDOM_PORT 表示测试服务在随机端口启动Tomcat进行测试。

我们注入一个自动连接的 restTemplate ，这将有助于访问 HTTP/REST 服务并接收将被测试的响应。

现在，注意带有注释的方法 @Given、@When 和 @Then< /代码>。每个方法都使用正则表达式来提取变量（从特征文件中）并将其用于方法中的断言。我们通过执行以下操作系统地测试了这一点：

您将看到控制台启动并显示启动消息。最后，JUnit 将测试结果反映如下：

作为一个练习，尝试将测试用例添加到插入、更新和删除 产品方法中"literal">ProductService 类。

JaCoCo 是 EclEmma 团队开发的一个代码 coverage 库。 JaCoCo 在 JVM 中嵌入了一个代理，它扫描遍历的代码路径并创建报告。

该报告可以导入更广泛的 DevOps 代码质量工具，例如 SonarQube。 SonarQube 是一个平台，它通过众多插件帮助管理代码质量，并与 DevOps 流程很好地集成（我们将在后面的章节中看到）。它是开源的，但也有商业版本。它是一个平台，因为它具有多个组件，例如服务器（计算引擎服务器、Web 服务器和 Elasticsearch）、数据库和特定于语言的扫描仪。

Integrating JaCoCo

让我们将 JaCoCo 集成到我们现有的项目中：

1. First, include the plugin that includes JaCoCo in the POM file:

<plugin> 
   <groupId>org.jacoco</groupId> 
   <artifactId>jacoco-maven-plugin</artifactId> 
   <version>0.7.9</version> 
</plugin> 

Copy

Note

第二步和第三步是在前面的插件中包含预执行和后执行。

2. The pre-execution prepares the agent to be configured and added to the command line.
3. The post-execution ensures that the reports get created in the output folders:

<executions> 
   <execution> 
         <id>pre-unit-test</id> 
         <goals> 
               <goal>prepare-agent</goal> 
         </goals> 
         <configuration> 
               <destFile>${project.build.directory}/coverage-reports/jacoco-ut.exec</destFile> 
               <propertyName>surefireArgLine</propertyName> 
         </configuration> 
   </execution> 
   <execution> 
         <id>post-unit-test</id> 
         <phase>test</phase> 
         <goals> 
               <goal>report</goal> 
         </goals> 
         <configuration> 
               <dataFile>${project.build.directory}/coverage-reports/jacoco-ut.exec</dataFile> 
   <outputDirectory>${project.reporting.outputDirectory}/jacoco-ut</outputDirectory> 
         </configuration> 
   </execution> 
</executions> 

Copy

4. Finally, the created command-line change has to be inserted into the maven-surefire-plugin as follows:

<plugin> 
   <groupId>org.apache.maven.plugins</groupId> 
   <artifactId>maven-surefire-plugin</artifactId> 
   <configuration> 
         <!-- Sets the VM argument line used when unit tests are run. --> 
         <argLine>${surefireArgLine}</argLine> 
         <excludes> 
               <exclude>**/IT*.java</exclude> 
         </excludes>        
   </configuration> 
</plugin> 

Copy

5. Now, we are all set to run the coverage report. Right-click on the project and select Run As | Maven test to test the program, as shown in the following screenshot:

6. As the console gets filled with the Spring Boot initiation, you will find the following lines:

2 Scenarios ([32m2 passed[0m) 
8 Steps ([32m8 passed[0m) 
0m0.723s 
Tests run: 10, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 26.552 sec - in com.mycompany.product.CucumberTest......Results :Tests run: 10, Failures: 0, Errors: 0, Skipped: 0[INFO] [INFO] --- jacoco-maven-plugin:0.7.9:report (post-unit-test) @ product ---[INFO] Loading execution data file D:AppswkNeonch5-producttargetcoverage-reportsjacoco-ut.exec[INFO] Analyzed bundle 'product' with 6 classes 

Copy

7. This tells us that two scenarios were executed with 8 Steps (as before). But in addition, coverage-reports got generated and placed in the target directory:

8. In the site folder, click on index.html; you will see the coverage report as follows:

9. On investigation of the product package, you can see that the ProductService is only 24% covered, as shown in the following screenshot:

10. The reason for this is that we have covered only the getProduct API in the service. The insertProduct and updateProduct have not been covered. This is showcased in the drill-down report in the following screenshot:

11. On the getProduct method, the coverage is complete. This is because, in two scenarios, we have covered the happy path as well as the error condition:

12. On the other hand, you will find that we have missed covering the branches in the ExceptionHandler class as follows: