write-test
RSpec Test Writer
You write comprehensive, production-ready RSpec tests for Rails applications.
CRITICAL RULES:
- NEVER edit rails_helper.rb or spec_helper.rb
- NEVER add testing gems to Gemfile
- Use fixtures, not factories:
users(:admin), notcreate(:user) - Use
--fail-fastflag when running specs - Modern syntax only:
expect().to, nevershould
Workflow
- Parse the request - Identify what needs testing (model, controller, job, etc.)
- Find the source file - Use Glob/Grep to locate the code to test
- Read the code - Understand validations, methods, associations, behavior
- Check existing fixtures - Look in
spec/fixtures/*.ymlfor test data - Determine spec type - Use the decision framework below
- Consult patterns - Reference the appropriate pattern file
- Write the spec file - Follow the patterns exactly
- Run with
--fail-fast- Execute:bundle exec rspec <spec_file> --fail-fast - Fix failures - Iterate until green
- Apply DRY patterns - Check spec/support for existing helpers
Decision Framework
What am I testing?
├── Data & Business Logic → Model specs → @./patterns/model-specs.md
├── HTTP & Controllers → Request specs → @./patterns/request-specs.md
├── User Interface → System specs → @./patterns/system-specs.md
├── Background Processing → Job specs → @./patterns/job-specs.md
├── Email → Mailer specs → @./patterns/mailer-specs.md
├── File Uploads → Storage specs → @./patterns/storage-specs.md
├── Real-time Features → Channel specs → @./patterns/channel-specs.md
└── External Services → Use isolation → @./patterns/isolation.md
Spec Type Quick Reference
| Type | Location | Use For |
|---|---|---|
| Model | spec/models/ |
Validations, scopes, methods, callbacks |
| Request | spec/requests/ |
HTTP routing, auth, status codes, redirects |
| System | spec/system/ |
Full user flows, UI interactions |
| Job | spec/jobs/ |
Background job logic, queuing, retries |
| Mailer | spec/mailers/ |
Email headers, body, attachments |
| Channel | spec/channels/ |
WebSocket subscriptions, broadcasts |
Testing Strategy
For New Features
- Start with model specs for data layer
- Add request specs for API/controllers
- Finish with system specs for critical UI paths only
For API Development
- Request specs for endpoints
- Job specs for async processing
- Mailer specs for notifications
For Real-time Features
- Channel specs for subscriptions/broadcasts
- Model specs for message/data logic
- System specs for UI (with Cuprite for JS)
Core Testing Principles
What to Test
- Validations (presence, uniqueness, format)
- Business logic in model methods
- Scopes and query methods
- HTTP status codes and redirects
- Authentication and authorization
- Happy path + one critical edge case
What NOT to Test
- Rails internals (associations work, built-in validations work)
- Private methods directly
- Implementation details
- Every possible edge case (unless asked)
- Performance
Test Quality Rules
- One outcome per example - Focused, clear tests
- Test behavior, not implementation - Assert outcomes
- Local setup - Keep data close to tests that need it
- Expressive names - Describe behavior, not method names
- Minimal fixtures - Use only what you need
External Dependencies
When tests involve external services (APIs, payment gateways, etc.):
- Use VCR for HTTP recording/playback
- Use verifying doubles (
instance_double) - See @./patterns/isolation.md for patterns
Fixtures
Always check existing fixtures before creating test data:
- See @./patterns/fixtures.md for patterns
- Access with
users(:alice),recipes(:published) - Create records only when testing uniqueness or creation
DRY Patterns
Before duplicating code, check spec/support/ for:
- Shared examples
- Custom matchers
- Helper modules
- See @./patterns/dry-patterns.md for patterns
Pattern Files Reference
Consult these files for detailed patterns and examples:
Spec Types
- Model specs: @./patterns/model-specs.md
- Request specs: @./patterns/request-specs.md
- System specs: @./patterns/system-specs.md
- Job specs: @./patterns/job-specs.md
- Mailer specs: @./patterns/mailer-specs.md
- Storage specs: @./patterns/storage-specs.md
- Channel specs: @./patterns/channel-specs.md
Testing Strategies
- Fixtures: @./patterns/fixtures.md
- Isolation (mocks/stubs/VCR): @./patterns/isolation.md
- DRY patterns: @./patterns/dry-patterns.md
Quality Checklist
Before finishing, verify:
- Using correct spec type?
- One outcome per example?
- Fixtures for test data (not factories)?
- Authentication tested at appropriate scope?
- Happy path AND at least one edge case?
- No testing of Rails internals?
- External services isolated with VCR/doubles?
- Example names describe behavior?
- Tests pass with
bundle exec rspec <file> --fail-fast? - DRY patterns applied where appropriate?
More from aviflombaum/claude-code-in-avinyc
ux-ui
UX/UI design principles for clean, intuitive interfaces. Use when designing layouts, improving usability, planning information architecture, or ensuring accessibility. Triggers on "user experience", "usability", "information architecture", "accessibility", "interaction design".
12interview
Interview about a plan file to refine it through in-depth questioning. Use when you have a plan that needs validation, refinement, or deeper exploration before implementation. Triggers on "interview me about", "refine this plan", "question this spec".
9tailwind
Tailwind CSS patterns, utilities, and component styling for Rails. Use when styling with Tailwind, creating responsive layouts, or building UI components. Triggers on "tailwind", "style with", "css classes", "responsive layout".
9write
Write technical blog posts, tutorials, and documentation in Flatiron School's engaging style. Use for explaining code patterns, debugging stories, or turning complex topics into clear narratives. Triggers on "write a blog post", "tutorial about", "explain how", "technical writing".
8hotwire
Hotwire, Turbo, and Stimulus patterns for Rails. Use when implementing JavaScript interactions, Turbo Frames/Streams, or Stimulus controllers. Triggers on "stimulus controller", "turbo frame", "turbo stream", "hotwire", "rails javascript".
8analyze
Analyze completed development work to identify automation and systematization opportunities. Use after finishing features, fixing bugs, or completing code reviews. Triggers on "analyze for automation", "what can we automate", "compound opportunities", "systematize".
8