how-i-made-your-machine

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

How I Made Your Machine

How I Made Your Machine

This is the style guide: the story of how I made your machine.
这是一份编码风格指南:讲述我是如何打造你的机器的。

Agent Usage

Agent 使用说明

  1. Read this guide before implementing, refactoring, or reviewing code.
  2. Treat these rules as defaults unless the user requests a different tradeoff.
  3. Model finite values and mutually exclusive states with explicit variants/enums/unions.
  4. Prefer domain-specific types and function signatures over generic primitives.
  5. Preserve behavior-first testing: test business outcomes, not framework internals or third-party behavior.
  6. Call out justified exceptions explicitly when constraints force weaker typing or non-ideal structure.
  7. Keep unrelated code unchanged; apply the guide to the task scope instead of broad rewrites.
  1. 在进行代码实现、重构或评审前,请阅读本指南。
  2. 除非用户要求做出其他权衡,否则请将这些规则作为默认准则。
  3. 用显式变体/enum/union来建模有限值和互斥状态。
  4. 优先使用领域特定类型和函数签名,而非通用原生类型。
  5. 坚持行为优先的测试原则:测试业务结果,而非框架内部逻辑或第三方行为。
  6. 当约束条件导致必须弱化类型或采用非理想结构时,请明确说明合理的例外情况。
  7. 保持无关代码不变;仅在任务范围内应用本指南,避免大范围重写。

Agent Workflow

Agent 工作流程

  1. Identify which sections below apply to the current task.
  2. Implement or refactor using the relevant patterns.
  3. Review the result against the Core Principles and Type Design Signals.
  4. Explain key changes in terms of maintainability, type safety, and behavior correctness.
  1. 确定以下哪些章节适用于当前任务。
  2. 使用相关模式进行实现或重构。
  3. 根据核心原则和类型设计信号审查结果。
  4. 从可维护性、类型安全性和行为正确性的角度解释关键变更。

Purpose

目的

This guide lays out how we should write code for maintainability, type safety, and behavior-first testing across projects. It sets strong defaults, with room for justified exceptions when the tradeoff is clear.
本指南阐述了我们如何在跨项目中编写具备可维护性、类型安全性且遵循行为优先测试原则的代码。它设定了明确的默认准则,同时在权衡取舍清晰时,允许合理的例外情况。

Core Principles

核心原则

  • Make invalid states hard to represent.
  • Model domain concepts explicitly instead of using ad-hoc primitives.
  • Use the type system and compiler as first-line quality gates.
  • Optimize for readable intent over clever implementation.
  • Test business behavior rather than framework or library internals.
  • 让无效状态难以被表示。
  • 显式建模领域概念,而非使用临时原生类型。
  • 将类型系统和编译器作为第一道质量关卡。
  • 优先优化代码的可读性与意图表达,而非追求巧妙的实现方式。
  • 测试业务行为,而非框架或库的内部逻辑。

Type Safety and Relying on the Compiler

类型安全性与编译器依赖

Using a type-safe language is not enough on its own. We have to be intentional about how we model data and behavior so the compiler and static analysis can do real work for us. It is easy to write code that technically type-checks while still side-stepping most of those guarantees.
Here are some patterns that are useful to follow:
  • Prefer domain types over raw strings and loosely typed containers.
  • Use unions/enums/typed variants when valid values are finite.
  • Favor exhaustive pattern matching where possible.
  • Represent unknown external values explicitly (
    Unknown*
    ) instead of falling back silently.
  • Avoid weakening types (
    any
    , broad casts, untyped flows) unless unavoidable.
仅使用类型安全的语言是不够的。我们必须有意识地对数据和行为进行建模,这样编译器和静态分析才能真正为我们发挥作用。很容易写出在技术上通过类型检查,但却规避了大部分类型安全保障的代码。
以下是一些值得遵循的模式:
  • 优先使用领域类型,而非原始字符串和松散类型的容器。
  • 当有效值为有限集合时,使用union/enum/类型变体。
  • 尽可能采用穷举模式匹配。
  • 显式表示未知的外部值(
    Unknown*
    ),而非默默回退。
  • 除非万不得已,否则避免弱化类型(
    any
    、宽泛类型转换、无类型流程)。

Type Design Signals

类型设计信号

  • If the value set is finite, use a union/enum instead of
    string
    .
  • If states are mutually exclusive, use one state union/enum instead of multiple booleans.
  • If function inputs represent domain concepts, use those domain types directly.
  • 如果值集合是有限的,使用union/enum而非
    string
  • 如果状态是互斥的,使用单个状态union/enum而非多个布尔值。
  • 如果函数输入代表领域概念,直接使用这些领域类型。

