Get guidance on writing idiomatic bupkis assertions
Provides guidance on writing idiomatic assertions using the bupkis testing library.
/plugin marketplace add boneskull/claude-plugins/plugin install bupkis@boneskull-plugins[what-to-assert]Provide guidance on writing idiomatic assertions using the bupkis testing library.
/bupkis [optional: what you're trying to assert]
Arguments:
what-to-assert (optional): Describe what you're trying to test or assertWhen 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:
If no context was provided, offer to help by:
Always emphasize key principles:
to satisfyto be defined vs not to be undefined)to be an object implies non-null)expectAsync for promise-based assertionsWith 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!