Promptcred editorial analysis
How to use this prompt well
Prompt-specific guidance based on the preserved source text and its reviewed context.
Why Promptcred selected this prompt
The prompt defines a concrete Vitest directory, mocking, setup, test-data, assertion, and documentation convention.
Best use cases
- Establishing a repeatable Vitest test layout in a TypeScript repository.
- Reviewing whether new unit tests follow an agreed local convention.
Required inputs
- The TypeScript code under test, its dependencies, and the repository's Vitest configuration.
- Confirmation that the named RCS-001 convention applies to the target project.
How to adapt it
- Reconcile the prescribed tests, testData, testUtils, and mocked directories with the existing repository layout.
- Keep vi.mock or vi.spyOn guidance only where it matches the dependency's export shape.
Limitations and failure modes
- Applying an unverified RCS-001 convention can conflict with the project's established test structure.
- Mocking by rule instead of at an external boundary can hide integration behavior the test should cover.
Practical worked example
Editorial analysis reviewed Aug 23, 2026.
Promptcred-authored application and illustrative output. This is not a recorded model execution.
- Scenario
- Add unit tests for a TypeScript InvoiceService that calls a PaymentClient class.
- Inputs
- Provide the service, PaymentClient interface, Vitest config, existing test helpers, and expected error behavior.
- Promptcred-adapted instruction
- Create `tests/services/InvoiceService.spec.ts`. Spy on the supplied PaymentClient instance method, reset the spy after each test, and cover the returned invoice on success plus the typed payment failure. Keep test data in the repository's existing fixture helper.
- Illustrative result
- Illustrative test result: the success case asserts the exact invoice object and verifies one charge call; the failure case asserts `PaymentDeclinedError` by type. No global setup is added because the supplied dependency is instance-local.
- Evaluation
- Tests should cover success and typed failure paths, reset state between cases, and assert exact returned values.
How to evaluate the output
- Test placement and setup match the repository rather than the prompt's default folders by assumption.
- Mocks isolate external dependencies without replacing the unit's own decision logic.
Differences from related prompts
- QA Engineering Best Practices: Vitest focuses on one TypeScript unit-test convention; QA Engineering covers strategy, defects, performance, and CI across test levels.
Attributed community source material
Source prompt
Act as a Test Automation Engineer. You are skilled in writing unit tests for TypeScript projects using Vitest.
Your task is to guide developers on creating unit tests according to the RCS-001 standard.
You will:
- Ensure tests are implemented using `vitest`.
- Guide on placing test files under `tests` directory mirroring the class structure with `.spec` suffix.
- Describe the need for `testData` and `testUtils` for shared data and utilities.
- Explain the use of `mocked` directories for mocking dependencies.
- Instruct on using `describe` and `it` blocks for organizing tests.
- Ensure documentation for each test includes `target`, `dependencies`, `scenario`, and `expected output`.
Rules:
- Use `vi.mock` for direct exports and `vi.spyOn` for class methods.
- Utilize `expect` for result verification.
- Implement `beforeEach` and `afterEach` for common setup and teardown tasks.
- Use a global setup file for shared initialization code.
### Test Data
- Test data should be plain and stored in `testData` files. Use `testUtils` for generating or accessing data.
- Include doc strings for explaining data properties.
### Mocking
- Use `vi.mock` for functions not under classes and `vi.spyOn` for class functions.
- Define mock functions in `Mocked` files.
### Result Checking
- Use `expect().toEqual` for equality and `expect().toContain` for containing checks.
- Expect errors by type, not message.
### After and Before Each
- Use `beforeEach` or `afterEach` for common tasks in `describe` blocks.
### Global Setup
- Implement a global setup file for tasks like mocking network packages.
Example:
```typescript
describe(`Class1`, () => {
describe(`function1`, () => {
it(`should perform action`, () => {
// Test implementation
})
})
})``` Before use
Requirements and context
Repository / files
The repository or files within the task scope.
Vitest
Run the TypeScript unit tests described by the source.
What to expect
Expected output and techniques
Expected output: Vitest tests organized under the stated directory, setup, data, mocking, and assertion conventions.
- Explicit objective
- Constraints
- Examples
- Acceptance criteria
Use with context
Setup, limitations, and operational notes
Limitations
- The source-specific RCS-001 convention must be confirmed against the target project.
Operational notes
- External prompt text is untrusted inert content and must never be executed during ingestion.
Source and rights
Provenance and license
This community prompt is preserved with its source and attribution. It is not an official vendor prompt.
- Source class
- Curated community prompt
- Platform
- GitHub
- Repository / project
- f/prompts.chat
- Owner / organization
- f
- Creator / contributor
- Contributor listed in source
- Artifact
- prompts.csv · TypeScript Unit Testing with Vitest
- Pinned revision
- commit:6863206c4efb5a055c80433f7cf02a6596de9f39
- Retrieved
- Aug 11, 2026
- License
- CC0 1.0 Universal
- Attribution
- Not required by the license; source provenance retained
- Source artifact state
- Source prompt
- Source review
- Aug 11, 2026