HarmonyOS开发：集成测试策略——模块集成测试

核心要点：单元测试验证单个函数对不对，集成测试验证模块拼在一起能不能跑通。选对集成策略（自底向上/自顶向下/大爆炸），搞清楚模块间接口怎么测，才能在模块组装阶段把Bug扼杀在摇篮里。

一、背景与动机

你单元测试写了200个用例，全绿，心里美滋滋。结果模块一拼起来——崩了。用户模块返回的数据格式变了，订单模块没跟着改；网络层抛了个新异常，业务层压根没处理这种case。

这种事太常见了。单元测试只管"我这个函数逻辑对不对"，不管"我依赖的那个模块是不是按约定来的"。模块之间的接口、数据格式、异常传递、调用时序——这些东西，单元测试覆盖不了，只有集成测试能搞定。

那集成测试到底怎么搞？一股脑全拼起来测？还是从底层模块开始一层层往上搭？还是从顶层往下推？不同策略各有优劣，选错了要么测试写不出来（依赖没实现），要么Bug发现太晚（组装太迟）。这篇文章把集成测试的策略和实战讲清楚。

二、核心原理

2.1 单元测试 vs 集成测试

先搞清楚这俩到底区别在哪：

一句话总结：单元测试验证"砖头"质量，集成测试验证"房子"能不能住。

2.2 集成测试策略分类

flowchart TB
    A[集成测试策略] --> B[自底向上<br/>Bottom-Up]
    A --> C[自顶向下<br/>Top-Down]
    A --> D[大爆炸<br/>Big Bang]
    A --> E[三明治<br/>Sandwich]

    B --> B1[从底层模块开始]
    B --> B2[需要驱动模块]
    B --> B3[底层Bug早发现]

    C --> C1[从顶层模块开始]
    C --> C2[需要桩模块Stub]
    C --> C3[接口问题早发现]

    D --> D1[所有模块一起测]
    D --> D2[无需驱动/桩模块]
    D --> D3[Bug定位困难]

    E --> E1[顶层+底层同时推进]
    E --> E2[中间层最后集成]
    E --> E3[兼顾接口与实现]

    classDef mainStyle fill:#4CAF50,stroke:#388E3C,color:#fff,font-weight:bold
    classDef bottomStyle fill:#3498DB,stroke:#2980B9,color:#fff
    classDef topStyle fill:#2ECC71,stroke:#27AE60,color:#fff
    classDef bangStyle fill:#F44336,stroke:#D32F2F,color:#fff
    classDef sandwichStyle fill:#9B59B6,stroke:#8E44AD,color:#fff

    class A mainStyle
    class B,B1,B2,B3 bottomStyle
    class C,C1,C2,C3 topStyle
    class D,D1,D2,D3 bangStyle
    class E,E1,E2,E3 sandwichStyle

2.3 各策略详解

自底向上（Bottom-Up）

从最底层的工具模块开始，逐步向上集成。底层模块没有依赖，直接测；测完上层模块时，底层已经验证过了，用真实依赖。

优点：底层Bug在早期就能发现，不需要写桩模块。
缺点：需要写驱动模块（Driver）来调用被测模块，顶层接口问题发现得晚。

自顶向下（Top-Down）

从最顶层的业务模块开始，逐步向下集成。上层模块依赖的下层模块还没实现，用桩模块（Stub）模拟。

优点：接口问题在早期就能发现，能尽早验证主流程。
缺点：需要写桩模块，底层Bug发现得晚。

大爆炸（Big Bang）

所有模块同时组装，一起测试。简单粗暴。

优点：不用写驱动模块和桩模块，省事。
缺点：Bug定位极其困难——出了问题，你不知道是哪个模块的锅。

三明治（Sandwich）

自顶向下和自底向上同时推进，中间层最后集成。兼顾了两者的优点，但测试管理复杂度更高。

2.4 策略选择决策

你的项目是什么情况？

├─ 模块少（<5个）且接口简单
│   └─ 大爆炸，别折腾了
│
├─ 底层模块稳定，上层频繁变动
│   └─ 自底向上，底层先验证
│
├─ 接口设计是最大风险
│   └─ 自顶向下，接口问题早暴露
│
└─ 中大型项目，模块多
    └─ 三明治，两头推进