Example 1: Finite Value Set as Variants

示例1:用变体表示有限值集合

<Tabs groupId="finite-values"> <TabItem value="pseudocode" label="Pseudocode" default>
text
Under-modeled:
  status: string

Better modeled:
  Status = "draft" | "published" | "archived"
  status: Status
</TabItem> <TabItem value="typescript" label="TypeScript">
ts
// Bad: unconstrained string allows invalid values.
const underModeledStatus: string = "draff";

// Good: finite union prevents invalid states.
type Status = "draft" | "published" | "archived";
const modeledStatus: Status = "draft";
</TabItem> <TabItem value="rust" label="Rust">
rust
// Bad: free-form string can carry invalid values.
let under_modeled_status = "draff";

// Good: enum constrains the value set.
enum Status {
    Draft,
    Published,
    Archived,
}

let modeled_status = Status::Draft;
let _ = (under_modeled_status, modeled_status);
</TabItem> <TabItem value="python" label="Python">
python
undefined
<Tabs groupId="finite-values"> <TabItem value="pseudocode" label="伪代码" default>
text
建模不足:
  status: string

优化建模:
  Status = "draft" | "published" | "archived"
  status: Status
</TabItem> <TabItem value="typescript" label="TypeScript">
ts
// Bad: 无约束字符串允许无效值。
const underModeledStatus: string = "draff";

// Good: 有限union防止无效状态。
type Status = "draft" | "published" | "archived";
const modeledStatus: Status = "draft";
</TabItem> <TabItem value="rust" label="Rust">
rust
// Bad: 自由格式字符串可能包含无效值。
let under_modeled_status = "draff";

// Good: enum约束值集合。
enum Status {
    Draft,
    Published,
    Archived,
}

let modeled_status = Status::Draft;
let _ = (under_modeled_status, modeled_status);
</TabItem> <TabItem value="python" label="Python">
python
undefined

Bad: unconstrained string allows invalid values.

Bad: 无约束字符串允许无效值。

under_modeled_status: str = "draff"
under_modeled_status: str = "draff"

Good: StrEnum constrains valid values.

Good: StrEnum约束有效值。

from enum import StrEnum
class Status(StrEnum): DRAFT = "draft" PUBLISHED = "published" ARCHIVED = "archived"
modeled_status: Status = Status.DRAFT

  </TabItem>
</Tabs>
from enum import StrEnum
class Status(StrEnum): DRAFT = "draft" PUBLISHED = "published" ARCHIVED = "archived"
modeled_status: Status = Status.DRAFT

  </TabItem>
</Tabs>

Example 2: Boolean Combinations to State Variants

示例2:将布尔组合转换为状态变体

<Tabs groupId="boolean-state"> <TabItem value="pseudocode" label="Pseudocode" default>
text
Under-modeled:
  is_draft: boolean
  is_published: boolean
  is_archived: boolean

Better modeled:
  ContentState = "draft" | "published" | "archived"
  content_state: ContentState
</TabItem> <TabItem value="typescript" label="TypeScript">
ts
// Bad: boolean combinations allow impossible states.
const isDraft = true;
const isPublished = true;
const isArchived = false;

// Good: one variant encodes one valid state.
type ContentState = "draft" | "published" | "archived";
const contentState: ContentState = "published";
void [isDraft, isPublished, isArchived];
</TabItem> <TabItem value="rust" label="Rust">
rust
// Bad: booleans can contradict each other.
struct UnderModeledContentState {
    is_draft: bool,
    is_published: bool,
    is_archived: bool,
}

// Good: enum enforces one state at a time.
enum ContentState {
    Draft,
    Published,
    Archived,
}

let under_modeled_content_state = UnderModeledContentState {
    is_draft: true,
    is_published: true,
    is_archived: false,
};
let modeled_content_state = ContentState::Published;
let _ = (
    under_modeled_content_state.is_draft,
    under_modeled_content_state.is_published,
    under_modeled_content_state.is_archived,
    modeled_content_state,
);
</TabItem> <TabItem value="python" label="Python">
python
undefined
<Tabs groupId="boolean-state"> <TabItem value="pseudocode" label="伪代码" default>
text
建模不足:
  is_draft: boolean
  is_published: boolean
  is_archived: boolean

优化建模:
  ContentState = "draft" | "published" | "archived"
  content_state: ContentState
