19、前端测试与Quarkus集成：从测试执行到架构选择

最新推荐文章于 2025-11-20 09:47:10 发布

lemon

最新推荐文章于 2025-11-20 09:47:10 发布

阅读量27

点赞数

CC 4.0 BY-SA版权

分类专栏： Quarkus与React全栈实战文章标签：前端测试 Quarkus集成微服务架构

本文链接：https://blog.youkuaiyun.com/lemon/article/details/152532106

Quarkus与React全栈实战专栏收录该内容

25 篇文章 ¥499.90

订阅专栏¥69.90

会员秒杀 ¥9.9 重磅福利

超级会员免费看

前端测试与Quarkus集成：从测试执行到架构选择

1. 前端测试执行

测试实现直观、易读且自解释。可以通过点击第一个 describe 块附近的播放按钮，然后点击“Run ‘tasks module tests’”菜单项来执行测试。其他模块、项目和用户的功能测试遵循与身份验证和任务测试相同的模式。

1.1 从命令行运行测试

之前我们从集成开发环境（IDE）中运行测试，这提供了运行单个测试或完整测试套件的便捷方式。但了解如何从命令行执行测试也很重要，这也是在持续集成（CI）管道中配置测试执行的方式。

我们的应用使用 Create React App 启动，它会提供无需维护的脚本，测试脚本也在 package.json 文件中关联。

在测试辅助部分，我们将一些测试辅助文件添加到名为 __tests__ 的目录中。但默认情况下，Jest 会将这些文件也视为测试。为了忽略这些辅助文件，需要修改 Jest 的配置，在 package.json 文件的最后部分添加以下内容：

"jest": {
    "testMatch": ["**/?(*.)+(spec|test).[jt]s?(x)"]
}

这个 testMatch 属性指示 Jest 搜索符合指定全局模式的测试，由于我们的所有测试文件都有 .test.js 后缀，因此会匹配所有测试文件。

从命令行运行测试，只需在前端项目根目录执行以下命令：

npm test

默认的 Create React App 配置会以交互式监视模式启动测试。此模式会运行自上次仓库提交以来更改的测试，并监视更改以在脚本运行时重新运行修改的测试。

如果想在非交互式模式下运行完整的测试套件，可执行以下命令：

npm test -- --watchAll=false

第一个 -- 用于指示后续参数应传递给底层的 react-scripts test 命令， --watchAll=false 标志用于禁用监视模式。

若想查看项目的测试覆盖率，可在上述命令基础上添加 --coverage 参数：

npm test -- --watchAll=false --coverage

2. 应用架构选择：微服务与单体架构

当前我们有一个基于 Quarkus 的后端和一个基于 React 的前端，既可以将应用以分布式微服务的方式部署为独立组件，也可以进行一些小的更改将前端集成到后端，以单体应用的方式分发。

2.1 微服务架构的优势

易于水平扩展 ：当某个服务资源不足时，只需为该服务提供更多副本或实例即可轻松扩展，且每个服务可独立扩展。
关键服务高冗余 ：可以轻松为应用中最关键的部分提供额外实例，并将这些关键服务实例部署在离用户更近的地理位置。
更轻松的部署更新 ：每个服务应与其他服务完全解耦，可独立部署。推出新版本的服务无需对整个应用及其所有服务进行完整部署。
框架和编程语言无关 ：应用可以被拆分为不同的服务和组件，每个组件可以使用不同的技术实现。

2.2 微服务架构的劣势

需要额外的基础设施和自动化 ：微服务操作复杂，需要特定且昂贵的基础设施，如 Kubernetes、亚马逊网络服务等。
服务间通信问题 ：应用被解耦为多个可能需要相互通信的组件或服务，失败的可能性更高。
事务性和数据一致性 ：每个服务依赖自己的数据库或持久化机制，管理跨多个服务或多个域的事务并实现数据一致性具有挑战性。
调试和问题解决困难 ：应用架构的复杂性增加不仅影响 IT 运营，还影响维护和问题解决任务。

2.3 单体架构的优势

无高级扩展需求 ：虽然将 Quarkus 后端和 React 前端作为单个组件分发会失去独立扩展每个组件的能力，但仍可扩展整个单体应用以提供高冗余或应对更高的用户负载。
适合小团队 ：任务管理器的开发和维护可由一个非常小的开发团队管理，将应用拆分为多个服务只会增加团队的任务和工作量。
事务性和数据一致性简单 ：只需一个数据库或持久化提供者，没有影响不同服务的复杂事务，数据一致性由数据库处理。
无需复杂基础设施 ：单体部署任务更简单，只需要一个数据库和应用部署，这意味着更低的基础设施要求和维护成本。

以下表格总结了微服务架构和单体架构的优缺点：
| 架构类型 | 优点 | 缺点 |
| ---- | ---- | ---- |
| 微服务架构 | 易于水平扩展、关键服务高冗余、部署更新轻松、框架和编程语言无关 | 需要额外基础设施和自动化、服务间通信问题、事务性和数据一致性挑战、调试和问题解决困难 |
| 单体架构 | 无高级扩展需求、适合小团队、事务性和数据一致性简单、无需复杂基础设施 | 失去独立扩展组件的能力 |

