31d - AI辅助PBT

┌──────────────┐     ┌──────────────┐     ┌──────────────┐
│  定义属性     │     │  设计生成器   │     │  运行测试     │
│  (Property)  │────▶│  (Generator) │────▶│  (Execute)    │
└──────────────┘     └──────────────┘     └──────────────┘
       ▲                                        │
       │                                 通过？  │  失败？
       │                                 ┌──────┴──────┐
       │                                 ▼             ▼
       │                            增加样本数     ┌──────────┐
       │                            继续测试      │  收缩     │
       │                                          │ (Shrink)  │
       │                                          └────┬─────┘
       │                                               ▼
       │                                          最小反例
       │                                    (Minimal Counterexample)
       │                                               │
       └───────────── AI 分析反例 ◄────────────────────┘
                    调整属性/修复代码

┌─────────────────────────────────────────────────┐
│  第 1 层：需求文档 (requirements.md)              │
│  "用户注册时，邮箱必须唯一"                        │
│  → 属性：对任意两个成功注册的用户，email 不相同      │
├─────────────────────────────────────────────────┤
│  第 2 层：设计文档 (design.md)                    │
│  "排序算法使用归并排序，时间复杂度 O(n log n)"      │
│  → 属性：输出有序 + 长度不变 + 元素集合不变          │
├─────────────────────────────────────────────────┤
│  第 3 层：API 契约 (OpenAPI/GraphQL Schema)       │
│  "GET /users/{id} 返回 200 或 404"               │
│  → 属性：对任意有效 id，状态码 ∈ {200, 404}        │
├─────────────────────────────────────────────────┤
│  第 4 层：代码实现 (源代码)                        │
│  函数签名 + 类型约束 + 注释                        │
│  → 属性：类型不变量、前置/后置条件                   │
└─────────────────────────────────────────────────┘

你是一位 Property-Based Testing 专家。请分析以下需求文档，
为每个验收标准识别可测试的属性。

## 需求文档
[粘贴 requirements.md 内容]

## 输出格式
对每个验收标准，请提供：
1. 验收标准编号和描述
2. 是否可作为 PBT 属性测试（是/否/部分）
3. 如果可以，写出属性的形式化描述
4. 建议的生成器策略（输入空间如何约束）
5. 预期的边缘场景

请用以下格式输出：
### AC [编号]: [描述]
- **可测试性**: [是/否/部分]
- **属性**: ∀ [变量]: [属性描述]
- **生成器**: [生成器策略]
- **边缘场景**: [列表]

分析以下函数签名和文档注释，识别所有可测试的属性。
重点关注：
1. 往返属性（如果存在逆操作）
2. 幂等属性（重复调用是否等价）
3. 不变量（输出必须满足的条件）
4. 单调性（输入增大时输出的变化方向）
5. 分配律/结合律等代数属性

## 代码
[粘贴函数签名和注释]

对每个发现的属性，请提供：
- 属性名称和形式化描述
- 对应的 [框架名] 测试代码
- 推荐的生成器约束

你是 Kiro Spec 驱动开发的 PBT 专家。请分析以下 design.md 
中的 Correctness Properties 部分，将每个属性转化为可执行的
Property-Based Test。

## Design 文档
[粘贴 design.md 的 Correctness Properties 部分]

## 目标框架
[fast-check / Hypothesis / proptest / Go rapid]

## 输出要求
对每个属性：
1. 属性的自然语言描述
2. 形式化表达
3. 完整的测试代码（包含生成器定义）
4. 预期的收缩行为
5. 与 requirements.md 的可追溯性链接

属性发现检查清单：

□ 往返属性
  - 是否存在 encode/decode、serialize/deserialize、compress/decompress 对？
  - 是否存在 create/delete、push/pop、enqueue/dequeue 对？

□ 幂等属性
  - 排序、去重、格式化、规范化操作是否幂等？
  - HTTP PUT/DELETE 是否幂等？

□ 不变量
  - 集合操作后大小关系是否成立？（filter 后 ≤ 原长度）
  - 数值操作后范围是否成立？（百分比 ∈ [0, 100]）
  - 类型约束是否始终满足？（非空、非负、有效枚举值）

□ 等价/Oracle 属性
  - 是否存在简单但慢的参考实现？
  - 是否存在已知正确的第三方库可对比？