</TabItem> <TabItem value="typescript" label="TypeScript">
ts
// Bad: 布尔组合可能产生不可能的状态。
const isDraft = true;
const isPublished = true;
const isArchived = false;

// Good: 单个变体表示一种有效状态。
type ContentState = "draft" | "published" | "archived";
const contentState: ContentState = "published";
void [isDraft, isPublished, isArchived];
</TabItem> <TabItem value="rust" label="Rust">
rust
// Bad: 布尔值可能相互矛盾。
struct UnderModeledContentState {
    is_draft: bool,
    is_published: bool,
    is_archived: bool,
}

// Good: enum确保同一时间只有一种状态。
enum ContentState {
    Draft,
    Published,
    Archived,
}

let under_modeled_content_state = UnderModeledContentState {
    is_draft: true,
    is_published: true,
    is_archived: false,
};
let modeled_content_state = ContentState::Published;
let _ = (
    under_modeled_content_state.is_draft,
    under_modeled_content_state.is_published,
    under_modeled_content_state.is_archived,
    modeled_content_state,
);
</TabItem> <TabItem value="python" label="Python">
python
undefined

Bad: booleans can represent impossible combinations.

Bad: 布尔值可能表示不可能的组合。

is_draft = True is_published = True is_archived = False
is_draft = True is_published = True is_archived = False

Good: Literal constrains to one valid state.

Good: Literal约束为单一有效状态。

from typing import Literal
ContentState = Literal["draft", "published", "archived"]
content_state: ContentState = "published" _ = (is_draft, is_published, is_archived, content_state)

  </TabItem>
</Tabs>
from typing import Literal
ContentState = Literal["draft", "published", "archived"]
content_state: ContentState = "published" _ = (is_draft, is_published, is_archived, content_state)

  </TabItem>
</Tabs>

Example 3: Functions Consume Domain Types

示例3:函数使用领域类型作为输入

<Tabs groupId="function-inputs"> <TabItem value="pseudocode" label="Pseudocode" default>
text
Under-modeled:
  schedule_message(channel: string, is_immediate: boolean, is_scheduled: boolean)

Better modeled:
  Channel = "email" | "sms" | "push"
  DeliveryMode = "immediate" | "scheduled"
  schedule_message(channel: Channel, delivery_mode: DeliveryMode)
</TabItem> <TabItem value="typescript" label="TypeScript">
ts
// Bad: primitives hide domain intent and allow contradictions.
function scheduleMessageUnderModeled(
  channel: string,
  isImmediate: boolean,
  isScheduled: boolean,
): void {
  void [channel, isImmediate, isScheduled];
}

// Good: explicit domain types make valid states clear.
type Channel = "email" | "sms" | "push";
type DeliveryMode = "immediate" | "scheduled";

function scheduleMessage(channel: Channel, deliveryMode: DeliveryMode): void {
  void [channel, deliveryMode];
}
</TabItem> <TabItem value="rust" label="Rust">
rust
// Bad: primitives allow invalid channels and conflicting mode flags.
fn schedule_message_under_modeled(channel: &str, is_immediate: bool, is_scheduled: bool) {
    let _ = (channel, is_immediate, is_scheduled);
}

// Good: domain enums constrain function inputs.
enum Channel {
    Email,
    Sms,
    Push,
}

enum DeliveryMode {
    Immediate,
    Scheduled,
}

fn schedule_message(channel: Channel, delivery_mode: DeliveryMode) {
    let _ = (channel, delivery_mode);
}
</TabItem> <TabItem value="python" label="Python">
python
undefined
<Tabs groupId="function-inputs"> <TabItem value="pseudocode" label="伪代码" default>
text
建模不足:
  schedule_message(channel: string, is_immediate: boolean, is_scheduled: boolean)

优化建模:
  Channel = "email" | "sms" | "push"
  DeliveryMode = "immediate" | "scheduled"
  schedule_message(channel: Channel, delivery_mode: DeliveryMode)
</TabItem> <TabItem value="typescript" label="TypeScript">
ts
// Bad: 原生类型隐藏领域意图,且允许矛盾输入。
function scheduleMessageUnderModeled(
  channel: string,
  isImmediate: boolean,
  isScheduled: boolean,
): void {
  void [channel, isImmediate, isScheduled];
}

// Good: 显式领域类型明确有效状态。
type Channel = "email" | "sms" | "push";
type DeliveryMode = "immediate" | "scheduled";

