CI / test (push) Failing after 12s

Details

refactor(exploration): absorb settlement.py into ExplorationSessionRepository

将 settlement.py 的 settle_campaign_sessions 函数吸收为
ExplorationSessionRepository.expire_running_sessions 方法。删除浅模块
settlement.py（30 行，接口宽如实现），会话生命周期操作集中在 repository。

- 新增 ExplorationSessionRepository.expire_running_sessions(campaign_id)
- 更新 campaigns.py 和 campaign_runner.py 两个调用点
- 删除 backend/agenteval/exploration/settlement.py
- 所有测试通过，行为不变

2026-08-04 13:28:23 +08:00

1.4 KiB

Raw Blame History

When to Mock

Mock at system boundaries only:

External APIs (payment, email, etc.)
Databases (sometimes - prefer test DB)
Time/randomness
File system (sometimes)

Don't mock:

Your own classes/modules
Internal collaborators
Anything you control

Designing for Mockability

At system boundaries, design interfaces that are easy to mock:

1. Use dependency injection

Pass external dependencies in rather than creating them internally:

// Easy to mock
function processPayment(order, paymentClient) {
  return paymentClient.charge(order.total);
}

// Hard to mock
function processPayment(order) {
  const client = new StripeClient(process.env.STRIPE_KEY);
  return client.charge(order.total);
}

2. Prefer SDK-style interfaces over generic fetchers

Create specific functions for each external operation instead of one generic function with conditional logic:

// GOOD: Each function is independently mockable
const api = {
  getUser: (id) => fetch(`/users/${id}`),
  getOrders: (userId) => fetch(`/users/${userId}/orders`),
  createOrder: (data) => fetch('/orders', { method: 'POST', body: data }),
};

// BAD: Mocking requires conditional logic inside the mock
const api = {
  fetch: (endpoint, options) => fetch(endpoint, options),
};

The SDK approach means:

Each mock returns one specific shape
No conditional logic in test setup
Easier to see which endpoints a test exercises
Type safety per endpoint

1.4 KiB Raw Blame History

When to Mock

Designing for Mockability

1.4 KiB

Raw Blame History