□ 变形属性
  - 输入排列是否影响输出？（排序不受输入顺序影响）
  - 输入缩放是否有已知的输出关系？

□ 保持属性
  - 操作是否保持元素集合不变？（排序不增删元素）
  - 操作是否保持某种度量不变？（旋转保持距离）

□ 交换律/结合律
  - 二元操作是否满足交换律？ f(a, b) == f(b, a)
  - 二元操作是否满足结合律？ f(f(a, b), c) == f(a, f(b, c))

import fc from 'fast-check';
 
// 生成一个有效的电商订单
const orderArbitrary = fc.record({
  id: fc.uuid(),
  customer: fc.record({
    name: fc.string({ minLength: 1, maxLength: 100 }),
    email: fc.emailAddress(),
  }),
  // 先生成 1-10 个商品项
  items: fc.array(
    fc.record({
      productId: fc.uuid(),
      name: fc.string({ minLength: 1 }),
      price: fc.integer({ min: 1, max: 1_000_000 }), // 分为单位
      quantity: fc.integer({ min: 1, max: 99 }),
    }),
    { minLength: 1, maxLength: 10 }
  ),
  // 折扣率 0-50%
  discountPercent: fc.integer({ min: 0, max: 50 }),
}).map(order => ({
  ...order,
  // 计算总价（派生字段）
  total: order.items.reduce(
    (sum, item) => sum + item.price * item.quantity, 0
  ) * (100 - order.discountPercent) / 100,
}));
 
// 属性：订单总价始终非负
fc.assert(
  fc.property(orderArbitrary, (order) => {
    return order.total >= 0;
  })
);

from hypothesis import given, settings
from hypothesis import strategies as st
from hypothesis.stateful import RuleBasedStateMachine, rule, invariant
 
class ShoppingCartMachine(RuleBasedStateMachine):
    """购物车状态机测试"""
    
    def __init__(self):
        super().__init__()
        self.cart = ShoppingCart()
        self.expected_items: dict[str, int] = {}
    
    @rule(
        product_id=st.text(min_size=1, max_size=20),
        quantity=st.integers(min_value=1, max_value=10)
    )
    def add_item(self, product_id: str, quantity: int):
        """添加商品到购物车"""
        self.cart.add(product_id, quantity)
        self.expected_items[product_id] = (
            self.expected_items.get(product_id, 0) + quantity
        )
    
    @rule(product_id=st.text(min_size=1, max_size=20))
    def remove_item(self, product_id: str):
        """从购物车移除商品"""
        self.cart.remove(product_id)
        self.expected_items.pop(product_id, None)
    
    @invariant()
    def items_match(self):
        """不变量：购物车内容与预期一致"""
        for pid, qty in self.expected_items.items():
            assert self.cart.get_quantity(pid) == qty
    
    @invariant()
    def total_non_negative(self):
        """不变量：总价始终非负"""
        assert self.cart.total() >= 0
 
# 运行状态机测试
TestShoppingCart = ShoppingCartMachine.TestCase

// 生成一个有效的日期范围（start <= end）
const dateRangeArbitrary = fc
  .tuple(
    fc.date({ min: new Date('2020-01-01'), max: new Date('2030-12-31') }),
    fc.date({ min: new Date('2020-01-01'), max: new Date('2030-12-31') })
  )
  .map(([a, b]) => a <= b ? { start: a, end: b } : { start: b, end: a });
 
// 生成一个有效的分页请求（offset + limit <= total）
const paginationArbitrary = fc
  .integer({ min: 1, max: 10000 })  // total
  .chain(total =>
    fc.tuple(
      fc.constant(total),
      fc.integer({ min: 0, max: total }),  // offset
      fc.integer({ min: 1, max: 100 })     // limit
    )
  )
  .map(([total, offset, limit]) => ({ total, offset, limit }));

package generators
 
import (
    "pgregory.net/rapid"
    "testing"
)
 
// 生成有效的中国手机号
func PhoneNumber() *rapid.Generator[string] {
    prefixes := []string{"130", "131", "132", "133", "134", "135",
        "136", "137", "138", "139", "150", "151", "152", "153",
        "155", "156", "157", "158", "159", "186", "187", "188", "189"}
    return rapid.Custom(func(t *rapid.T) string {
        prefix := rapid.SampledFrom(prefixes).Draw(t, "prefix")
        suffix := rapid.StringMatching(`[0-9]{8}`).Draw(t, "suffix")
        return prefix + suffix
    })
}
 
