Token导航 LogoToken导航

Agent Skill · 研究检索

typescript-testing(TypeScript 测试)

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

typescript-testing 是研究检索类 Agent Skill,可用宿主为 Codex、Claude、Cursor、Gemini CLI,通过GitHub 仓库获取,权限为需要联网;许可证信息还不明确,第三方扫描已通过,按安装量在研究检索类的 73,675 个 Skill 里排第 71,596。

总安装 194周安装 8GitHub Stars 191下载 63核验 2026-05-01

安装说明

本站只整理中文说明,不托管安装包,也不代用户安装。
GitHub
许可证
unknown

安装方式

通过对话安装

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

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

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

skills.shnpx skills
npx skills add https://github.com/shinpr/ai-coding-project-boilerplate --skill typescript-testing

这个 Skill 是做什么的

研究检索类 Skill 主要解决「找资料、核对事实、把来源整理清楚」的问题,通常会让助手先检索再总结。

辅助测试设计与回归验证,支持单元测试、端到端测试用例编写。可用于根据失败日志定位问题或制定测试计划。需确认项目使用的测试框架和运行命令后再使用。涉及浏览器或外部服务时应区分模拟环境与真实环境。typescript-testing 属于研究检索类 Skill,可作为该场景下的辅助能力补充。

来源仓库内路径:skills/typescript-testing

上手步骤

4 步
  1. 1

    确认自己的宿主工具

    公开资料标注支持 Codex、Claude、Cursor、Gemini CLI;先确认自己用的是其中之一,再按对应工具的 Skills 目录放置。

  2. 2

    拿到安装命令

    可以直接复制的命令是 npx skills add https://github.com/shinpr/ai-coding-project-boilerplate --skill t…;命令里的占位符换成自己的路径或密钥再执行。

  3. 3

    安装后重启宿主

    命令执行完要完全退出宿主工具再打开,让新装的 Skill 被重新扫描到,否则列表里可能看不到。

  4. 4

    按最小权限试用

    它需要需要联网,先在测试目录或测试账号里跑,确认没问题再放到正式项目。

常见问题

6 条

typescript-testing 怎么安装?

在终端执行 npx skills add https://github.com/shinpr/ai-coding-project-boilerplate --skill typescript-…。装完完全退出宿主工具再打开,让它重新扫描本地 Skill。

typescript-testing 支持哪些 AI 工具?

公开资料标注支持 Codex、Claude、Cursor、Gemini CLI。其他工具只要能读取本地 Skill 目录,一般也能手动放进去,但要自己确认触发方式是否一致。

typescript-testing 需要什么权限?

权限级别是需要联网。该 Skill 可能需要联网访问来源站点、仓库或外部 API;具体网络访问范围需要结合源码和 README 复核。

typescript-testing 是免费的吗?

公开资料没有标注明确许可证,收费和商用限制都无法确认。正式使用前请到来源仓库核对授权说明。

typescript-testing 用的人多吗?

公开数据是累计安装 194 次,近一周安装 8 次,下载 63 次,GitHub 191 星。这些数字来自第三方目录统计,只能当作热度参考,不代表质量或安全性。

typescript-testing 安全吗?

第三方扫描结果为通过,但这只覆盖已知的静态检查项,不能替代自己读一遍源码和安装命令。

值得选的地方和要先想清楚的地方

值得选的地方

  • 同时适配 4 种工具,换客户端不用重新找替代品。
  • 第三方扫描已通过,常见的高风险行为没有命中。

先想清楚的地方

  • 许可证没有明确标注,能不能商用、能不能再分发都不确定。
  • 第三方目录整理,版本更新和行为细节以来源仓库为准。

适不适合你

更适合

  • 已经在用 Codex,想直接扩展它能力的人。
  • 需要处理研究检索类任务、又不想每次都手写提示词的人。

不太适合

  • 需要明确授权才能用到公司项目里的场景。
  • 需要厂商级技术支持和 SLA 的生产系统。

研究检索类 Skill 对比

6 个同类
Skill总安装GitHub 星权限许可证扫描
find-skills

寻找技能 · Codex、Claude

31,199,81316,486操作浏览器MIT有提醒
self-improving-agent

自我改进 Agent · OpenClaw

16,464,0023,396接触敏感数据MIT-0通过
soultrace

灵魂追踪 · Codex、Claude

7,588,94412需要联网未明确有提醒
self-improving

自我完善 · OpenClaw

6,829,2841,046需要联网MIT-0通过
microsoft-foundry

微软代工厂 · Codex、Claude

6,614,144764调用外部服务未明确有提醒
typescript-testing

TypeScript 测试 · 本页

194191需要联网未明确通过