三、代码实战

3.1 基础用法：模块接口测试

先看一个最典型的场景——用户服务模块依赖数据仓库模块，验证两者之间的接口契约：

// UserRepository.ets - 数据仓库模块
export class UserRepository {
  // 根据用户ID查询用户信息
  async getUserById(userId: string): Promise<UserInfo> {
    const db = await this.getDatabase()
    const result = await db.query('SELECT * FROM users WHERE id = ?', [userId])
    if (result.length === 0) {
      throw new Error(`用户不存在: ${userId}`)
    }
    return result[0] as UserInfo
  }

  // 创建新用户
  async createUser(user: UserInfo): Promise<string> {
    const db = await this.getDatabase()
    return await db.insert('users', user)
  }
}

// UserService.ets - 业务服务模块，依赖UserRepository
export class UserService {
  private repo: UserRepository

  constructor(repo: UserRepository) {
    this.repo = repo
  }

  // 获取用户详情，附带格式化
  async getUserDetail(userId: string): Promise<UserDetail> {
    const user = await this.repo.getUserById(userId)
    return {
      id: user.id,
      displayName: `${user.lastName}${user.firstName}`,
      age: this.calculateAge(user.birthday),
      status: user.active ? '活跃' : '停用'
    }
  }

  private calculateAge(birthday: string): number {
    const birth = new Date(birthday)
    const now = new Date()
    let age = now.getFullYear() - birth.getFullYear()
    if (now.getMonth() < birth.getMonth() ||
        (now.getMonth() === birth.getMonth() && now.getDate() < birth.getDate())) {
      age--
    }
    return age
  }
}

集成测试的重点不是验证calculateAge算得对不对（那是单元测试的事），而是验证UserService和UserRepository之间的接口调用是否正确：

// UserServiceIntegrationTest.ets
import { describe, it, beforeAll, afterAll, assertEqual, assertNotNull } from '@ohos/hypium'
import { UserService } from '../UserService'
import { UserRepository } from '../UserRepository'

export default function userServiceIntegrationTest() {
  describe('UserService与UserRepository集成测试', () => {
    let userService: UserService
    let userRepo: UserRepository

    beforeAll(async () => {
      // 使用真实的UserRepository，不是Mock
      userRepo = new UserRepository()
      userService = new UserService(userRepo)
      // 初始化测试数据
      await userRepo.createUser({
        id: 'test-001',
        firstName: '三',
        lastName: '张',
        birthday: '1990-05-15',
        active: true
      })
    })

    afterAll(async () => {
      // 清理测试数据
      await userRepo.deleteUser('test-001')
    })

    it('getUserDetail_正常返回格式化数据', 0, async () => {
      const detail = await userService.getUserDetail('test-001')
      // 验证接口返回的数据格式符合UserDetail契约
      assertNotNull(detail)
      assertEqual(detail.id, 'test-001')
      assertEqual(detail.displayName, '张三')
      assertEqual(detail.status, '活跃')
    })

    it('getUserDetail_用户不存在时抛出异常', 0, async () => {
      try {
        await userService.getUserDetail('non-exist-id')
        // 如果没抛异常，测试失败
        assertEqual(true, false, '应该抛出异常但没有')
      } catch (e) {
        // 验证异常从Repository正确传播到Service
        assertNotNull(e)
        assertEqual((e as Error).message.includes('用户不存在'), true)
      }
    })
  })
}

3.2 进阶用法：自底向上集成测试

假设项目有三个层次：网络层 → 数据层 → 业务层。自底向上就是从网络层开始，逐步向上集成：

// ==================== 第一步：测试网络层（底层，无依赖） ====================
// HttpClientTest.ets - 网络层独立测试
import { describe, it, assertEqual, assertNotNull } from '@ohos/hypium'
import { HttpClient } from '../HttpClient'