// 生成有效的 IPv4 地址
func IPv4Address() *rapid.Generator[string] {
    return rapid.Custom(func(t *rapid.T) string {
        octets := make([]int, 4)
        for i := range octets {
            octets[i] = rapid.IntRange(0, 255).Draw(t, "octet")
        }
        return fmt.Sprintf("%d.%d.%d.%d",
            octets[0], octets[1], octets[2], octets[3])
    })
}
 
// 生成有效的金额（分为单位，避免浮点精度问题）
func MoneyInCents(min, max int64) *rapid.Generator[int64] {
    return rapid.Int64Range(min, max)
}
 
// 属性测试：手机号格式验证
func TestPhoneNumberFormat(t *testing.T) {
    rapid.Check(t, func(t *rapid.T) {
        phone := PhoneNumber().Draw(t, "phone")
        if len(phone) != 11 {
            t.Fatalf("手机号长度应为 11，实际为 %d: %s", len(phone), phone)
        }
    })
}

你是一位 PBT 生成器设计专家。请为以下数据类型设计智能生成器。

## 数据类型定义
[粘贴类型定义 / 接口 / struct]

## 业务约束
[列出字段间的约束关系，如 start_date < end_date]

## 目标框架
[fast-check / Hypothesis / proptest / rapid]

## 要求
1. 生成器必须只产生满足所有业务约束的有效数据
2. 偏向生成边界值（空字符串、零值、最大值）
3. 支持高效收缩（优先使用 map/chain 而非 filter）
4. 提供生成器的单元测试，验证生成的数据确实满足约束
5. 如果存在可复用的子生成器，请提取为独立函数

请分析以下 TypeScript 接口，列出：
1. 每个字段的类型约束（范围、格式、可选性）
2. 字段间的依赖关系（如 endDate > startDate）
3. 隐含的业务规则（如 discount 不能超过 total）
4. 边界值列表（每个字段的极端有效值）

interface Order {
  id: string;
  items: OrderItem[];
  discount: number;
  total: number;
  status: 'pending' | 'paid' | 'shipped' | 'delivered';
  createdAt: Date;
  updatedAt: Date;
}

// 验证生成器本身的正确性
fc.assert(
  fc.property(orderArbitrary, (order) => {
    // 生成器应该只产生有效订单
    return (
      order.items.length >= 1 &&
      order.total >= 0 &&
      order.createdAt <= order.updatedAt
    );
  }),
  { numRuns: 10000 } // 大量运行验证生成器质量
);

你的项目使用什么语言？
│
├── JavaScript/TypeScript
│   └── → fast-check（唯一成熟选择，生态完善）
│
├── Python
│   └── → Hypothesis（事实标准，支持状态机测试）
│
├── Rust
│   ├── 需要 Hypothesis 风格的策略组合？
│   │   └── → proptest（最成熟，75M+ 下载）
│   └── 需要更好的收缩？
│       └── → pbt（2025 新库，收缩优于 proptest）
│
├── Go
│   ├── 简单属性测试？
│   │   └── → testing/quick（标准库，零依赖）
│   └── 需要完整 PBT 功能？
│       └── → rapid（现代设计，自动收缩）
│
├── Java/Kotlin
│   └── → jqwik（JUnit 5 集成，功能完整）
│
└── Haskell
    └── → QuickCheck（PBT 鼻祖，生态最丰富）

requirements.md          design.md              tasks.md
┌──────────────┐    ┌──────────────────┐    ┌──────────────┐
│ 验收标准      │    │ Correctness      │    │ PBT 任务      │
│ (AC)         │───▶│ Properties       │───▶│ (带属性编号)  │
│              │    │ (正确性属性)      │    │              │
│ WHEN X       │    │ P1: ∀x: f(x)≥0  │    │ 实现 P1 测试  │
│ THEN Y       │    │ P2: roundtrip    │    │ 实现 P2 测试  │
└──────────────┘    └──────────────────┘    └──────────────┘

### Requirement 3: 文件差异计算
 
