[Refactor] Integration Test Framework Overhaul: Replace Spring Boot Test with Standalone Nacos Server / IT测试框架重构：使用独立Nacos Server替代Spring Boot Test

[KomachiSion]

🌐 Background / 背景

EN: Currently, Nacos integration tests (IT) primarily rely on Spring Boot Test to construct the Nacos server instance. This approach has several significant drawbacks:

• Performance Issues: Multiple Spring container startups cause severe performance degradation
• Resource Contention: Static resources and configurations are prone to mutual interference between tests
• Test Isolation: Lack of proper isolation leads to flaky tests and unreliable results

CN: 当前 Nacos 的集成测试（IT）主要通过 Spring Boot Test 来构造 Nacos Server 实例，这种方式存在以下显著问题：

• 性能问题：多次启动 Spring 容器导致严重的性能下降
• 资源竞争：静态资源和配置容易在测试之间相互干扰
• 测试隔离性：缺乏适当的隔离导致测试不稳定且结果不可靠

The current IT implementation can be found at: https://github.com/alibaba/nacos/tree/develop/test

📦 Current State / 当前进展

EN: A prototype solution has been validated in a forked repository. The approach involves:

• Building Nacos server in CI/CD pipeline (GitHub Actions)
• Starting standalone Nacos server with embedded Derby database
• Running tests as pure JUnit tests without Spring Boot Test dependency

CN: 已在个人 fork 仓库中验证方案可行性，主要思路：

• 在 CI/CD 流水线（GitHub Actions）中构建 Nacos Server
• 启动单机版 Nacos Server（使用嵌入式 Derby 数据库）
• 测试用例不再依赖 Spring Boot Test，作为纯 JUnit 测试运行

Proof of Concept: A sample ConfigOpenAPI IT test class has been implemented to demonstrate the viability of this approach.

🎯 Migration Strategy / 迁移策略

Aspect	Current Approach	Proposed Approach	Benefits
Server Lifecycle	Spring Boot Test per class	Single server in CI	Faster execution, less overhead
Database	Mixed configurations	Embedded Derby (Phase 1)	Consistent test environment
Test Framework	Spring Boot Test + JUnit	Pure JUnit	Reduced complexity, better isolation
Resource Management	Shared Spring context	External process	No static resource conflicts

🛠 Technical Proposal / 技术方案规划

Phase 1: Foundation / 基础建设

# GitHub Actions workflow snippet
- name: Build Nacos Server
  run: mvn clean package -DskipTests

- name: Start Nacos Server
  run: |
    cd distribution/target/nacos-server-*/nacos
    sh bin/startup.sh -m standalone
    # Wait for server ready
    until curl -s http://localhost:8848/nacos/v1/ns/operator/metrics; do sleep 5; done

// Example test structure
public class ConfigOpenAPIIT {
    
    private static final String NACOS_SERVER = "http://localhost:8848";
    
    @Test
    public void testPublishConfig() {
        // Pure HTTP client calls to Nacos OpenAPI
        // No Spring context involved
    }
}

Phase 2: Test Coverage Expansion / 测试覆盖扩展

EN: Gradually migrate existing IT tests to the new framework:

1. OpenAPI Tests - Configuration, Naming, Authority APIs
2. AdminAPI Tests - Administrative operations
3. ConsoleAPI Tests - Console-specific endpoints

CN: 逐步迁移现有 IT 测试到新框架：

1. OpenAPI 测试 - 配置、命名、权限相关 API
2. AdminAPI 测试 - 管理操作相关
3. ConsoleAPI 测试 - 控制台专用接口

Phase 3: Cleanup / 清理阶段

EN: Remove legacy components:

• Old IT configurations in test/ directory
• Deprecated test classes
• Internal dependencies like Nacos.java in console module

CN: 移除遗留组件：

• test/ 目录下的旧 IT 配置
• 废弃的测试类
• console 模块下的 Nacos.java 等内部依赖

📋 TODO List / 任务清单

• Task 1: Supplement OpenAPI test cases / 补充 OpenAPI 测试用例
  • Config OpenAPI tests (参考已实现样例)
  • Naming OpenAPI tests
  • Authority OpenAPI tests