按安装量取同分类前几名;数字来自第三方目录统计,只作热度参考,不代表质量结论。

SKILL.md 原文

TypeScript Testing Rules

Test Framework

  • Vitest: This project uses Vitest
  • Test imports: import {describe, it, expect, beforeEach, vi} from 'vitest'
  • Mock creation: Use vi.mock()

Basic Testing Policy

Quality Requirements

  • Coverage: Unit test coverage must be 70% or higher
  • Independence: Each test can run independently without depending on other tests
  • Reproducibility: Tests are environment-independent and always return the same results
  • Readability: Test code maintains the same quality as production code

Coverage Requirements

Mandatory: Unit test coverage must be 70% or higher Metrics: Statements, Branches, Functions, Lines

Test Types and Scope

  1. Unit Tests

- Verify behavior of individual functions or classes - Mock all external dependencies - Most numerous, implemented with fine granularity

  1. Integration Tests

- Verify coordination between multiple components - Use actual dependencies (DB, API, etc.) - Verify major functional flows

  1. Cross-functional Verification in E2E Tests

- Mandatory verification of impact on existing features when adding new features - Cover integration points with "High" and "Medium" impact levels from Design Doc's "Integration Point Map" - Verification pattern: Existing feature operation -> Enable new feature -> Verify continuity of existing features - Success criteria: No change in response content, processing time within 5 seconds - Designed for automatic execution in CI/CD pipelines

Test Implementation Conventions

Directory Structure

src/
└── application/
    └── services/
        ├── __tests__/
        │   ├── service.test.ts      # Unit tests
        │   └── service.int.test.ts  # Integration tests
        └── service.ts

Naming Conventions

  • Test files: {target-file-name}.test.ts
  • Integration test files: {target-file-name}.int.test.ts
  • Test suites: Names describing target features or situations
  • Test cases: Names describing expected behavior

Test Code Quality Rules

Recommended: Keep all tests always active

  • Merit: Guarantees test suite completeness
  • Practice: Fix problematic tests and activate them

Avoid: test.skip() or commenting out

  • Reason: Creates test gaps and incomplete quality checks
  • Solution: Completely delete unnecessary tests

Test Quality Criteria

Boundary and Error Case Coverage

Include boundary values and error cases alongside happy paths.

it('returns 0 for empty array', () => expect(calc([])).toBe(0))
it('throws on negative price', () => expect(() => calc([{price: -1}])).toThrow())

Literal Expected Values

Use literal values for assertions. Do not replicate implementation logic. Valid test: Expected value!= Mock return value (implementation transforms/processes data)

expect(calcTax(100)).toBe(10)  // not: 100 * TAX_RATE

Result-Based Verification

Verify results, not invocation order or count.

expect(mock).toHaveBeenCalledWith('a')  // not: toHaveBeenNthCalledWith

Meaningful Assertions

Each test must include at least one verification.

it('creates user', async () => {
  const user = await createUser({name: 'test'})
  expect(user.id).toBeDefined()
})

Appropriate Mock Scope

Mock only direct external I/O dependencies. Use real implementations for indirect dependencies.

vi.mock('./database')  // external I/O only

Property-based Testing (fast-check)

Use fast-check when verifying invariants or properties.

import fc from 'fast-check'

it('reverses twice equals original', () => {
  fc.assert(fc.property(fc.array(fc.integer()), (arr) => {
    return JSON.stringify(arr.reverse().reverse()) === JSON.stringify(arr)
  }))
})

Usage condition: Use when Property annotations are assigned to ACs in Design Doc.

Mock Type Safety Enforcement

Minimal Type Definition Requirements

// Only required parts
type TestRepo = Pick<Repository, 'find' | 'save'>
const mock: TestRepo = { find: vi.fn(), save: vi.fn() }

// Only when absolutely necessary, with clear justification
const sdkMock = {
  call: vi.fn()
} as unknown as ExternalSDK // Complex external SDK type structure

Basic Vitest Example

import { describe, it, expect, vi } from 'vitest'

vi.mock('./userService', () => ({
  getUserById: vi.fn(),
  updateUser: vi.fn()
}))

describe('ComponentName', () => {
  it('should follow AAA pattern', () => {
    const input = 'test'
    const result = someFunction(input)
    expect(result).toBe('expected')
  })
})

平台分布

Codex

36.81%
按下载量换算23

Claude

30.03%
按下载量换算19

Cursor

17.63%
按下载量换算11

Gemini CLI

9.41%
按下载量换算6

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

通过

权限和风险

需要联网

该 Skill 可能需要联网访问来源站点、仓库或外部 API;具体网络访问范围需要结合源码和 README 复核。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。目前只有一个公开来源,建议同时核对源仓库。

继续浏览同类 Skills