#### Acceptance Criteria
3.1 WHEN 两个相同的文件被比较, THEN 差异结果为空
3.2 WHEN 对文件 A 应用差异补丁, THEN 结果等于文件 B
3.3 WHEN 差异计算完成, THEN 补丁大小不超过两个文件大小之和

## Correctness Properties
 
P1: Roundtrip — 对任意文件对 (a, b)，apply(a, diff(a, b)) == b
P2: Empty diff — 对任意文件 a，diff(a, a) == empty
P3: Patch size bound — 对任意文件对 (a, b)，
    size(diff(a, b)) <= size(a) + size(b)

import fc from 'fast-check';
import { diff, apply, DiffResult } from '../src/diff';
 
// 文件内容生成器：模拟真实文件的字节序列
const fileContentArb = fc.oneof(
  fc.uint8Array({ minLength: 0, maxLength: 1000 }),  // 小文件
  fc.uint8Array({ minLength: 1000, maxLength: 10000 }), // 中等文件
  fc.constant(new Uint8Array(0)),  // 空文件（边界值）
);
 
describe('文件差异计算 - Property-Based Tests', () => {
  /**
   * P1: Roundtrip 属性
   * Validates: Requirements 3.2
   * 对任意文件对 (a, b)，apply(a, diff(a, b)) == b
   */
  test('P1: apply(a, diff(a, b)) should equal b', () => {
    fc.assert(
      fc.property(
        fileContentArb,
        fileContentArb,
        (fileA, fileB) => {
          const patch = diff(fileA, fileB);
          const result = apply(fileA, patch);
          expect(result).toEqual(fileB);
        }
      ),
      { numRuns: 500 }
    );
  });
 
  /**
   * P2: Empty diff 属性
   * Validates: Requirements 3.1
   * 对任意文件 a，diff(a, a) 应为空
   */
  test('P2: diff(a, a) should be empty', () => {
    fc.assert(
      fc.property(fileContentArb, (file) => {
        const result = diff(file, file);
        expect(result.changes).toHaveLength(0);
      }),
      { numRuns: 500 }
    );
  });
 
  /**
   * P3: Patch size bound 属性
   * Validates: Requirements 3.3
   * 补丁大小不超过两个文件大小之和
   */
  test('P3: patch size should not exceed sum of file sizes', () => {
    fc.assert(
      fc.property(
        fileContentArb,
        fileContentArb,
        (fileA, fileB) => {
          const patch = diff(fileA, fileB);
          const patchSize = JSON.stringify(patch).length;
          const maxSize = fileA.length + fileB.length;
          return patchSize <= maxSize;
        }
      ),
      { numRuns: 500 }
    );
  });
});

requirements.md AC 3.2
        │
        ▼
design.md Property P1
        │
        ▼
tasks.md "实现 P1 测试"
        │
        ▼
diff.property.test.ts
  test('P1: roundtrip')
  // Validates: Requirements 3.2

发现失败输入: [847, -23, 0, 512, -1, 99, 0, 3, -456, 72]
                                    │
                              收缩过程
                                    │
第 1 轮: [847, -23, 0, 512, -1]     ← 尝试取前半部分
         仍然失败 ✓ 继续收缩
                                    │
第 2 轮: [-23, 0, -1]               ← 移除不影响失败的元素
         仍然失败 ✓ 继续收缩
                                    │
第 3 轮: [-1, 0]                    ← 进一步简化
         仍然失败 ✓ 继续收缩
                                    │
第 4 轮: [-1]                       ← 尝试单元素
         通过了 ✗ 回退到上一步
                                    │
第 5 轮: [0]                        ← 尝试另一个单元素
         通过了 ✗ 回退
                                    │
最小反例: [-1, 0]                   ← 无法进一步收缩

// ❌ 差：filter 会导致收缩效率低下
// 因为收缩后的值可能不满足 filter 条件，被丢弃
const evenNumber = fc.integer().filter(n => n % 2 === 0);
 
// ✅ 好：map 保证收缩后的值仍然有效
const evenNumber = fc.integer().map(n => n * 2);

// ❌ 差：生成后过滤，收缩效率低
const dateRange = fc
  .tuple(fc.date(), fc.date())
  .filter(([a, b]) => a < b);
 
