test-service
Skill26 starsChanged 4 months agoMITView on GitHub
Use when writing RSpec for a service object under spec/services/. Test the public .call contract. Trigger words: service spec, test service object, spec/services.
In this repository32 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- apply-code-conventionsSkill
- apply-stack-conventionsSkill
- code-reviewSkill
- create-engine-installerSkill
- create-engineSkill
- document-engineSkill
- extract-engineSkill
- generate-api-collectionSkill
- implement-authorizationSkill
- implement-background-jobSkill
- implement-graphqlSkill
- implement-hotwireSkill
- load-contextSkill
- optimize-performanceSkill
- plan-testsSkill
- rails-featureSkill
- rails-maintenanceSkill
- rails-reviewSkill
- refactor-codeSkill
- release-engineSkill
- review-architectureSkill
- review-engineSkill
- review-migrationSkill
- security-checkSkill
- seed-databaseSkill
- setup-environmentSkill
- test-engineSkill
- upgrade-engineSkill
- version-apiSkill
- write-testsSkill
The file
We split this skill into the rules it gives an agent
5 rules. About 0 are common, 1 is distinctive, and 4 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
4
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 88
Use instance_double for unit isolation:
- Very specific: line 98
Avoid class-level stubs: do not use allow(CarrierApi::Client).to receive(:notify) — always double the instance.
- Very specific: line 100
Use create for integration tests:
- Very specific: line 108
When testing API clients, use class: Hash with initialize_with to build hash-shaped response fixtures.
- Distinctive: line 154
When completing a service test, output MUST include:
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 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
Test Service
Quick Reference
| Aspect | Rule |
| File location | spec/services/module_name/service_spec.rb |
| Subject | subject(:service_call) { described_class.call(params) } |
| Unit isolation | instance_double for collaborators |
| Integration | create for DB-backed tests |
| Multi-assertion | aggregate_failures |
| State verification | change matchers |
| Time-dependent | travel_to |
| API responses | FactoryBot hash factories (class: Hash) |
HARD-GATE
DO NOT implement the service before step 1 is written and failing for the right reason.
1. WRITE: Write the spec (happy path + error cases + edge cases)
2. RUN: bundle exec rspec spec/services/your_service_spec.rb
3. VERIFY: Confirm failures are for the right reason (not a typo or missing factory)
4. FIX: Implement or fix until the spec passes
5. SUITE: bundle exec rspec spec/services/ — verify no regressionsCore Process
Spec Template
# frozen_string_literal: true
require 'spec_helper'
RSpec.describe ModuleName::MainService do
describe '.call' do
subject(:service_call) { described_class.call(params) }
let(:shelter) { create(:shelter, :with_animals) }
let(:params) do
{ shelter: { shelter_id: shelter.id }, items: %w[TAG001 TAG002] }
end
context 'when input is valid' do
before { create(:animal, tag_number: 'TAG001', shelter:) }
it 'returns success' do
expect(service_call[:success]).to be true
end
end
context 'when shelter is not found' do
let(:params) { super().merge(shelter: { shelter_id: 999_999 }) }
it 'returns error response' do
expect(service_call[:success]).to be false
end
end
context 'when input is blank' do
let(:params) { { shelter: { shelter_id: nil }, items: [] } }
it 'returns error response with meaningful message' do
aggregate_failures do
expect(service_call[:success]).to be false
expect(service_call[:errors]).not_to be_empty
end
end
end
end
endUse instance_double for unit isolation:
let(:client) { instance_double(Api::Client) }
before { allow(client).to receive(:execute_query).and_return(api_response) }CRITICAL — Collaborators MUST be stubbed via instance_double. Three patterns:
- Inject dependency: pass the double in params directly.
- Stub
.new:allow(CarrierApi::Client).to receive(:new).and_return(client)when the service instantiates internally. - Avoid class-level stubs: do not use
allow(CarrierApi::Client).to receive(:notify)— always double the instance.
Use create for integration tests:
let(:source_shelter) { create(:shelter, :with_animals) }FactoryBot Hash Factories for API Responses
When testing API clients, use class: Hash with initialize_with to build hash-shaped response fixtures. A minimal example:
FactoryBot.define do
factory :api_animal_response, class: Hash do
tag_number { 'TAG001' }
status { 'active' }
initialize_with { attributes.stringify_keys }
end
end
# In the spec:
let(:api_response) { build(:api_animal_response, tag_number: 'TAG002') }New Test File Checklist
subjectdefined for the main actioninstance_doublefor unit /createfor integration- Happy path for each public method
- Error and edge cases (blank input, invalid refs, failures)
- Partial success scenarios where relevant
shared_examplesfor repeated patternsaggregate_failuresfor multi-assertion testschangematchers for state verification
Common Mistakes
| Mistake | Correct approach |
| No error scenario tests | Always test failures alongside the happy path |
let! everywhere | Use let (lazy) unless the value is unconditionally required for setup |
| Huge factory setup | Keep factories minimal — only attributes the test requires |
| Spec breaks on refactor with unchanged behavior | Tests that break on refactoring are testing internals, not contracts |
Extended Resources (Progressive Disclosure)
Load these files only when their specific content is needed:
- PATTERNS.md — Use when you need the full pattern catalog and factory placement guidance
- assets/spec_examples.md — Use when you need additional worked examples beyond the spec template above
- assets/testing_checklist.md — Use when reviewing a completed service spec for completeness
Output Style
When completing a service test, output MUST include:
# Service Spec — [ServiceName]
## Spec File
- Path: spec/services/<module>/<service>_spec.rb
- Subject: `described_class.call(params)`
## Coverage
- Happy path: ✓ (<n> examples)
- Error cases: ✓ (<n> examples — list error classes/conditions)
- Edge cases: ✓ (<n> examples — blank input, boundary values)
- Isolation: instance_double for <collaborator list>
## TDD Gate
- RED: <failure message confirming missing behavior>
- GREEN: <all examples pass>
- Suite: <full spec/services/ suite status>Integration
| Skill | When to chain |
| write-tests | For general RSpec style and TDD discipline |
| create-service-object | For the service conventions being tested |
| integrate-api-client | For API client layer testing patterns |
| test-engine | When testing engine-specific services |
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
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.