总体而言，通常应从设计良好的单体应用开始，并随着时间的推移评估是否迁移或演变为分布式架构。目前我们的应用很简单，单体架构是更好的选择，但未来应用可能会发展，需要更复杂的架构。

以下是微服务架构和单体架构的选择流程图：

graph LR
    A[应用架构选择] --> B{应用复杂度和需求}
    B -->|复杂、大量用户、大团队| C[微服务架构]
    B -->|简单、少量用户、小团队| D[单体架构]
    C --> E[优势：扩展灵活、部署独立等]
    C --> F[劣势：基础设施复杂、通信问题等]
    D --> G[优势：无需高级扩展、适合小团队等]
    D --> H[劣势：无法独立扩展组件]

3. 配置 Quarkus 应用以构建前端

若要将 React 和 Quarkus 项目整合为单一部署，需配置 Quarkus 构建过程，使其运行前端构建和打包任务，并处理生成的资源。

3.1 修改 pom.xml 文件

在 Maven 项目的 pom.xml 文件中，需进行如下修改，让 Quarkus 处理前端构建过程生成的资源：

<resources>
    <resource>
        <directory>src/main/resources</directory>
    </resource>
    <resource>
        <directory>src/main/frontend/build</directory>
        <targetPath>frontend</targetPath>
    </resource>
</resources>

此配置会影响 Maven Resources 插件，该插件负责将资源复制到输出或目标目录。第一个条目复制默认设置，即 src/main/resources 目录中的所有文件将被复制到 target/classes 或 ${project.build.outputDirectory} 目录。第二个条目配置插件将 src/main/frontend/build 目录中的所有资源复制到 target/classes/frontend 目录，这使得 Quarkus 能够提供前端资源。

3.2 创建 Maven 配置文件

仅进行上述资源配置，还需手动在前端项目中执行 npm 命令来构建应用，然后再执行 Maven 构建。为实现自动化，可在项目的 pom.xml 文件中添加一个新的 Maven 配置文件：

<profile>
    <id>frontend</id>
    <build>
        <plugins>
            <plugin>
                <groupId>org.codehaus.mojo</groupId>
                <artifactId>exec-maven-plugin</artifactId>
                <version>${exec-maven-plugin.version}</version>
                <executions>
                    <execution>
                        <id>npm-install</id>
                        <phase>generate-resources</phase>
                        <goals>
                            <goal>exec</goal>
                        </goals>
                        <configuration>
                            <workingDirectory>src/main/frontend</workingDirectory>
                            <executable>npm</executable>
                            <arguments>
                                <argument>install</argument>
                            </arguments>
                        </configuration>
                    </execution>
                    <execution>
                        <id>npm-build</id>
                        <phase>generate-resources</phase>
                        <goals>
                            <goal>exec</goal>
                        </goals>
                        <configuration>
                            <workingDirectory>src/main/frontend</workingDirectory>
                            <executable>npm</executable>
                            <arguments>
                                <argument>build</argument>
                            </arguments>
                        </configuration>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>
</profile>

该配置文件定义了一个名为 frontend 的新 Maven 配置文件，其主要目的是运行与前端相关的构建任务。这里使用了 Exec Maven 插件，它允许在单独的进程中执行程序和 Java 程序。
- npm-install 执行配置 ：将 Exec Maven 插件的 exec 目标绑定到 Maven 的 generate-resources 构建生命周期阶段，此阶段在资源复制和项目编译相关阶段之前执行，确保自定义资源配置中定义的资源目录包含所需文件。配置部分设置了执行进程的工作目录（React 项目的相对路径 src/main/frontend ）以及要执行的可执行文件和参数（ npm install ）。
- npm-build 执行配置 ：同样绑定到 generate-resources 阶段，执行 npm build 命令来构建前端项目。

以下流程图展示了配置 Quarkus 构建前端的步骤：

graph LR
    A[开始] --> B[修改 pom.xml 资源配置]
    B --> C[创建前端 Maven 配置文件]
    C --> D[配置 npm-install 执行]
    D --> E[配置 npm-build 执行]
    E --> F[完成配置]

总结

前端测试是确保应用可靠性的重要环节，可通过 IDE 或命令行执行测试，同时要注意处理测试辅助文件。在架构选择方面，微服务架构和单体架构各有优劣，需根据应用的复杂度、团队规模和扩展需求等因素进行权衡。对于当前简单的应用，单体架构是较好的选择，但随着应用的发展，可能需要考虑迁移到微服务架构。在将前端集成到 Quarkus 后端时，通过修改 pom.xml 文件和创建 Maven 配置文件，可以实现前端项目的自动化构建和资源处理。

总之，在开发过程中，要根据实际情况灵活选择测试方式和架构模式，并合理配置构建过程，以提高开发效率和应用的稳定性。