// ✅ 好：用 chain 确保约束在生成时就满足
const dateRange = fc.date().chain(start =>
  fc.date({ min: start }).map(end => ({ start, end }))
);

from hypothesis import given, settings, HealthCheck
from hypothesis import strategies as st
 
# 使用 @example 提供已知的重要边界值
# 这些值会在随机测试之前先被测试
@given(st.lists(st.integers()))
@settings(
    max_examples=1000,
    suppress_health_check=[HealthCheck.too_slow],
    database=None,  # 禁用数据库缓存以获得更好的收缩
)
def test_sort_preserves_length(xs):
    assert len(sorted(xs)) == len(xs)

use proptest::prelude::*;
 
// 自定义策略：生成有效的 HTTP 状态码
fn http_status_code() -> impl Strategy<Value = u16> {
    prop_oneof![
        // 常见状态码（高权重，更容易收缩到这些值）
        3 => Just(200u16),
        3 => Just(201u16),
        3 => Just(400u16),
        3 => Just(404u16),
        3 => Just(500u16),
        // 随机有效状态码（低权重）
        1 => (100u16..600u16),
    ]
}
 
proptest! {
    #[test]
    fn test_status_code_category(code in http_status_code()) {
        let category = categorize_status(code);
        match code {
            100..=199 => prop_assert_eq!(category, "informational"),
            200..=299 => prop_assert_eq!(category, "success"),
            300..=399 => prop_assert_eq!(category, "redirect"),
            400..=499 => prop_assert_eq!(category, "client_error"),
            500..=599 => prop_assert_eq!(category, "server_error"),
            _ => prop_assert!(false, "unexpected status code: {}", code),
        }
    }
}

fc.assert(
  fc.property(myArbitrary, (input) => {
    // 你的属性
    return someCondition(input);
  }),
  {
    numRuns: 1000,
    verbose: 2,  // 显示收缩过程的详细日志
    endOnFailure: true,  // 第一次失败就停止
    // seed: 12345,  // 固定种子以复现特定失败
  }
);

# 在 pytest 中查看收缩过程
# 运行: pytest --hypothesis-show-statistics -v
 
@settings(
    max_examples=500,
    verbosity=Verbosity.verbose,  # 显示每次尝试
)
@given(st.lists(st.integers()))
def test_my_property(xs):
    assert my_function(xs) >= 0

┌─────────────────────────────────────────────────────────────┐
│                    AI 辅助 PBT 工作流                        │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  步骤 1: 属性发现                                            │
│  ┌──────────┐    ┌──────────┐    ┌──────────┐              │
│  │ Spec 文档 │───▶│ AI 分析  │───▶│ 属性列表 │              │
│  └──────────┘    └──────────┘    └──────────┘              │
│                                       │                     │
│  步骤 2: 生成器设计                     │                     │
│  ┌──────────┐    ┌──────────┐    ┌────▼─────┐              │
│  │ 类型定义  │───▶│ AI 设计  │───▶│ 生成器   │              │
│  └──────────┘    └──────────┘    └──────────┘              │
│                                       │                     │
│  步骤 3: 测试代码生成                   │                     │
│  ┌──────────┐    ┌──────────┐    ┌────▼─────┐              │
│  │ 属性+生成器│───▶│ AI 编写  │───▶│ 测试文件 │              │
│  └──────────┘    └──────────┘    └──────────┘              │
│                                       │                     │
│  步骤 4: 执行与分析                     │                     │
│  ┌──────────┐    ┌──────────┐    ┌────▼─────┐              │
│  │ 运行测试  │───▶│ AI 分析  │───▶│ 修复建议 │              │
│  │          │    │ 反例     │    │          │              │
│  └──────────┘    └──────────┘    └──────────┘              │
│                                                             │
└─────────────────────────────────────────────────────────────┘

.kiro/specs/my-feature/
├── requirements.md    # 包含验收标准
├── design.md          # 包含 Correctness Properties
└── tasks.md           # 包含 PBT 任务

请阅读以下 requirements.md 和 design.md，识别所有可以用
Property-Based Testing 验证的属性。

对每个属性，请提供：
1. 属性名称（如 P1, P2...）
2. 自然语言描述
3. 形式化表达（使用 ∀ 量词）
4. 对应的验收标准编号
5. 推荐的测试框架