function scheduleMessage(channel: Channel, deliveryMode: DeliveryMode): void {
  void [channel, deliveryMode];
}
</TabItem> <TabItem value="rust" label="Rust">
rust
// Bad: 原生类型允许无效渠道和冲突模式标记。
fn schedule_message_under_modeled(channel: &str, is_immediate: bool, is_scheduled: bool) {
    let _ = (channel, is_immediate, is_scheduled);
}

// Good: 领域enum约束函数输入。
enum Channel {
    Email,
    Sms,
    Push,
}

enum DeliveryMode {
    Immediate,
    Scheduled,
}

fn schedule_message(channel: Channel, delivery_mode: DeliveryMode) {
    let _ = (channel, delivery_mode);
}
</TabItem> <TabItem value="python" label="Python">
python
undefined

Bad: primitive inputs accept invalid values and contradictory flags.

Bad: 原生输入接受无效值和矛盾标记。

def schedule_message_under_modeled( channel: str, is_immediate: bool, is_scheduled: bool, ) -> None: _ = (channel, is_immediate, is_scheduled)
def schedule_message_under_modeled( channel: str, is_immediate: bool, is_scheduled: bool, ) -> None: _ = (channel, is_immediate, is_scheduled)

Good: domain literals constrain allowed values.

Good: 领域字面量约束允许的值。

from typing import Literal
Channel = Literal["email", "sms", "push"] DeliveryMode = Literal["immediate", "scheduled"]
def schedule_message(channel: Channel, delivery_mode: DeliveryMode) -> None: _ = (channel, delivery_mode)

  </TabItem>
</Tabs>
from typing import Literal
Channel = Literal["email", "sms", "push"] DeliveryMode = Literal["immediate", "scheduled"]
def schedule_message(channel: Channel, delivery_mode: DeliveryMode) -> None: _ = (channel, delivery_mode)

  </TabItem>
</Tabs>

Self-Documenting Code

自文档化代码

Self-documenting code is usually better than writing comments everywhere. Comments go stale quickly, while clear naming and structure have to evolve with the program.
  • Prefer descriptive, domain-aligned names even when verbose.
  • Keep function and type names intention-revealing.
  • Add comments only for non-obvious decisions, invariants, or tradeoffs.
  • Avoid comments that restate what code already makes obvious.
自文档化代码通常比到处写注释更好。注释会很快过时,而清晰的命名和结构必须随程序一起演进。
  • 即使冗长,也优先选择描述性的、与领域对齐的命名。
  • 函数和类型名称应能揭示其意图。
  • 仅为非显而易见的决策、不变量或权衡添加注释。
  • 避免注释代码中已经明确体现的内容。

Example 4: Document the Why, Not the Obvious What

示例4:注释解释原因,而非显而易见的内容

<Tabs groupId="documenting-why"> <TabItem value="pseudocode" label="Pseudocode" default>
text
Low-value comment:
  // Increment retry count
  retry_count = retry_count + 1

High-value comment:
  // Billing provider closes refunds at next-day midnight, so keep a one-day grace period.
  refund_grace_period_days = 1
  is_refund_eligible = days_since_purchase <= refund_window_days + refund_grace_period_days
</TabItem> <TabItem value="typescript" label="TypeScript">
ts
// Bad: restates obvious code behavior without context.
function incrementRetryCount(retryCount: number): number {
  // Increment retry count.
  return retryCount + 1;
}

// Good: documents a non-obvious business constraint.
function isRefundEligible(
  daysSincePurchase: number,
  refundWindowDays: number,
): boolean {
  // Billing provider closes refunds at next-day midnight, so we keep a one-day grace period.
  const refundGracePeriodInDays = 1;
  return daysSincePurchase <= refundWindowDays + refundGracePeriodInDays;
}
</TabItem> <TabItem value="rust" label="Rust">
rust
// Bad: restates obvious behavior.
fn increment_retry_count(retry_count: u32) -> u32 {
    // Increment retry count.
    retry_count + 1
}

// Good: documents a non-obvious business constraint.
fn is_refund_eligible(days_since_purchase: u32, refund_window_days: u32) -> bool {
    // Billing provider closes refunds at next-day midnight, so we keep a one-day grace period.
    let refund_grace_period_in_days = 1;
    days_since_purchase <= refund_window_days + refund_grace_period_in_days
}

let _ = increment_retry_count(0);
</TabItem> <TabItem value="python" label="Python">
python
undefined
<Tabs groupId="documenting-why"> <TabItem value="pseudocode" label="伪代码" default>
text
低价值注释:
  // 增加重试次数
  retry_count = retry_count + 1