export default function httpClientTest() {
  describe('HttpClient底层测试', () => {
    const client = new HttpClient('https://api.example.com')

    it('get_正常请求返回响应体', 0, async () => {
      const response = await client.get('/health')
      assertEqual(response.statusCode, 200)
      assertNotNull(response.body)
    })

    it('get_404返回错误码', 0, async () => {
      const response = await client.get('/not-exist')
      assertEqual(response.statusCode, 404)
    })
  })
}

// ==================== 第二步：网络层+数据层集成 ====================
// ApiRepositoryTest.ets - 数据层依赖网络层
import { describe, it, beforeAll, assertEqual, assertNotNull } from '@ohos/hypium'
import { ApiRepository } from '../ApiRepository'
import { HttpClient } from '../HttpClient'

export default function apiRepositoryIntegrationTest() {
  describe('ApiRepository与HttpClient集成', () => {
    let repo: ApiRepository

    beforeAll(() => {
      // 使用真实的HttpClient，不是Mock
      const httpClient = new HttpClient('https://api.example.com')
      repo = new ApiRepository(httpClient)
    })

    it('fetchUsers_返回用户列表', 0, async () => {
      const users = await repo.fetchUsers()
      assertNotNull(users)
      assertEqual(users.length > 0, true)
      // 验证数据层对网络层返回的JSON解析正确
      assertEqual(typeof users[0].id, 'string')
      assertEqual(typeof users[0].name, 'string')
    })

    it('fetchUsers_网络错误时抛出业务异常', 0, async () => {
      // 使用错误的URL触发网络错误
      const badClient = new HttpClient('https://invalid.url.example')
      const badRepo = new ApiRepository(badClient)
      try {
        await badRepo.fetchUsers()
        assertEqual(true, false, '应该抛出异常')
      } catch (e) {
        // 验证数据层把网络异常转换成了业务异常
        assertEqual((e as Error).message.includes('数据获取失败'), true)
      }
    })
  })
}

// ==================== 第三步：网络层+数据层+业务层集成 ====================
// UserViewModelTest.ets - 业务层依赖数据层
import { describe, it, beforeAll, assertEqual, assertNotNull } from '@ohos/hypium'
import { UserViewModel } from '../UserViewModel'
import { ApiRepository } from '../ApiRepository'
import { HttpClient } from '../HttpClient'

export default function userViewModelIntegrationTest() {
  describe('UserViewModel全链路集成', () => {
    let viewModel: UserViewModel

    beforeAll(() => {
      // 构建完整的依赖链：HttpClient → ApiRepository → UserViewModel
      const httpClient = new HttpClient('https://api.example.com')
      const repo = new ApiRepository(httpClient)
      viewModel = new UserViewModel(repo)
    })

    it('loadUsers_完整链路正常工作', 0, async () => {
      await viewModel.loadUsers()
      // 验证从网络请求到UI数据的完整转换链路
      assertEqual(viewModel.userList.length > 0, true)
      assertEqual(viewModel.isLoading, false)
      assertEqual(viewModel.errorMessage, '')
    })

    it('loadUsers_加载状态正确切换', 0, async () => {
      const loadPromise = viewModel.loadUsers()
      // 验证加载开始时状态正确
      assertEqual(viewModel.isLoading, true)
      await loadPromise
      // 验证加载结束后状态正确
      assertEqual(viewModel.isLoading, false)
    })
  })
}

3.3 完整示例：模块间接口契约测试

接口契约测试是集成测试的核心——验证模块之间的调用约定是否被遵守。下面是一个完整的、可运行的示例：

// ==================== 接口定义 ====================
// IDataProvider.ets - 数据提供者接口
export interface IDataProvider {
  // 查询数据，返回指定类型的结果
  query<T>(sql: string, params?: Array<ParamType>): Promise<Array<T>>
  // 执行写操作，返回影响的行数
  execute(sql: string, params?: Array<ParamType>): Promise<number>
  // 开启事务
  beginTransaction(): Promise<void>
  // 提交事务
  commit(): Promise<void>
  // 回滚事务
  rollback(): Promise<void>
}