[粘贴 Spec 内容]

基于以下属性列表和数据类型定义，为每个属性设计智能生成器。

## 属性列表
[步骤 2 的输出]

## 数据类型
[粘贴相关类型定义]

## 要求
- 使用 [框架名] 语法
- 生成器应覆盖边界值
- 优先使用 map/chain 而非 filter
- 为复杂类型提供分层生成策略

请基于以下属性和生成器，生成完整的 PBT 测试文件。

## 属性和生成器
[步骤 2 和 3 的输出]

## 要求
- 每个测试用 JSDoc/docstring 注释说明属性
- 包含 "Validates: Requirements X.Y" 可追溯性标注
- 设置合理的 numRuns（默认 500）
- 包含 seed 固定机制以便复现

# fast-check (Jest/Vitest)
npx vitest run --reporter=verbose src/**/*.property.test.ts
 
# Hypothesis (pytest)
pytest --hypothesis-show-statistics -v tests/property/
 
# proptest (Rust)
cargo test --lib -- --nocapture property_tests
 
# rapid (Go)
go test -v -run TestProperty ./...

PBT 测试失败，请分析以下反例并判断原因：

## 失败的属性
[属性描述]

## 反例
[框架输出的最小反例]

## 相关代码
[被测函数的实现]

## 请判断
1. 这是测试本身的问题（属性定义不正确）？
2. 这是代码的 bug（需要修复实现）？
3. 这是 Spec 的问题（需求不完整或矛盾）？

请给出你的判断理由和修复建议。

PBT 测试失败，得到反例 X
│
├── 反例 X 是否满足属性的前置条件？
│   ├── 否 → 生成器问题：生成器产生了无效输入
│   │        修复：调整生成器约束
│   │
│   └── 是 → 继续判断
│       │
│       ├── 手动验证：f(X) 的结果是否符合预期？
│       │   ├── 不符合 → 代码 bug
│       │   │            修复：修改被测函数实现
│       │   │
│       │   └── 符合 → 继续判断
│       │       │
│       │       ├── 属性定义是否正确反映了需求？
│       │       │   ├── 否 → 属性定义错误
│       │       │   │        修复：调整属性定义
│       │       │   │
│       │       │   └── 是 → 需求本身可能有问题
│       │       │            行动：与产品经理/用户确认需求
│       │       │
│       │       └── 是否是浮点精度问题？
│       │           └── 是 → 使用近似比较
│       │                    修复：expect(a).toBeCloseTo(b)
│       │
│       └── 反例是否涉及并发/时序？
│           └── 是 → 可能是竞态条件
│                    修复：添加同步机制

你是一位 PBT 反例分析专家。请分析以下测试失败：

## 测试属性
名称: [属性名]
描述: [自然语言描述]
形式化: [∀ x: ...]

## 反例（框架收缩后的最小反例）
输入: [反例值]
期望: [期望的输出/行为]
实际: [实际的输出/行为]

## 被测代码
```[语言]
[被测函数实现]

### 8.4 反例复现与回归测试

发现的反例应该被固化为回归测试：

**fast-check**：
```typescript
// 将 PBT 发现的反例固化为具体测试
describe('回归测试（来自 PBT 反例）', () => {
  // 2025-06-15 PBT 发现：空数组导致除零错误
  test('regression: empty array should return 0 average', () => {
    expect(average([])).toBe(0);
  });

  // 2025-06-16 PBT 发现：负数价格导致总价计算错误
  test('regression: negative price should be rejected', () => {
    expect(() => createOrder([{ price: -1, qty: 1 }])).toThrow();
  });
});

// 也可以使用 fast-check 的 seed 复现
fc.assert(
  fc.property(myArbitrary, myProperty),
  { seed: 1234567890 }  // 使用失败时记录的 seed
);

from hypothesis import given, example
 
# Hypothesis 自动将发现的反例存入数据库
# 下次运行时会优先测试这些已知的失败输入
 
# 也可以手动添加 @example 装饰器
@given(st.lists(st.integers()))
@example([])           # 空列表（PBT 发现的边界值）
@example([0, 0, 0])    # 全零列表（PBT 发现的边界值）
@example([-1, 1])      # 正负混合（PBT 发现的边界值）
def test_sort_preserves_elements(xs):
    sorted_xs = sorted(xs)
    assert sorted(sorted_xs) == sorted(xs)