高价值注释:
  // 支付提供商在次日午夜关闭退款通道,因此保留1天的宽限期。
  refund_grace_period_days = 1
  is_refund_eligible = days_since_purchase <= refund_window_days + refund_grace_period_days
</TabItem> <TabItem value="typescript" label="TypeScript">
ts
// Bad: 重复代码的明显行为,未提供上下文。
function incrementRetryCount(retryCount: number): number {
  // 增加重试次数。
  return retryCount + 1;
}

// Good: 注释说明非显而易见的业务约束。
function isRefundEligible(
  daysSincePurchase: number,
  refundWindowDays: number,
): boolean {
  // 支付提供商在次日午夜关闭退款通道,因此我们保留1天的宽限期。
  const refundGracePeriodInDays = 1;
  return daysSincePurchase <= refundWindowDays + refundGracePeriodInDays;
}
</TabItem> <TabItem value="rust" label="Rust">
rust
// Bad: 重复明显的行为。
fn increment_retry_count(retry_count: u32) -> u32 {
    // 增加重试次数。
    retry_count + 1
}

// Good: 注释说明非显而易见的业务约束。
fn is_refund_eligible(days_since_purchase: u32, refund_window_days: u32) -> bool {
    // 支付提供商在次日午夜关闭退款通道,因此我们保留1天的宽限期。
    let refund_grace_period_in_days = 1;
    days_since_purchase <= refund_window_days + refund_grace_period_in_days
}

let _ = increment_retry_count(0);
</TabItem> <TabItem value="python" label="Python">
python
undefined

Bad: restates obvious behavior.

Bad: 重复明显的行为。

def increment_retry_count(retry_count: int) -> int: # Increment retry count. return retry_count + 1
def increment_retry_count(retry_count: int) -> int: # 增加重试次数。 return retry_count + 1

Good: documents a non-obvious business constraint.

Good: 注释说明非显而易见的业务约束。

def is_refund_eligible(days_since_purchase: int, refund_window_days: int) -> bool: # Billing provider closes refunds at next-day midnight, so we keep a one-day grace period. refund_grace_period_in_days = 1 return days_since_purchase <= refund_window_days + refund_grace_period_in_days
_ = increment_retry_count(0)

  </TabItem>
</Tabs>
def is_refund_eligible(days_since_purchase: int, refund_window_days: int) -> bool: # 支付提供商在次日午夜关闭退款通道,因此我们保留1天的宽限期。 refund_grace_period_in_days = 1 return days_since_purchase <= refund_window_days + refund_grace_period_in_days
_ = increment_retry_count(0)

  </TabItem>
</Tabs>

Testing Business Logic First

优先测试业务逻辑

Tests are important for verifying behavior and preventing regression at both unit and integration levels. But we should avoid writing tests for the sake of writing tests: they add maintenance cost and create noise when they assert outcomes that do not matter to business behavior.
  • Test business outcomes and domain behavior first.
  • Prioritize tests for state transitions, input-to-output rules, defaults, and fallback behavior.
  • Do not test third-party/library internals.
  • Avoid mocks by default.
  • Use mocks only for unstable boundaries (network, filesystem, time, OS/process boundaries).
  • Assert externally meaningful behavior, not private implementation details.
测试对于在单元和集成层面验证行为、防止回归至关重要。但我们不应为了测试而测试:无意义的测试会增加维护成本,且在断言与业务行为无关的结果时会产生干扰。
  • 优先测试业务结果和领域行为。
  • 优先测试状态转换、输入输出规则、默认值和回退行为。
  • 不要测试第三方/库的内部逻辑。
  • 默认避免使用mock。
  • 仅在不稳定的边界(网络、文件系统、时间、操作系统/进程边界)使用mock。
  • 断言外部可感知的行为,而非私有实现细节。

Example 5: Test State Transitions and Outcomes

示例5:测试状态转换与结果

<Tabs groupId="testing-behavior"> <TabItem value="pseudocode" label="Pseudocode" default>
text
Brittle:
  assert transition_helper_called_once()

Behavior-focused:
  result = transition_order_state("draft", "publish")
  assert result == "published"
</TabItem> <TabItem value="typescript" label="TypeScript">
ts
import { describe, expect, it } from "vitest";

describe("transitionOrderStateUnderTest", () => {
  it("bad: asserts an implementation detail", () => {
    const transitionHelperCallCount = 1;
    expect(transitionHelperCallCount).toBe(1);
  });
});

