Token导航 LogoToken导航TokenDH.com
研究检索只读github未标认证来源可访问clear审计通过

test-isolation测试隔离

Agent Skill

用于辅助测试设计、自动化测试、用例整理和回归验证。它适合让 Agent 编写单元测试、端到端测试、测试计划或根据失败日志定位问题。使用时需要确认项目测试框架、运行命令和夹具数据,避免为了通过测试而改坏真实逻辑;涉及浏览器或外部服务时,应区分本地模拟、测试环境和生产环境。

总安装

594

周安装

25

GitHub Stars

10

下载量

208
CodexClaudeCursorGemini CLI

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

3

许可证

MIT

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:test-isolation(测试隔离)
来源仓库:https://github.com/yanko-belov/code-craft
仓库路径:skills/test-isolation
安装命令:
npx skills add https://github.com/yanko-belov/code-craft --skill test-isolation
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。不同来源提供的安装方式可能略有差异;本站展示可直接复制的安装命令,安装前请核对来源页面。

skills.shnpx skills
npx skills add https://github.com/yanko-belov/code-craft --skill test-isolation

简介

用于辅助测试设计、自动化测试、用例整理和回归验证。

  • 适合编写单元测试、端到端测试或根据日志定位问题。
  • 需确认项目测试框架、运行命令和夹具数据后使用。test-isolation 属于研究检索类 Skill,可作为该场景下的辅助能力补充。
  • 涉及浏览器或外部服务时应区分模拟环境与生产环境。
  • 安装方式:通过 npx 从指定 GitHub 仓库添加。

SKILL.md

Test Isolation

Overview

Each test must be independent. No shared state. No dependencies between tests.

Tests that depend on each other are brittle, hard to debug, and can't run in parallel. Every test should set up its own state and clean up after itself.

When to Use

  • Writing any test that uses shared data
  • Tests that must run in a specific order
  • Tests that fail randomly or when run alone
  • Test suites that can't run in parallel

The Iron Rule

NEVER let one test depend on another test's state or execution.

No exceptions:

  • Not for "it's more efficient"
  • Not for "the first test creates the data"
  • Not for "they always run in order"
  • Not for "it works on my machine"

Detection: Dependency Smell

If tests share mutable state or depend on order, STOP:

// ❌ VIOLATION: Tests depend on each other
describe('UserService', () => {
  let userService: UserService;
  let createdUserId: string;  // Shared state!

  it('creates a user', async () => {
    const user = await userService.create({ name: 'Alice' });
    createdUserId = user.id;  // First test sets state
    expect(user).toBeDefined();
  });

  it('finds the created user', async () => {
    const user = await userService.findById(createdUserId);  // Second test uses it
    expect(user.name).toBe('Alice');
  });
});

Problems:

  • Second test fails if first doesn't run
  • Can't run tests in parallel
  • Random failures when order changes

The Correct Pattern: Isolated Tests

Each test manages its own state:

// ✅ CORRECT: Each test is independent
describe('UserService', () => {
  let userService: UserService;

  beforeEach(() => {
    userService = new UserService(new InMemoryUserRepo());
  });

  afterEach(() => {
    // Clean up if needed
  });

  it('creates a user', async () => {
    const user = await userService.create({ name: 'Alice' });
    expect(user.id).toBeDefined();
    expect(user.name).toBe('Alice');
  });

  it('finds a user by id', async () => {
    // Arrange: Create own test data
    const created = await userService.create({ name: 'Bob' });

    // Act
    const found = await userService.findById(created.id);

    // Assert
    expect(found.name).toBe('Bob');
  });

  it('returns null for non-existent user', async () => {
    // No setup needed - tests the empty state
    const found = await userService.findById('non-existent');
    expect(found).toBeNull();
  });
});

Isolation Techniques

1. Fresh Instance Per Test

beforeEach(() => {
  service = new Service(new MockDependency());
});

2. Database Transactions

beforeEach(async () => {
  await db.beginTransaction();
});

afterEach(async () => {
  await db.rollback();  // Undo all changes
});

3. In-Memory Stores

beforeEach(() => {
  repository = new InMemoryRepository();  // Fresh empty store
});

4. Factory Functions

function createTestUser(overrides = {}) {
  return { id: uuid(), name: 'Test', ...overrides };
}

it('test 1', () => {
  const user = createTestUser({ name: 'Alice' });
});

it('test 2', () => {
  const user = createTestUser({ name: 'Bob' });  // Own data
});

Pressure Resistance Protocol

1. "It's More Efficient"

Pressure: "Creating data once and reusing is faster"

Response: Shared state causes random failures that waste hours debugging.

Action: Use beforeEach to create fresh state. The milliseconds saved aren't worth the debugging time.

2. "The First Test Creates Data"

Pressure: "Test 1 creates a user, Test 2 verifies it"

Response: This creates implicit coupling. Test 2 can't run alone.

Action: Each test creates its own data in Arrange phase.

3. "They Always Run In Order"

Pressure: "Our test runner executes sequentially"

Response: Test runners parallelize. CI environments differ. Order assumptions break.

Action: Write tests that pass regardless of order.

Red Flags - STOP and Reconsider

  • Variables declared outside tests and mutated inside
  • Tests that fail when run individually
  • Tests that fail when run in different order
  • beforeAll that creates data used by multiple tests
  • Comments like "run after test X"

All of these mean: Refactor for isolation.

Quick Reference

Shared State (Bad)Isolated (Good)
let userId outside testsCreate user in each test
beforeAll creates databeforeEach creates fresh data
Tests modify shared objectEach test has own instance
Order-dependent executionAny order works

Common Rationalizations (All Invalid)

ExcuseReality
"It's more efficient"Debugging flaky tests is inefficient.
"They run in order"Not in parallel mode or different environments.
"It works locally"It'll fail in CI.
"Just this one time"One coupling leads to more.
"The data is read-only"Until someone adds a write.

The Bottom Line

Every test stands alone. No shared state. No order dependencies.

If a test can't run by itself and pass, it's not a valid test. Each test creates what it needs, verifies what it should, and cleans up after itself.

适合场景

01

用户想查找某类 Agent Skill 时

02

需要根据任务场景推荐可安装能力包时

03

需要对比不同来源的安装命令和来源信息时

04

需要参考平台分布和安装热度时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

补充不同宿主或平台的使用分布数据

能力 5

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

Codex

27.43%
按下载量换算57

Claude Code

24.52%
按下载量换算51

windsurf

18.25%
按下载量换算38

Antigravity

13.85%
按下载量换算29

trae

7.62%
按下载量换算16

OpenCode

3.29%
按下载量换算7

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

通过

权限和风险

只读

该 Skill 主要提供规则、说明或参考内容,本身偏只读;真正读写文件、联网或执行命令仍取决于宿主 Agent 的任务。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。

来源信息

继续浏览同类 Skills