accelint-ts-testing by gohypergiant/agent-skills
npx skills add https://github.com/gohypergiant/agent-skills --skill accelint-ts-testing编写可维护、高效的 Vitest 测试的综合模式。专注于测试组织、清晰度和性能方面的专家级指导。
export const X = value)、类型定义文件、GLSL uniform 声明和纯数据文件不包含任何需要测试的逻辑。测试 expect(MY_CONSTANT).toBe(42) 无法验证任何内容:如果值发生变化,测试也会随之改变,提供零保护。这些"测试"浪费 CI 时间,并在值更改时产生维护负担。测试行为(函数、逻辑、转换),而不是数据声明。如果文件仅导出类型、常量或数据结构而没有函数或逻辑,则完全跳过测试。vitest.config.ts 中配置 clearMocks: true、mockReset: true、restoreMocks: true 一次,即可消除整个依赖顺序的故障类别。it('should add item to empty cart') 而不是 。广告位招租
在这里展示您的产品或服务
触达数万 AI 开发者,精准高效
describe('when cart is empty', () => describe('addItem', ...))it('should add item to cart'),而不是 it('Add item to cart') 或 it('It should add item to cart')。当加上"it"前缀时,描述应读作一个句子:"it should add item to cart"。大写开头、非句子格式如 it('addToCart test') 或冗余的"It should"会破坏可读性和测试输出一致性。基于示例的测试使用 it('should...') 格式,而基于属性的测试使用 it('property: ...') 格式。expect(array.map(fn)).toEqual(expected) 是浪费时间验证 Array.prototype.map 是否正常工作。JavaScript/TypeScript 标准库和成熟的第三方库已经经过充分测试。将测试重点放在业务逻辑上,而不是证明 lodash、React 或语言本身是否有效。如果你发现自己正在测试"这个库函数是否做了它声称的事情?",那么你测试的是错误的层级。测试你的代码如何使用库,而不是库是否工作。toBeTruthy() 或 toBeDefined() - 这些断言会通过多个你从未打算的不同值:toBeTruthy() 对 1、"false"、[] 和 {} 都会通过 - 所有这些在语义上都是不同的。当重构将 getUser() 从返回 {id: 1} 更改为返回 1 时,你的测试仍然通过,但生产代码会中断。宽松的断言会产生虚假的信心,这种信心在生产环境中会蒸发。toBeTypeOf() 不是宽松的断言。any 或跳过类型检查 - 当实现签名更改时,带有 as any 的测试会静默通过,同时使用错误的参数调用函数。你发布了 TypeScript 本可以捕获的损坏代码。测试是可执行的文档:user as any 不传达任何信息,但 createTestUser(Partial<User>) 精确显示了此测试用例重要的属性。tsconfig.json 编译路径之外,因此在项目根目录运行 tsc 不会捕获测试中的类型错误。测试中的类型错误会导致运行时故障、不正确的测试行为以及来自未测试其声称内容的测试的虚假信心。在将任何测试文件标记为"完成"之前,你必须使用项目的包管理器(npm/pnpm/bun/yarn)直接对测试文件运行 tsc --noEmit。对于 monorepo,首先 cd 到特定的包目录,然后运行类型检查。在继续之前修复所有类型错误 - 绝不要使用 as any 或 @ts-ignore 来绕过错误。JSON.parse() 结果、外部库、用户输入和数据库记录接收无效数据。类型为 process(data: ValidData) 的函数在运行时仍然可以接收 null、undefined 或格式错误的对象。测试防御性编程场景:将 null 传递给不可为空的参数,将 undefined 传递给必填字段,将格式错误的对象传递给类型化参数。这些"类型无效"的测试可以捕获 TypeScript 无法防止的实际错误。decode(encode(x)) === x),而不仅仅是解码成功。测试规范化时,验证幂等性(normalize(normalize(x)) === normalize(x)),而不仅仅是它返回一个字符串。弱属性给出虚假的信心:它们通过但实际上并不验证正确性。在实现测试之前应用这些专家思维模式:
export const X = 42)、类型定义文件(type User = {...})、GLSL uniform 声明、配置对象和纯数据文件没有可验证的行为。如果文件不包含函数、逻辑、转换 - 跳过测试它。测试行为,而不是数据。it.each() 进行参数化测试,而不是复制测试结构。每个概念一个断言可以保持测试的重点。关于 Vitest 测试模式的专家指导:
it.each() 减少重复本技能使用渐进式披露结构以最小化上下文使用:
阅读 AGENTS.md 以获取所有规则的简明概述,包括一行摘要和用于发现现有测试配置的工作流程。
在编写测试之前:
vitest.config.ts 中的全局模拟清理设置(clearMocks、mockReset、restoreMocks)test/setup.ts、vitest.setup.ts 等)并分析其配置使用这些明确的触发器来知道何时加载每个参考文件:
强制加载(加载整个文件):
当看到这些模式时加载:
toBeTruthy() 或 toBeDefined() → assertions.md除非特别需要,否则不要加载:
每个参考文件包含:
当调用此技能进行测试代码审查时,使用标准化的报告格式:
报告格式提供:
何时使用报告模板:
/accelint-ts-testing <路径> 直接调用技能何时不使用报告模板:
重要提示:审计测试时,务必检查基于属性的测试机会
查看 quick-start.md 以获取完整的之前/之后示例,展示此技能如何将不清晰的测试转换为清晰、可维护的测试。
每周安装次数
116
仓库
GitHub 星标数
7
首次出现
2026年1月30日
安全审计
安装于
claude-code104
codex102
opencode93
github-copilot92
cursor89
gemini-cli88
Comprehensive patterns for writing maintainable, effective vitest tests. Focused on expert-level guidance for test organization, clarity, and performance.
export const X = value), type definition files, GLSL uniform declarations, and pure data files contain no logic to test. Testing expect(MY_CONSTANT).toBe(42) verifies nothing: if the value changes, the test changes with it, providing zero protection. These "tests" waste CI time and create maintenance burden when values change. Test behavior (functions, logic, transformations), not data declarations. If a file exports only types, constants, or data structures with no functions or logic, skip testing it entirely.clearMocks: true, mockReset: true, restoreMocks: true in vitest.config.ts once to eliminate this entire class of order-dependent failure.it('should add item to empty cart') vs describe('when cart is empty', () => describe('addItem', ...)).it('should add item to cart') not it('Add item to cart') or it('It should add item to cart'). The description reads as a sentence when prefixed with "it": "it should add item to cart". Capitalized starts, non-sentence formats like it('addToCart test'), or redundant "It should" break readability and test output consistency. Example-based tests use it('should...') while property-based tests use it('property: ...') format.expect(array.map(fn)).toEqual(expected) wastes time verifying that Array.prototype.map works correctly. The JavaScript/TypeScript standard library and established third-party libraries are already well-tested. Focus tests on your business logic, not on proving that lodash, React, or the language itself works. If you find yourself testing "does this library function do what it claims?", you're testing the wrong layer. Test how your code uses libraries, not whether libraries work.toBeTruthy() or toBeDefined() - These assertions pass for multiple distinct values you never intended: toBeTruthy() passes for 1, "false", [], and {} - all semantically different. When refactoring changes getUser() from returning {id: 1} to returning 1, your test still passes but your production code breaks. Loose assertions create false confidence that evaporates in production. toBeTypeOf() is NOT a loose assertion.any or skip type checking in test files - When implementation signatures change, tests with as any silently pass while calling functions with wrong arguments. You ship broken code that TypeScript could have caught. Tests are executable documentation: user as any communicates nothing, but createTestUser(Partial<User>) shows exactly what properties matter for this test case.tsconfig.json compilation paths, so running tsc at the project root won't catch type errors in tests. Type errors in tests cause runtime failures, incorrect test behavior, and false confidence from tests that don't test what they claim. Before marking any test file as "done", you MUST run tsc --noEmit directly against the test file using the project's package manager (npm/pnpm/bun/yarn). For monorepos, cd into the specific package directory first, then run type checking. Fix all type errors before proceeding - never use as any or @ts-ignore to bypass errors.JSON.parse() results, external libraries, user input, and database records. A function typed as process(data: ValidData) can still receive null, undefined, or malformed objects at runtime. Test defensive programming scenarios: pass null to non-nullable parameters, undefined to required fields, malformed objects to typed parameters. These "type-invalid" tests catch real bugs that TypeScript cannot prevent.decode(encode(x)) === x), not just that decode succeeds. When testing normalization, verify idempotence (normalize(normalize(x)) === normalize(x)), not just that it returns a string. Weak properties give false confidence: they pass but don't actually validate correctness.Apply these expert thinking patterns before implementing tests:
export const X = 42), type definition files (type User = {...}), GLSL uniform declarations, configuration objects, and pure data files have no behavior to verify. If the file contains no functions, no logic, no transformations - skip testing it. Test behavior, not data.it.each() for parameterized tests instead of copying test structure. One assertion per concept keeps tests focused.Expert guidance on vitest testing patterns:
it.each() to reduce duplicationThis skill uses a progressive disclosure structure to minimize context usage:
Read AGENTS.md for a concise overview of all rules with one-line summaries and the workflow for discovering existing test configuration.
Before writing tests:
vitest.config.ts for global mock cleanup settings (clearMocks, mockReset, restoreMocks)test/setup.ts, vitest.setup.ts, etc.) and analyze their configurationUse these explicit triggers to know when to load each reference file:
MANDATORY Loading (load entire file):
Load When You See These Patterns:
toBeTruthy() or toBeDefined() → assertions.mdDo NOT Load Unless Specifically Needed:
Each reference file contains:
When this skill is invoked for test code review, use the standardized report format:
Template: assets/output-report-template.md
The report format provides:
When to use the report template:
/accelint-ts-testing <path>When NOT to use the report template:
IMPORTANT: When auditing tests, ALWAYS check for property-based testing opportunities
See quick-start.md for a complete before/after example showing how this skill transforms unclear tests into clear, maintainable ones.
Weekly Installs
116
Repository
GitHub Stars
7
First Seen
Jan 30, 2026
Security Audits
Gen Agent Trust HubPassSocketPassSnykPass
Installed on
claude-code104
codex102
opencode93
github-copilot92
cursor89
gemini-cli88
后端测试指南:API端点、业务逻辑与数据库测试最佳实践
11,800 周安装
ActiveCampaign自动化集成指南:通过Rube MCP实现CRM与营销自动化
72 周安装
通过Rube MCP实现Make自动化:集成Composio工具包管理场景与操作
72 周安装
Microsoft Teams自动化指南:通过Rube MCP实现频道消息、聊天与会议管理
72 周安装
Electrobun 最佳实践:TypeScript + Bun 跨平台桌面应用开发指南
72 周安装
ATXP Memory:AI代理记忆管理工具 - 云端备份与本地向量搜索
72 周安装
Brave Search Spellcheck API:智能拼写检查与查询纠正,提升搜索准确性
72 周安装