describe("transitionOrderState", () => {
  it("good: asserts observable state transition", () => {
    const nextState = transitionOrderState("draft", "publish");
    expect(nextState).toBe("published");
  });
});
</TabItem> <TabItem value="rust" label="Rust">
rust
#[test]
fn bad_asserts_implementation_detail_only() {
    let transition_helper_call_count = 1;
    assert_eq!(transition_helper_call_count, 1);
}

#[test]
fn good_transitions_draft_to_published_when_publish_is_requested() {
    let next_state = transition_order_state("draft", "publish");
    assert_eq!(next_state, "published");
}
</TabItem> <TabItem value="python" label="Python">
python
def test_bad_asserts_implementation_detail_only() -> None:
    transition_helper_call_count = 1
    assert transition_helper_call_count == 1

def test_good_transition_order_state_moves_draft_to_published() -> None:
    next_state = transition_order_state("draft", "publish")
    assert next_state == "published"
</TabItem> </Tabs>
<Tabs groupId="testing-behavior"> <TabItem value="pseudocode" label="伪代码" default>
text
脆弱的测试:
  assert transition_helper_called_once()

聚焦行为的测试:
  result = transition_order_state("draft", "publish")
  assert result == "published"
</TabItem> <TabItem value="typescript" label="TypeScript">
ts
import { describe, expect, it } from "vitest";

describe("transitionOrderStateUnderTest", () => {
  it("bad: 断言实现细节", () => {
    const transitionHelperCallCount = 1;
    expect(transitionHelperCallCount).toBe(1);
  });
});

describe("transitionOrderState", () => {
  it("good: 断言可观察的状态转换", () => {
    const nextState = transitionOrderState("draft", "publish");
    expect(nextState).toBe("published");
  });
});
</TabItem> <TabItem value="rust" label="Rust">
rust
#[test]
fn bad_asserts_implementation_detail_only() {
    let transition_helper_call_count = 1;
    assert_eq!(transition_helper_call_count, 1);
}

#[test]
fn good_transitions_draft_to_published_when_publish_is_requested() {
    let next_state = transition_order_state("draft", "publish");
    assert_eq!(next_state, "published");
}
</TabItem> <TabItem value="python" label="Python">
python
def test_bad_asserts_implementation_detail_only() -> None:
    transition_helper_call_count = 1
    assert transition_helper_call_count == 1

def test_good_transition_order_state_moves_draft_to_published() -> None:
    next_state = transition_order_state("draft", "publish")
    assert next_state == "published"
</TabItem> </Tabs>

Example 6: Mock Only Unstable Boundaries

示例6:仅在不稳定边界使用Mock

<Tabs groupId="testing-mocks"> <TabItem value="pseudocode" label="Pseudocode" default>
text
Preferred:
  fake_clock = FixedClock("2025-01-01T00:00:00Z")
  assert discount_is_active(fake_clock)

Avoid:
  assert internal_helper_called("calculate_discount_window")
</TabItem> <TabItem value="typescript" label="TypeScript">
ts
import { expect, it, vi } from "vitest";

it("bad: mocks an internal helper and asserts internals", () => {
  const calculateDiscountWindow = vi.fn().mockReturnValue(true);
  calculateDiscountWindow();
  expect(calculateDiscountWindow).toHaveBeenCalledTimes(1);
});

it("good: mocks only unstable network boundary and asserts behavior", async () => {
  const fetchExchangeRate = vi.fn().mockRejectedValue(new Error("timeout"));
  const gateway = createCurrencyGateway({ fetchExchangeRate });

  const rate = await gateway.getRateOrFallback("USD", "EUR");

  expect(rate).toBe(0.92);
});
</TabItem> <TabItem value="rust" label="Rust">
rust
#[test]
fn bad_asserts_internal_helper_behavior() {
    let internal_helper_call_count = 1;
    assert_eq!(internal_helper_call_count, 1);
}

#[test]
fn good_uses_cached_rate_when_live_lookup_fails() {
    let gateway = CurrencyGateway::new(FailingRateClient, CachedRateStore::with_rate(0.92));
    let rate = gateway.get_rate_or_fallback("USD", "EUR");
    assert_eq!(rate, 0.92);
}
</TabItem> <TabItem value="python" label="Python">
python
def test_bad_asserts_internal_helper_behavior() -> None:
    internal_helper_call_count = 1
    assert internal_helper_call_count == 1

def test_good_uses_cached_rate_when_live_lookup_fails() -> None:
    gateway = CurrencyGateway(
        rate_client=FailingRateClient(),
        cache_store=CachedRateStore(rate=0.92),
    )

    rate = gateway.get_rate_or_fallback("USD", "EUR")

    assert rate == 0.92