// ==================== 接口契约测试 ====================
// DataProviderContractTest.ets - 任何实现IDataProvider的类都必须通过这个测试
import { describe, it, beforeAll, afterAll, assertEqual, assertNotNull, assertThrowError } from '@ohos/hypium'
import { IDataProvider } from '../IDataProvider'
import { RdbDataProvider } from '../RdbDataProvider'
import { MockDataProvider } from '../MockDataProvider'

/**
 * 接口契约测试套件
 * 任何实现IDataProvider的类都应该通过此测试
 * @param providerName 提供者名称
 * @param providerFactory 创建提供者的工厂函数
 */
function dataProviderContractTest(
  providerName: string,
  providerFactory: () => IDataProvider
) {
  describe(`${providerName} 接口契约测试`, () => {
    let provider: IDataProvider

    beforeAll(async () => {
      provider = providerFactory()
      await provider.beginTransaction()
    })

    afterAll(async () => {
      await provider.rollback()
    })

    it('query_空表返回空数组', 0, async () => {
      const result = await provider.query('SELECT * FROM non_exist_table WHERE 1=0')
      assertNotNull(result)
      assertEqual(result.length, 0)
    })

    it('execute_插入数据后可查询', 0, async () => {
      await provider.execute(
        'INSERT INTO test_table (id, name) VALUES (?, ?)',
        ['contract-001', '契约测试']
      )
      const result = await provider.query(
        'SELECT * FROM test_table WHERE id = ?',
        ['contract-001']
      )
      assertEqual(result.length, 1)
      assertEqual(result[0]['name'], '契约测试')
    })

    it('execute_更新数据后查询结果变更', 0, async () => {
      await provider.execute(
        'UPDATE test_table SET name = ? WHERE id = ?',
        ['更新后', 'contract-001']
      )
      const result = await provider.query(
        'SELECT * FROM test_table WHERE id = ?',
        ['contract-001']
      )
      assertEqual(result[0]['name'], '更新后')
    })

    it('execute_删除数据后查询不到', 0, async () => {
      await provider.execute('DELETE FROM test_table WHERE id = ?', ['contract-001'])
      const result = await provider.query(
        'SELECT * FROM test_table WHERE id = ?',
        ['contract-001']
      )
      assertEqual(result.length, 0)
    })

    it('事务_回滚后数据不生效', 0, async () => {
      await provider.execute(
        'INSERT INTO test_table (id, name) VALUES (?, ?)',
        ['rollback-001', '将被回滚']
      )
      await provider.rollback()
      await provider.beginTransaction()
      const result = await provider.query(
        'SELECT * FROM test_table WHERE id = ?',
        ['rollback-001']
      )
      assertEqual(result.length, 0, '回滚后数据不应存在')
    })
  })
}

// 对真实实现运行契约测试
export default function rdbContractTest() {
  dataProviderContractTest('RdbDataProvider', () => new RdbDataProvider('test.db'))
}

// 对Mock实现也运行契约测试，确保Mock行为与真实实现一致
export function mockContractTest() {
  dataProviderContractTest('MockDataProvider', () => new MockDataProvider())
}

四、踩坑与注意事项

坑点1：集成测试不是"大号单元测试"

有人把集成测试写成这样——所有依赖都用Mock，然后调一下被测函数，断言一下返回值。这不就是单元测试吗？集成测试的核心价值是验证模块间交互，不是验证单个函数的逻辑。如果所有依赖都是Mock的，你测的只是Mock的行为，不是真实的模块交互。

原则：集成测试中，被测模块的直接依赖用真实实现，只有外部系统（如远程API、第三方SDK）才用Mock。

坑点2：测试数据不隔离

集成测试操作的是真实数据库或真实文件系统，如果多个测试用例共享数据，执行顺序一变结果就不同。A用例插入了一条数据，B用例查到了这条数据——你以为B的查询逻辑对了，其实是A的副作用。

解决方案：每个测试用例在beforeAll中准备数据，在afterAll中清理数据。更严格的做法是每个用例前后都清理，用beforeEach/afterEach。

坑点3：异步操作没等完就断言

集成测试涉及真实的异步操作（数据库查询、网络请求），如果你忘了await，断言在异步操作完成前就执行了——测试永远"通过"，因为还没到断言那行代码就已经结束了。

