登录解决 Swift Testing 中 DI 容器的竞态条件
欢迎给个 star：RickeyBoy-Github
🎬 背景：单元测试不稳定
当项目逐渐扩大，Unit Test 越来越多的时候，必然会出现问题：某些单元测试有时能通过，有时又不行。最麻烦的是有些时候本地运行能通过，在 CI Pipeline 中又通过不了。
通常来讲本地设备和 CI 设备确实很不一样，一个常见的问题就是存在静态条件（Race Condition）的问题，本篇就尝试从根本上解决这类似的问题，并且从原理层面也讲清楚来龙去脉。
🔁 快速回顾：为什么 DI 很重要
如果是在 SwiftUI 上使用 MVVM 的架构，那 DI （Dependency Injection 依赖注入）对你来说肯定不陌生。这里简单回顾一下，为什么要用 DI
不可测试的 ViewModel
final class CheckoutViewModel {
private let paymentService = PaymentService() // 硬编码的依赖
func placeOrder() async throws {
try await paymentService.charge(amount: 99.99)
}
}
这个 ViewModel 直接持有了它的依赖。想在测试中把 PaymentService 换成 mock？根本换不了。
可测试的 ViewModel
final class CheckoutViewModel {
private let paymentService: PaymentServiceProtocol
init(paymentService: PaymentServiceProtocol) {
self.paymentService = paymentService
}
func placeOrder() async throws {
try await paymentService.charge(amount: 99.99)
}
}
现在我们可以在测试中注入 mock，在生产环境中使用真实服务了：
// 生产环境
let vm = CheckoutViewModel(paymentService: StripePaymentService())
// 测试
let vm = CheckoutViewModel(paymentService: MockPaymentService())
生产环境中，ViewModel 连接真实服务。测试中，由 mock 替代：
道理很简单，小项目用着也没问题。但随着 app 不断膨胀，事情就开始变味了。
💥 MVVM 的依赖问题
构造器注入复杂度爆炸
现实中的 ViewModel 不可能只有一个依赖，随着业务迭代它们只会越来越多：
init(
paymentService: PaymentServiceProtocol,
orderRepository: OrderRepositoryProtocol,
analyticsTracker: AnalyticsTrackerProtocol,
authService: AuthServiceProtocol,
featureFlagService: FeatureFlagServiceProtocol
) { ... }
而且如果父级 ViewModel 需要创建子级 ViewModel，那父级就必须知道子级的全部依赖。往下嵌套三层之后再新增一个依赖，你就得一路往上改文件……
SwiftUI 的 @Environment 帮不上忙
SwiftUI 有一个内置的 DI 机制，@Environment：
struct CheckoutView: View {
@Environment(.paymentService) var paymentService // 可以！
}
看起来挺好。但问题是 @Environment 只能在 View 的 body 里用，不适用于 ViewModel：
class CheckoutViewModel {
@Environment(.paymentService) var paymentService // 编译报错
}
所以我们需要一个像 @Environment 一样好用，但能在 View 层之外工作的方案。
🏭 Factory：适配 MVVM 的 DI 框架
Factory 是一个轻量级的 DI 框架，刚好解决了这个问题。ViewModel 通过 @Injected 主动从容器中拉取依赖：
final class CheckoutViewModel {
@Injected(.paymentService) private var paymentService
@Injected(.orderRepository) private var orderRepository
func placeOrder() async throws {
let order = try await orderRepository.createOrder()
try await paymentService.charge(amount: order.total)
}
}
不用传 init 参数，也不用维护依赖链。容器负责创建每个服务，@Injected 在运行时自动解析，ViewModel 压根不需要关心依赖从哪来。
Factory 就像个中间人，根据当前环境决定注入什么：
ViewModel 只管说"我要什么"，Factory 负责"给你什么"。
Container：依赖注册中心
Container 是你定义每个依赖创建方式的地方：
extension Container {
var paymentService: Factory<PaymentServiceProtocol> {
self { StripePaymentService() }
}
var orderRepository: Factory<OrderRepositoryProtocol> {
self { OrderRepository() }
}
}
在生产环境中，@Injected(.paymentService) 解析为 StripePaymentService()。在测试中，你可以覆盖它：
Container.shared.paymentService.register { MockPaymentService() }
SharedContainer：按模块组织依赖
一个全局 Container 小项目够用。但在拥有几十个服务的模块化工程里，它很快就变成了大杂烩。Factory 提供了 SharedContainer，让你按模块拆分管理，就像是文件夹一样：
PaymentSharedContainer
├── paymentService
└── paymentGateway
OrderSharedContainer
├── orderRepository
└── orderValidator
AuthSharedContainer
├── authService
└── tokenStorage
每个模块管好自己的容器，边界清晰，各司其职：
public final class PaymentSharedContainer: SharedContainer {
public static var shared = PaymentSharedContainer()
public let manager = ContainerManager()
public var paymentService: Factory<PaymentServiceProtocol> {
self { StripePaymentService() }
}
public var paymentGateway: Factory<PaymentGatewayProtocol> {
self { PaymentGateway() }
}
}
在 ViewModel 中使用：
final class CheckoutViewModel {
@Injected(\PaymentSharedContainer.paymentService)
private var paymentService
}
到这里一切都很美好，直到你开始并行跑测试（尤其是 Swift Testing 默认就是并行模式）。
🐛 核心问题：并行测试与共享可变状态
好，现在终于说到重点了。
一个典型的测试配置
@Suite
struct CheckoutViewModelTests {
let mockPayment: PaymentServiceProtocolSpy
let sut: CheckoutViewModel
init() {
mockPayment = PaymentServiceProtocolSpy()
PaymentSharedContainer.shared.paymentService.register { mockPayment }
sut = CheckoutViewModel()
}
@Test func placeOrder_chargesCorrectAmount() async throws {
try await sut.placeOrder()
#expect(mockPayment.chargeCallCount == 1)
}
}
看着没毛病，单独跑这个测试 Suite 的时候确实也没问题。
并行执行时发生了什么
Swift Testing 默认并发执行测试。这对 CI 速度来说是好事，但这意味着多个测试 Suite 同时执行，且共享同一个 PaymentSharedContainer.shared 实例：
Suite A 注册了 MockA，Suite B 在同一个容器上注册了 MockB。当 Suite A 解析依赖时，它可能拿到的是 MockB，反过来也一样。最终结果完全取决于线程调度顺序，而线程调度本身就是不确定的。换句话说，你的测试结果现在全凭运气。
更糟糕的是：Suite 内部的竞态
即使是同一个 Suite 内部的测试，也可能产生竞态。Swift Testing 并不保证 @Test 方法按顺序执行：
@Suite
struct OrderViewModelTests {
let mockRepo: OrderRepositoryProtocolSpy
let sut: OrderViewModel
init() {
mockRepo = OrderRepositoryProtocolSpy()
OrderSharedContainer.shared.orderRepository.register { mockRepo }
sut = OrderViewModel()
}
@Test func fetchOrders_success() async {
mockRepo.fetchOrdersResult = [Order.sample]
await sut.fetchOrders()
#expect(sut.orders.count == 1)
}
@Test func fetchOrders_empty() async {
mockRepo.fetchOrdersResult = []
await sut.fetchOrders()
#expect(sut.orders.isEmpty)
}
}
两个测试配置的是同一个 mockRepo 实例。并发运行时，一个测试的配置会影响到另一个，本来期望拿到空列表的测试，结果却看到了一条数据，显然这样会影响最终的测试结果。
最终症状
- 测试本地通过但 CI 上失败（不同机器，不同时序）
- 重跑失败的流水线就能通过
- 添加或删除不相关的测试导致其他地方失败
- 稳定运行很长时间的测试突然变得不可靠
根本原因都是一样的：DI 容器中的共享可变状态，导致 Race Condition
🔐 解决方案：使用 @TaskLocal 实现容器隔离
思路很简单：给每个测试分配自己的独立容器副本。不共享，自然就不会有竞态。
理解 @TaskLocal
在讲方案之前，先简单科普一下 @TaskLocal。这是 Swift Concurrency 提供的一个属性，它能让每个 Task 持有自己的 copy，互相之间完全隔离：
enum Scope {
@TaskLocal static var currentUser: String = "default"
}
// Task A 看到 "Alice"
Task {
Scope.$currentUser.withValue("Alice") {
print(Scope.currentUser) // "Alice"
}
}
// Task B 看到 "Bob"，完全独立
Task {
Scope.$currentUser.withValue("Bob") {
print(Scope.currentUser) // "Bob"
}
}
每个 Task 有自己的 currentUser。无需加锁，没有竞态，没有共享状态。
将 @TaskLocal 应用到容器
聪明的你大概已经猜到了，把容器的 shared 属性标记为 @TaskLocal，每个测试任务就能拿到自己的容器了：
public final class PaymentSharedContainer: SharedContainer {
@TaskLocal public static var shared = PaymentSharedContainer()
// ^^^^^^^^^ 就是这行代码
public let manager = ContainerManager()
public var paymentService: Factory<PaymentServiceProtocol> {
self { StripePaymentService() }
}
}
就这么一行代码的事。当测试运行在一个绑定了新容器到 $shared 的 Task 里时，所有 @Injected 解析拿到的都是当前测试专属的容器，而不是全局那个。
Factory 的内置支持：Container Traits
当然，你也可以手动调用 $shared.withValue(...)，但写起来实在太啰嗦了。Factory（通过 FactoryTesting）提供了 Container Traits 来帮你搞定这些样板代码，可以直接嵌入 Swift Testing 的 @Suite 和 @Test 属性。
定义 Container Trait
为每个 SharedContainer 在测试支持模块中定义一个 trait：
import Testing
import FactoryTesting
// 辅助方法：配置测试默认值
private func configurePaymentDefaults(_ container: PaymentSharedContainer) {
container.paymentService.register { PaymentServiceProtocolSpy() }
container.paymentGateway.register { PaymentGatewayProtocolSpy() }
}
// Suite 级别的 trait：隔离整个 Suite
extension SuiteTrait where Self == ContainerTrait<PaymentSharedContainer> {
static var paymentContainer: ContainerTrait<PaymentSharedContainer> {
let container = PaymentSharedContainer()
configurePaymentDefaults(container)
return .init(shared: PaymentSharedContainer.$shared, container: container)
}
}
// Test 级别的 trait：允许单个测试覆盖配置
extension TestTrait where Self == ContainerTrait<PaymentSharedContainer> {
static func paymentContainer(
_ configure: @escaping (PaymentSharedContainer) -> Void
) -> ContainerTrait<PaymentSharedContainer> {
let container = PaymentSharedContainer()
configurePaymentDefaults(container)
configure(container) // 应用测试专属的配置
return .init(shared: PaymentSharedContainer.$shared, container: container)
}
}
在测试中使用 Traits
Suite 级别的隔离。 Suite 中的每个测试都获得自己的容器：
@Suite(.paymentContainer, .orderContainer)
struct CheckoutViewModelTests {
let mockPayment: PaymentServiceProtocolSpy
let sut: CheckoutViewModel
init() {
// 在隔离的容器上注册测试专属的 mock
let spy = PaymentServiceProtocolSpy()
PaymentSharedContainer.shared.paymentService.register { spy }
mockPayment = spy
sut = CheckoutViewModel()
}
@Test func placeOrder_chargesOnce() async throws {
try await sut.placeOrder()
#expect(mockPayment.chargeCallCount == 1)
}
@Test func placeOrder_passesCorrectAmount() async throws {
try await sut.placeOrder()
#expect(mockPayment.lastChargedAmount == 99.99)
}
}
这样两个测试就可以放心地并行跑了，各自都有独立的 PaymentSharedContainer 实例，互不干扰。
Test 级别的覆盖。 还可以针对某个测试单独定制配置：
@Suite(.paymentContainer)
struct DiscountTests {
@Test(
"高级用户享受 20% 折扣",
.paymentContainer { $0.discountRate.register { 0.20 } }
)
func premiumDiscount() async {
let vm = CheckoutViewModel()
let price = vm.calculateFinalPrice(for: 100.0)
#expect(price == 80.0)
}
@Test("普通用户没有折扣")
func noDiscount() async {
let vm = CheckoutViewModel()
let price = vm.calculateFinalPrice(for: 100.0)
#expect(price == 100.0) // 使用 Suite 默认值（无折扣）
}
}
整体运作方式
用上 Container Traits 之后，每个测试都拥有自己的独立容器，彼此之间完全隔离：
不再有共享状态，不再有竞态，单元测试从此稳定！
📋 完整实践清单
我们在每个模块中遵循的模式：
1. 为 SharedContainer 标记 @TaskLocal：
public final class OrderSharedContainer: SharedContainer {
@TaskLocal public static var shared = OrderSharedContainer()
public let manager = ContainerManager()
// ... 依赖定义
}
2. 在测试支持模块中创建 trait 辅助方法：
// OrderMocks/ContainerTraits.swift
private func configureOrderDefaults(_ container: OrderSharedContainer) {
container.orderRepository.register { OrderRepositoryProtocolSpy() }
container.orderValidator.register { OrderValidatorProtocolSpy() }
}
extension SuiteTrait where Self == ContainerTrait<OrderSharedContainer> {
static var orderContainer: ContainerTrait<OrderSharedContainer> {
let container = OrderSharedContainer()
configureOrderDefaults(container)
return .init(shared: OrderSharedContainer.$shared, container: container)
}
}
3. 在测试Suite中应用 traits：
@Suite(.orderContainer, .paymentContainer)
struct OrderFlowTests {
// 每个测试都获得隔离的容器，可安全并行执行
}
🧭 核心要点
- DI 的本质是为了可测试性
-
Factory 填补了 MVVM + DI 的空白，解决了 SwiftUI
@Environment无法覆盖的场景 - 并行测试 + 共享容器（Shared Container） = 竞态条件（Race Condition）
-
@TaskLocal容器隔离从根本上解决了问题，为每个测试提供独立的容器实例 - Container Traits 让方案切实可行， 每个模块定义一次，在每个测试Suite中声明式地应用