</TabItem> </Tabs>
<Tabs groupId="testing-mocks"> <TabItem value="pseudocode" label="伪代码" default>
text
推荐做法:
  fake_clock = FixedClock("2025-01-01T00:00:00Z")
  assert discount_is_active(fake_clock)

避免做法:
  assert internal_helper_called("calculate_discount_window")
</TabItem> <TabItem value="typescript" label="TypeScript">
ts
import { expect, it, vi } from "vitest";

it("bad: Mock内部辅助函数并断言实现细节", () => {
  const calculateDiscountWindow = vi.fn().mockReturnValue(true);
  calculateDiscountWindow();
  expect(calculateDiscountWindow).toHaveBeenCalledTimes(1);
});

it("good: 仅Mock不稳定的网络边界并断言行为", async () => {
  const fetchExchangeRate = vi.fn().mockRejectedValue(new Error("timeout"));
  const gateway = createCurrencyGateway({ fetchExchangeRate });

  const rate = await gateway.getRateOrFallback("USD", "EUR");

  expect(rate).toBe(0.92);
});
</TabItem> <TabItem value="rust" label="Rust">
rust
#[test]
fn bad_asserts_internal_helper_behavior() {
    let internal_helper_call_count = 1;
    assert_eq!(internal_helper_call_count, 1);
}

#[test]
fn good_uses_cached_rate_when_live_lookup_fails() {
    let gateway = CurrencyGateway::new(FailingRateClient, CachedRateStore::with_rate(0.92));
    let rate = gateway.get_rate_or_fallback("USD", "EUR");
    assert_eq!(rate, 0.92);
}
</TabItem> <TabItem value="python" label="Python">
python
def test_bad_asserts_internal_helper_behavior() -> None:
    internal_helper_call_count = 1
    assert internal_helper_call_count == 1

def test_good_uses_cached_rate_when_live_lookup_fails() -> None:
    gateway = CurrencyGateway(
        rate_client=FailingRateClient(),
        cache_store=CachedRateStore(rate=0.92),
    )

    rate = gateway.get_rate_or_fallback("USD", "EUR")

    assert rate == 0.92
</TabItem> </Tabs>

Exceptions

例外情况

We can make exceptions when strict modeling creates disproportionate complexity, external contracts require looser typing, or performance/interoperability constraints apply.
When we take an exception, we should document:
  • Which rule is being bent
  • Why
  • Which safeguards are in place (validation, logging, tests)
当严格建模会导致复杂度大幅增加、外部契约要求更宽松的类型,或是存在性能/互操作性约束时,我们可以做出例外。
当做出例外时,我们应该记录:
  • 违反了哪条规则
  • 原因
  • 采取了哪些保障措施(验证、日志、测试)

Example 7: External Contract Requires Looser Typing

示例7:外部契约要求更宽松的类型

<Tabs groupId="exceptions"> <TabItem value="pseudocode" label="Pseudocode" default>
text
Rule being bent:
  "Finite value set -> union/enum instead of string"

Why:
  Partner webhook sends undocumented status values.

Safeguards:
  validate known values
  map unknown values to UnknownPartnerStatus
  log raw unknown values
  test known and unknown inputs
</TabItem> <TabItem value="typescript" label="TypeScript">
ts
// Bad: assumes external input already matches strict known values.
type UnderModeledPartnerStatus = "accepted" | "rejected";

function parsePartnerStatus(rawPartnerStatus: UnderModeledPartnerStatus): UnderModeledPartnerStatus {
  return rawPartnerStatus;
}

// Good: accept string input, validate known values, and map unknown values explicitly.
type KnownPartnerStatus = "accepted" | "rejected";
type PartnerStatus = KnownPartnerStatus | "unknown_partner_status";

function mapPartnerStatus(rawPartnerStatus: string): PartnerStatus {
  if (rawPartnerStatus === "accepted" || rawPartnerStatus === "rejected") {
    return rawPartnerStatus;
  }

  console.warn("unknown partner status", { rawPartnerStatus });
  return "unknown_partner_status";
}
</TabItem> <TabItem value="rust" label="Rust">
rust
// Bad: panics on unexpected partner status values.
enum UnderModeledPartnerStatus {
    Accepted,
    Rejected,
}

fn parse_partner_status(raw_partner_status: &str) -> UnderModeledPartnerStatus {
    match raw_partner_status {
        "accepted" => UnderModeledPartnerStatus::Accepted,
        "rejected" => UnderModeledPartnerStatus::Rejected,
        _ => panic!("unsupported partner status: {raw_partner_status}"),
    }
}