• Task 2: Supplement AdminAPI test cases / 补充 AdminAPI 测试用例
• Task 3: Supplement ConsoleAPI test cases / 补充 ConsoleAPI 测试用例
• Task 4: Remove old IT configurations and test classes / 移除旧的 IT 配置和测试类
• Task 5: Remove internal dependencies from old tests (e.g., console module Nacos.java) / 移除旧测试依赖的内部代码

🔍 Key Discussion Points / 核心讨论方向

1. EN: Should we support external database (MySQL) testing in addition to Derby? / 是否需要支持除 Derby 外的外部数据库（如 MySQL）测试？

2. EN: How to handle test data isolation between different test classes? / 如何处理不同测试类之间的测试数据隔离？

3. EN: Should we provide a test utility library for common operations (setup, teardown, HTTP clients)? / 是否需要提供测试工具库来封装常用操作（初始化、清理、HTTP 客户端）？

4. EN: What's the rollback strategy if the new framework encounters issues? / 如果新框架遇到问题，回滚策略是什么？

🤝 Call for Discussion & Contribution / 社区讨论与贡献方向

EN: This is a significant refactoring effort that will improve the reliability and performance of Nacos integration tests. Community input is welcome on:

• Technical approach and implementation details
• Prioritization of test migration
• Best practices for test data management

CN: 这是一次重要的重构工作，将提升 Nacos 集成测试的可靠性和性能。欢迎社区就以下方面提供意见：

• 技术方案和实现细节
• 测试迁移的优先级
• 测试数据管理的最佳实践

---

Related: #14877

[cxhello]

Great proposal! I've reviewed the PoC in #14877 and have a few suggestions for the roadmap:

1. Migration plan for gRPC/SDK integration tests

The new framework focuses on HTTP API testing, which is a great start. However, the existing IT modules (config-test, naming-test, core-test) also cover scenarios driven by the Java SDK over gRPC — such as config listening (ConfigIntegrationV3CoreITCase), instance registration, and service subscription push (SubscribeNamingITCase).

These scenarios cannot be replaced by pure HTTP tests. I'd suggest adding a phase between Phase 2 and Phase 3 to explicitly classify which old tests can be replaced by HTTP equivalents and which need to be retained or migrated separately. This avoids accidentally losing gRPC protocol coverage when removing old IT classes.

2. Avoid server module dependency in openapi-test

The PoC imports com.alibaba.nacos.config.server.constant.Constants to get API path strings. This couples the test module to server internals, which goes against the decoupling goal. If the server renames or restructures these constants, the tests break silently.

Suggestion: define API path constants directly within the openapi-test module, or promote them to nacos-api if they're part of the public contract.

3. Reuse CI build artifacts to avoid duplicate builds

Currently, a single PR triggers full mvn clean install -Prelease-nacos in three separate workflows (ci.yml, pr-ci.yml, it-new.yml). Since pr-ci.yml already uploads the server tarball as an artifact, it-new.yml could download and reuse it instead of rebuilding from scratch — saving ~10 minutes per run.

Alternatively, consider integrating the IT stage into the existing CI workflow as a dependent job.

4. Add test infrastructure before scaling out test cases

Before expanding to Naming/Auth/Console test suites, it might be worth adding a few foundational pieces:

• @Timeout on test methods — prevents CI from hanging if the server becomes unresponsive (default HTTP client timeout can be very long)
• Server health check in @BeforeAll — fail fast with a clear message instead of cryptic connection errors
• Batch cleanup in @AfterAll — the current try/finally per-test approach won't clean up if deleteConfig itself fails (e.g., server crash mid-suite), which could leave stale data affecting subsequent tests

[KomachiSion]

1. Yes, nacos-client and nacos-maintainer-client also should be added in new-it, it can be added step by step.
2. The current demo is generate by vibecoding, it might some wrong imports, In fact the openapi-test should only depend common and api module.
3. Great suggestion, but new-it depend build strongly, we only can skip the rat, checkstyle and spotbug check, the install should be include.
4. It should be add cases by cases.