3.4 KiB
3.4 KiB
description, argument-hint
| description | argument-hint |
|---|---|
| Get guidance on writing idiomatic bupkis assertions | [what-to-assert] |
Bupkis Assertion Guidance
Provide guidance on writing idiomatic assertions using the bupkis testing library.
Usage
/bupkis [optional: what you're trying to assert]
Arguments:
what-to-assert(optional): Describe what you're trying to test or assert
Instructions
When this command is invoked:
-
Load the bupkis assertion patterns skill from
skills/bupkis-assertion-patterns/SKILL.md -
If the user provided context, analyze their needs and:
- Identify which patterns from the skill apply to their situation
- Provide specific code examples using those patterns
- Explain why the recommended approach is better
- Show before/after comparisons from the skill when helpful
-
If no context was provided, offer to help by:
- Asking what they're trying to test or assert
- Listing common scenarios:
- Checking if properties exist on objects
- Verifying object structure and types
- Testing arrays or collections
- Validating promise behavior
- Type checking values
- Offering to show examples of specific patterns
-
Always emphasize key principles:
- Using semantic assertions over indirect checks
- Combining related checks with
to satisfy - Choosing positive assertions when possible (e.g.,
to be definedvsnot to be undefined) - Letting assertions imply related checks (e.g.,
to be an objectimplies non-null) - Using
expectAsyncfor promise-based assertions
Example Interactions
With context:
User: /bupkis checking if an object has multiple numeric properties
Agent: For checking multiple properties with specific types, use `to satisfy`
with nested `expect.it()` assertions:
✅ DO - concise, shows structure at a glance:
expect(state, 'to satisfy', {
filesCompleted: expect.it('to be a number'),
suitesCompleted: expect.it('to be a number'),
tasksCompleted: expect.it('to be a number'),
});
This is better than separate assertions because:
- Shows the expected structure clearly
- Better error messages show exactly which properties failed
- More maintainable - all related checks in one place
With specific code:
User: /bupkis
How can I improve this?
expect('filesCompleted' in state, 'to be truthy');
Agent: Instead of checking property existence with the `in` operator,
use the semantic `to have property` assertion:
✅ DO - clear, semantic assertion:
expect(state, 'to have property', 'filesCompleted');
This is clearer because it directly expresses your intent and provides
better error messages when the property is missing.
Without context:
User: /bupkis
Agent: I can help you write idiomatic bupkis assertions! What are you trying to test?
Common scenarios:
- Checking if properties exist on objects
- Verifying object structure and types
- Testing arrays or collections
- Validating promise behavior
- Type checking values
You can also paste your current test code and I'll suggest improvements,
or ask about a specific assertion pattern!