rails-testing
Skill644 starsChanged 10 months agoMITView on GitHub
Help with Rails testing including unit tests, integration tests, fixtures, and debugging test failures. Use when working on tests or debugging test issues.
We split this skill into the rules it gives an agent
22 rules. About 0 are common, 13 are distinctive, and 9 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈13
Distinctive · estimate
This author's own choices. Worth a look.
9
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 10
When helping with Rails testing:
- Very specific: line 13
Check existing tests in test/ directory to understand project conventions
- Distinctive: line 14
Look for test patterns in similar files (models, controllers, etc.)
- Very specific: line 18
Run all tests: bin/rails test
- Very specific: line 19
Run specific file: bin/rails test test/models/user_test.rb
- Very specific: line 20
Run specific test: bin/rails test test/models/user_test.rb:5 (line number)
- Very specific: line 21
Run with verbose output: bin/rails test -v
- Very specific: line 22
Use --fail-fast to stop on first failure: bin/rails test --fail-fast
- Distinctive: line 25
Models: Test business logic, validations, associations
- Distinctive: line 26
Controllers: Test request/response, status codes, redirects, instance variables
- Distinctive: line 27
Integration Tests: Test full workflows across multiple components
- Distinctive: line 28
Fixtures: Use for test data setup
- Very specific: line 31
Use descriptive test names: test_should_create_valid_user
- Distinctive: line 32
Test both success and failure cases
- Distinctive: line 33
Keep tests focused and isolated
- Distinctive: line 34
Use fixtures for shared test data
- Distinctive: line 38
Read error messages carefully - they usually point to the issue
- Distinctive: line 39
Check if test data is set up correctly (fixtures, setup methods)
- Distinctive: line 40
Verify assertions match the actual behavior
- Very specific: line 41
Use puts or p to inspect values
- Distinctive: line 42
Check test isolation - tests shouldn't depend on each other
- Very specific: line 47
Check test/fixtures/ for test data
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Rails Testing
Instructions
When helping with Rails testing:
- Understand the test structure
- Check existing tests in
test/directory to understand project conventions - Look for test patterns in similar files (models, controllers, etc.)
- Respect the project's test organization and naming conventions
- Check existing tests in
- Running tests
- Run all tests:
bin/rails test - Run specific file:
bin/rails test test/models/user_test.rb - Run specific test:
bin/rails test test/models/user_test.rb:5(line number) - Run with verbose output:
bin/rails test -v - Use
--fail-fastto stop on first failure:bin/rails test --fail-fast
- Run all tests:
- Test types in Rails
- Models: Test business logic, validations, associations
- Controllers: Test request/response, status codes, redirects, instance variables
- Integration Tests: Test full workflows across multiple components
- Fixtures: Use for test data setup
- Writing effective tests
- Use descriptive test names:
test_should_create_valid_user - Test both success and failure cases
- Keep tests focused and isolated
- Use fixtures for shared test data
- Clean up side effects after tests
- Use descriptive test names:
- Debugging test failures
- Read error messages carefully - they usually point to the issue
- Check if test data is set up correctly (fixtures, setup methods)
- Verify assertions match the actual behavior
- Use
putsorpto inspect values - Check test isolation - tests shouldn't depend on each other
- Test database
- Rails uses a separate test database
- Run migrations:
bin/rails db:test:prepare - Check
test/fixtures/for test data
Examples
When user asks: "How do I test this model?"
→ Create a model test in test/models/ following existing patterns, test validations and associations
When user asks: "Why is this test failing?" → Analyze the error, check test data setup, verify assertions, suggest fixes
When user asks: "Add tests for this controller"
→ Create controller tests in test/controllers/, test CRUD actions and edge cases
When user asks: "How do I set up test data?"
→ Suggest fixtures in test/fixtures/ or setup methods in the test file
Other versions2 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 2
- marckohlbrugge/unofficial-37signals-coding-style-guide★ 724same name
- mickzijdel/rails-toolkit★ 1same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository5 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- e2e-testingSkill
- seed-packsSkill
- theme-creationSkill
- theme-evaluationSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