// Good: capture unknown values explicitly and continue safely.
enum PartnerStatus {
    Accepted,
    Rejected,
    UnknownPartnerStatus,
}

fn map_partner_status(raw_partner_status: &str) -> PartnerStatus {
    match raw_partner_status {
        "accepted" => PartnerStatus::Accepted,
        "rejected" => PartnerStatus::Rejected,
        _ => {
            eprintln!("unknown partner status: {raw_partner_status}");
            PartnerStatus::UnknownPartnerStatus
        }
    }
}

let _ = parse_partner_status("accepted");
</TabItem> <TabItem value="python" label="Python">
python
from typing import Literal
<Tabs groupId="exceptions"> <TabItem value="pseudocode" label="伪代码" default>
text
违反的规则:
  "有限值集合 -> 使用union/enum而非string"

原因:
  合作伙伴的Webhook发送未记录的状态值。

保障措施:
  验证已知值
  将未知值映射为UnknownPartnerStatus
  记录原始未知值
  测试已知和未知输入
</TabItem> <TabItem value="typescript" label="TypeScript">
ts
// Bad: 假设外部输入已符合严格的已知值。
type UnderModeledPartnerStatus = "accepted" | "rejected";

function parsePartnerStatus(rawPartnerStatus: UnderModeledPartnerStatus): UnderModeledPartnerStatus {
  return rawPartnerStatus;
}

// Good: 接受string输入,验证已知值,并显式映射未知值。
type KnownPartnerStatus = "accepted" | "rejected";
type PartnerStatus = KnownPartnerStatus | "unknown_partner_status";

function mapPartnerStatus(rawPartnerStatus: string): PartnerStatus {
  if (rawPartnerStatus === "accepted" || rawPartnerStatus === "rejected") {
    return rawPartnerStatus;
  }

  console.warn("unknown partner status", { rawPartnerStatus });
  return "unknown_partner_status";
}
</TabItem> <TabItem value="rust" label="Rust">
rust
// Bad: 遇到意外的合作伙伴状态值时会panic。
enum UnderModeledPartnerStatus {
    Accepted,
    Rejected,
}

fn parse_partner_status(raw_partner_status: &str) -> UnderModeledPartnerStatus {
    match raw_partner_status {
        "accepted" => UnderModeledPartnerStatus::Accepted,
        "rejected" => UnderModeledPartnerStatus::Rejected,
        _ => panic!("unsupported partner status: {raw_partner_status}"),
    }
}

// Good: 显式捕获未知值并安全继续。
enum PartnerStatus {
    Accepted,
    Rejected,
    UnknownPartnerStatus,
}

fn map_partner_status(raw_partner_status: &str) -> PartnerStatus {
    match raw_partner_status {
        "accepted" => PartnerStatus::Accepted,
        "rejected" => PartnerStatus::Rejected,
        _ => {
            eprintln!("unknown partner status: {raw_partner_status}");
            PartnerStatus::UnknownPartnerStatus
        }
    }
}

let _ = parse_partner_status("accepted");
</TabItem> <TabItem value="python" label="Python">
python
from typing import Literal

Bad: assumes the partner only ever sends known values.

Bad: 假设合作伙伴只发送已知值。

UnderModeledPartnerStatus = Literal["accepted", "rejected"]
def parse_partner_status(raw_partner_status: UnderModeledPartnerStatus) -> UnderModeledPartnerStatus: return raw_partner_status
UnderModeledPartnerStatus = Literal["accepted", "rejected"]
def parse_partner_status(raw_partner_status: UnderModeledPartnerStatus) -> UnderModeledPartnerStatus: return raw_partner_status

Good: accept raw string input and map unknown values explicitly.

Good: 接受原始string输入并显式映射未知值。

PartnerStatus = Literal["accepted", "rejected", "unknown_partner_status"]
def map_partner_status(raw_partner_status: str) -> PartnerStatus: if raw_partner_status in {"accepted", "rejected"}: return raw_partner_status
print(f"unknown partner status: {raw_partner_status}")
return "unknown_partner_status"

  </TabItem>
</Tabs>
PartnerStatus = Literal["accepted", "rejected", "unknown_partner_status"]
def map_partner_status(raw_partner_status: str) -> PartnerStatus: if raw_partner_status in {"accepted", "rejected"}: return raw_partner_status
print(f"unknown partner status: {raw_partner_status}")
return "unknown_partner_status"

  </TabItem>
</Tabs>