// fast-check: JSON 序列化往返
fc.assert(
  fc.property(fc.anything(), (value) => {
    const serialized = JSON.stringify(value);
    const deserialized = JSON.parse(serialized);
    // 注意：JSON 不支持 undefined、函数等，需要约束输入
    expect(deserialized).toEqual(value);
  })
);

# Hypothesis: Base64 编码往返
@given(st.binary())
def test_base64_roundtrip(data: bytes):
    encoded = base64.b64encode(data)
    decoded = base64.b64decode(encoded)
    assert decoded == data

// Go rapid: URL 编码往返
func TestURLEncodingRoundtrip(t *testing.T) {
    rapid.Check(t, func(t *rapid.T) {
        original := rapid.String().Draw(t, "input")
        encoded := url.QueryEscape(original)
        decoded, err := url.QueryUnescape(encoded)
        if err != nil {
            t.Fatal(err)
        }
        if decoded != original {
            t.Fatalf("roundtrip failed: %q -> %q -> %q",
                original, encoded, decoded)
        }
    })
}

// fast-check: 排序幂等
fc.assert(
  fc.property(fc.array(fc.integer()), (arr) => {
    const sorted1 = [...arr].sort((a, b) => a - b);
    const sorted2 = [...sorted1].sort((a, b) => a - b);
    expect(sorted2).toEqual(sorted1);
  })
);

# Hypothesis: HTML 清理幂等
@given(st.text())
def test_sanitize_idempotent(html: str):
    once = sanitize_html(html)
    twice = sanitize_html(once)
    assert once == twice

// fast-check: filter 后长度不变量
fc.assert(
  fc.property(
    fc.array(fc.integer()),
    fc.func(fc.boolean()),  // 随机谓词
    (arr, predicate) => {
      const filtered = arr.filter(predicate);
      return filtered.length <= arr.length;
    }
  )
);

// Go rapid: Map 操作后键集合不变量
func TestMapKeysInvariant(t *testing.T) {
    rapid.Check(t, func(t *rapid.T) {
        m := rapid.MapOf(
            rapid.String(),
            rapid.Int(),
        ).Draw(t, "map")
        
        // 对所有值加 1
        transformed := make(map[string]int)
        for k, v := range m {
            transformed[k] = v + 1
        }
        
        // 键集合应该不变
        if len(transformed) != len(m) {
            t.Fatal("key set changed after value transformation")
        }
        for k := range m {
            if _, ok := transformed[k]; !ok {
                t.Fatalf("key %q missing after transformation", k)
            }
        }
    })
}

# Hypothesis: 快速排序 vs 内置排序
@given(st.lists(st.integers()))
def test_quicksort_matches_builtin(xs):
    assert quicksort(xs) == sorted(xs)

// fast-check: 搜索结果的变形属性
// 添加更多搜索关键词不应增加结果数量
fc.assert(
  fc.property(
    fc.string({ minLength: 1 }),  // 基础查询
    fc.string({ minLength: 1 }),  // 额外关键词
    (query, extraKeyword) => {
      const results1 = search(query);
      const results2 = search(`${query} ${extraKeyword}`);
      // 更精确的查询结果应该 ≤ 更宽泛的查询
      return results2.length <= results1.length;
    }
  )
);

# Hypothesis: 排序保持元素集合
@given(st.lists(st.integers()))
def test_sort_preserves_elements(xs):
    sorted_xs = sorted(xs)
    assert sorted(sorted_xs) == sorted(xs)  # 多重集相等
    assert len(sorted_xs) == len(xs)

// fast-check: 集合并集的交换律
fc.assert(
  fc.property(
    fc.uniqueArray(fc.integer()),
    fc.uniqueArray(fc.integer()),
    (setA, setB) => {
      const unionAB = new Set([...setA, ...setB]);
      const unionBA = new Set([...setB, ...setA]);
      expect(unionAB).toEqual(unionBA);
    }
  )
);

请使用 fast-check 为以下 TypeScript 函数编写 Property-Based Tests。