// 错误写法：忘了await
it('查询用户', 0, async () => {
  const result = userService.getUserDetail('001')  // 没await！
  assertEqual(result.id, '001')  // result是Promise，不是数据
})

// 正确写法
it('查询用户', 0, async () => {
  const result = await userService.getUserDetail('001')  // 加上await
  assertEqual(result.id, '001')
})

坑点4：桩模块和驱动模块维护成本高

自顶向下需要桩模块，自底向上需要驱动模块。这些辅助代码本身也需要维护——业务接口改了，桩模块也得跟着改。如果桩模块的行为和真实模块不一致，集成测试就失去了意义。

建议：桩模块尽量简单，只返回固定数据。复杂的桩模块本身就需要测试，这就本末倒置了。

坑点5：大爆炸策略的"一锅粥"问题

小项目用大爆炸策略没问题，但模块一多，出了Bug你根本不知道是哪个模块的问题。更糟糕的是，多个Bug叠加在一起，表现出来的现象可能和单个Bug完全不同——你修了一个，另一个才暴露出来。

建议：超过5个模块的项目，别用大爆炸。自底向上或三明治策略虽然前期多写点辅助代码，但后期排查问题的效率高得多。

坑点6：集成测试执行时间过长

集成测试要启动真实数据库、发起真实网络请求，执行速度比单元测试慢几个数量级。如果集成测试套件跑一次要10分钟，开发者就不愿意频繁跑了。

建议：

• 集成测试和单元测试分开执行，CI流水线中只在合并请求阶段跑集成测试
• 使用内存数据库代替文件数据库，加速数据库操作
• 减少不必要的beforeAll/afterAll中的数据准备

坑点7：环境依赖导致测试不稳定

集成测试依赖真实环境——数据库连接、网络状态、文件系统权限。今天跑过了，明天网络抖了一下就挂了。这种"时灵时不灵"的测试比没有测试还可怕，因为它会消磨团队对测试的信任。

建议：对不稳定的外部依赖（如远程API）使用Mock，对可控的本地依赖（如本地数据库）使用真实实现。在测试框架中加重试机制，对偶发失败自动重试1-2次。

五、HarmonyOS 6适配说明

API差异表

行为变更

1. @IntegrationTest装饰器：HarmonyOS 6新增专用集成测试标记，与@Test区分开。集成测试用例在执行时会有更长的超时时间（默认30秒 vs 单元测试的5秒），并且支持自动重试。

2. @InjectTest依赖注入：不再需要手动在beforeAll中构造依赖链，框架自动根据模块依赖关系注入真实实现或Mock对象。

3. TestModule隔离容器：每个测试用例运行在独立的模块容器中，数据完全隔离，不再需要手动清理测试数据。

适配代码

// HarmonyOS 6集成测试写法
import { describe, it, IntegrationTest, InjectTest, TestData } from '@ohos/hypium'
import { UserService } from '../UserService'
import { UserRepository } from '../UserRepository'

@IntegrationTest
export default function userServiceIntegrationTest() {
  describe('UserService集成测试_HarmonyOS6', () => {
    // 框架自动注入UserService及其依赖
    @InjectTest
    let userService: UserService

    // 自动准备和清理测试数据
    @TestData({
      table: 'users',
      records: [
        { id: 'auto-001', firstName: '三', lastName: '张', birthday: '1990-05-15', active: true }
      ]
    })
    it('getUserDetail_自动注入依赖', 0, async () => {
      const detail = await userService.getUserDetail('auto-001')
      assertEqual(detail.displayName, '张三')
    })
  })
}

六、总结

集成测试是单元测试和端到端测试之间的桥梁。单元测试保证砖头质量，集成测试保证房子结构。选对策略是关键——小项目大爆炸省事，大项目自底向上或三明治更稳妥。接口契约测试是集成测试的核心武器，任何实现都必须通过契约测试，才能保证模块间协作不出问题。别把集成测试写成大号单元测试，也别让环境依赖毁了测试的稳定性——这两件事做好，集成测试就能真正发挥价值。