## 函数签名
```typescript
[粘贴函数签名和 JSDoc]

### 10.2 Hypothesis (Python)

[粘贴函数签名和 docstring]

### 10.3 Go rapid

[粘贴函数签名和注释]

### 10.4 proptest (Rust)

[粘贴函数签名和文档注释]

---

## 实战案例：电商订单系统的 AI 辅助 PBT

### 案例背景

一个电商平台的订单计算模块，需要验证价格计算、折扣应用、库存扣减等核心逻辑。团队使用 Kiro 的 Spec 驱动工作流，从需求文档中提取属性并生成 PBT。

### 案例分析

#### 第 1 步：从需求提取属性

**requirements.md（节选）**：
```markdown
### Requirement: 订单价格计算

#### Acceptance Criteria
AC1: WHEN 订单包含多个商品, THEN 总价等于所有商品（单价×数量）之和
AC2: WHEN 应用折扣码, THEN 折扣后价格 = 原价 × (1 - 折扣率)
AC3: WHEN 折扣后价格计算完成, THEN 最终价格不低于 0
AC4: WHEN 订单创建成功, THEN 库存应减少对应数量
AC5: WHEN 订单取消, THEN 库存应恢复到订单创建前的状态

import fc from 'fast-check';
 
// 商品生成器
const productArb = fc.record({
  id: fc.uuid(),
  name: fc.string({ minLength: 1, maxLength: 50 }),
  price: fc.integer({ min: 1, max: 10_000_00 }), // 1分 ~ 10万元（分为单位）
  stock: fc.integer({ min: 0, max: 10000 }),
});
 
// 订单项生成器（数量不超过库存）
const orderItemArb = (maxStock: number) =>
  fc.record({
    productId: fc.uuid(),
    price: fc.integer({ min: 1, max: 10_000_00 }),
    quantity: fc.integer({ min: 1, max: Math.max(1, maxStock) }),
  });
 
// 订单生成器
const orderArb = fc.array(
  orderItemArb(100),
  { minLength: 1, maxLength: 20 }
);
 
// 折扣率生成器（0% ~ 100%）
const discountArb = fc.integer({ min: 0, max: 100 });

describe('订单价格计算 - Property-Based Tests', () => {
  /**
   * AC1: 总价等于所有商品（单价×数量）之和
   * Validates: Requirements AC1
   */
  test('P1: total equals sum of item prices × quantities', () => {
    fc.assert(
      fc.property(orderArb, (items) => {
        const expectedTotal = items.reduce(
          (sum, item) => sum + item.price * item.quantity, 0
        );
        const actualTotal = calculateTotal(items);
        return actualTotal === expectedTotal;
      }),
      { numRuns: 1000 }
    );
  });
 
  /**
   * AC2: 折扣后价格 = 原价 × (1 - 折扣率)
   * Validates: Requirements AC2
   */
  test('P2: discounted price equals total × (1 - rate)', () => {
    fc.assert(
      fc.property(orderArb, discountArb, (items, discountPercent) => {
        const total = calculateTotal(items);
        const discounted = applyDiscount(total, discountPercent);
        const expected = Math.floor(total * (100 - discountPercent) / 100);
        return discounted === expected;
      }),
      { numRuns: 1000 }
    );
  });
 
  /**
   * AC3: 最终价格不低于 0
   * Validates: Requirements AC3
   */
  test('P3: final price is never negative', () => {
    fc.assert(
      fc.property(orderArb, discountArb, (items, discountPercent) => {
        const total = calculateTotal(items);
        const finalPrice = applyDiscount(total, discountPercent);
        return finalPrice >= 0;
      }),
      { numRuns: 1000 }
    );
  });
 
  /**
   * AC5: 订单取消后库存恢复（往返属性）
   * Validates: Requirements AC5
   */
  test('P5: cancel(create(order)) restores stock', () => {
    fc.assert(
      fc.property(orderArb, (items) => {
        const initialStock = new Map(
          items.map(item => [item.productId, 1000])
        );
        
        // 创建订单 → 扣减库存
        const afterCreate = createOrder(items, new Map(initialStock));
        
        // 取消订单 → 恢复库存
        const afterCancel = cancelOrder(afterCreate.orderId, afterCreate.stock);
        
        // 库存应该恢复到初始状态
        for (const [id, qty] of initialStock) {
          if (afterCancel.get(id) !== qty) return false;
        }
        return true;
      }),
      { numRuns: 500 }
    );
  });
});