JotJunior/cstk/plugins/cstk-language-go/skills/go-add-test/SKILL.md
go-add-test
Add unit/integration tests to a GOB Go microservice following established project patterns. Triggers: "add test", "add tests", "criar teste", "novo teste", "test coverage", "testar", "write tests for", "escrever testes para".
- Source repository stars
- 22
- Declared platforms
- 0
- Static risk flags
- 1
- Last source update
- 2026-08-24
- Source checked
- 2026-08-25
Decision brief
What it does: where it fits
Add unit/integration tests to a GOB Go microservice following established project patterns.
Not for
- Tasks that require unconfirmed production actions or broad system permissions.
- Environments where the pinned source and install steps cannot be inspected.
Compatibility matrix
Platform support, with evidence labels
| Platform | Status | Evidence | What to check |
|---|---|---|---|
| Codex | Not declared | No explicit evidence | Portability before use |
| Claude Code | Not declared | No explicit evidence | Portability before use |
| Cursor | Not declared | No explicit evidence | Portability before use |
| Gemini CLI | Not declared | No explicit evidence | Portability before use |
Installation
Inspect first. Install second.
The source command is displayed only when detected. A safe inspection prompt is always available so your agent can explain every action before execution.
npx skills add https://github.com/JotJunior/cstk --skill "plugins/cstk-language-go/skills/go-add-test"Inspect the Agent Skill "go-add-test" from https://github.com/JotJunior/cstk/blob/d1b28a511642ec12e088ed01df11d8ee9eb8bc05/plugins/cstk-language-go/skills/go-add-test/SKILL.md at commit d1b28a511642ec12e088ed01df11d8ee9eb8bc05. List every install step, command, network request, credential, file read/write, external action, and rollback step. Explain whether it fits my task. Do not install or execute anything until I approve.
Workflow
What the source asks the agent to do
- 01
Instructions
You generate Go tests for GOB microservices following the MockFunc pattern established in gob-member-service and gob-auth-service.
Service: which service in services/ (e.g., gob-process-service)Layer: which layer to test: domain, service, handler, repository, consumerScope: specific file/method or entire layer - 02
Step 1: Identify Target
Parse the user request to determine: - Service: which service in services/ (e.g., gob-process-service) - Layer: which layer to test: domain, service, handler, repository, consumer - Scope: specific file/method or entire layer
Service: which service in services/ (e.g., gob-process-service)Layer: which layer to test: domain, service, handler, repository, consumerScope: specific file/method or entire layer - 03
Step 2: Pre-flight Reads
Before writing ANY test code, read these files in the target service:
Repository interfaces — internal/repository/repository.go or similar interface filesThese define the methods you need to mockTarget source file — the file being tested (e.g., internal/service/memberservice.go) - 04
Step 3: Generate Mocks (if mockstest.go doesn't exist)
Create mockstest.go in the same package as the tests. Use the MockFunc pattern:
One MockXxxRepository struct per repository interfaceField name = method name + Func suffixSafe defaults: return nil, nil for pointer returns, nil for error-only returns - 05
Step 4: Generate Setup Helper
Create a setup function that wires the service with all mock dependencies:
Return the service AND all individual mock repos (so tests can configure Func fields)Match the real constructor — check NewXxxService() signatureIf the service takes a config, create a testConfig() helper too
Permission review
Static risk signals and limitations
Writes files
The documentation asks the agent to create, modify, or delete local files.
t.Error("Create() expected error when repo fails")Evidence record
Why each signal appears
| Signal | Value | Evidence type | Meaning |
|---|---|---|---|
| Quality score | 96/100 | Computed | Documentation, specificity, maintenance, and trust rules |
| Repository stars | 22 | Source | Repository attention, not individual Skill quality |
| Compatibility | 0 platforms | Source | Declared in the catalog source record |
| Usage guide | automated source guide | Editorial | Generated or reviewed according to the visible evidence level |
Pinned source
Provenance and original SKILL.md
- Repository
- JotJunior/cstk
- Skill path
- plugins/cstk-language-go/skills/go-add-test/SKILL.md
- Commit
- d1b28a511642ec12e088ed01df11d8ee9eb8bc05
- License
- MIT
- Collected
- 2026-08-25
- Default branch
- main
View the original SKILL.md
go-add-test
Add unit/integration tests to a GOB Go microservice following established project patterns.
Triggers
- "add test", "add tests", "criar teste", "novo teste", "test coverage", "testar"
- "write tests for", "escrever testes para"
- Examples: "add tests for process-service service layer", "criar testes de domain para bulletin-service"
Instructions
You generate Go tests for GOB microservices following the MockFunc pattern established in gob-member-service and gob-auth-service.
Step 1: Identify Target
Parse the user request to determine:
- Service: which service in
services/(e.g.,gob-process-service) - Layer: which layer to test:
domain,service,handler,repository,consumer - Scope: specific file/method or entire layer
If not specified, ask the user.
Step 2: Pre-flight Reads
Before writing ANY test code, read these files in the target service:
- Repository interfaces —
internal/repository/repository.goor similar interface files- These define the methods you need to mock
- Target source file — the file being tested (e.g.,
internal/service/member_service.go)- Understand every method signature, dependencies, and error paths
- Domain structs —
internal/domain/*.go- Needed for creating test fixtures
- Existing tests — any
*_test.gofiles in the target package- Follow existing patterns if tests already exist
- DTO structs —
internal/dto/dto.goif testing service/handler layer- Request/response types used by the methods
Step 3: Generate Mocks (if mocks_test.go doesn't exist)
Create mocks_test.go in the same package as the tests. Use the MockFunc pattern:
package service
import (
"context"
"github.com/google/uuid"
"github.com/gob/{service}/internal/domain"
)
// --- MockXxxRepository ---
type MockXxxRepository struct {
FindByIDFunc func(ctx context.Context, id uuid.UUID) (*domain.Xxx, error)
CreateFunc func(ctx context.Context, entity *domain.Xxx) error
UpdateFunc func(ctx context.Context, entity *domain.Xxx) error
DeleteFunc func(ctx context.Context, id uuid.UUID) error
ListFunc func(ctx context.Context, limit, offset int) ([]*domain.Xxx, int, error)
// Add one field per interface method
}
func (m *MockXxxRepository) FindByID(ctx context.Context, id uuid.UUID) (*domain.Xxx, error) {
if m.FindByIDFunc != nil {
return m.FindByIDFunc(ctx, id)
}
return nil, nil
}
func (m *MockXxxRepository) Create(ctx context.Context, entity *domain.Xxx) error {
if m.CreateFunc != nil {
return m.CreateFunc(ctx, entity)
}
return nil
}
// ... implement ALL interface methods with nil-check + safe default
Rules for mocks:
- One
MockXxxRepositorystruct per repository interface - Field name = method name +
Funcsuffix - Safe defaults: return
nil, nilfor pointer returns,nilfor error-only returns - Mocks live in
mocks_test.goin the SAME package (not a separate mocks directory) - Build tag: none needed (they're
_test.gofiles)
Step 4: Generate Setup Helper
Create a setup function that wires the service with all mock dependencies:
func setupXxxService() (*XxxService, *MockAaaRepository, *MockBbbRepository) {
aaaRepo := &MockAaaRepository{}
bbbRepo := &MockBbbRepository{}
// Match the actual constructor signature
service := NewXxxService(aaaRepo, bbbRepo)
// OR if the service uses a Repositories struct:
// repos := &Repositories{aaa: aaaRepo, bbb: bbbRepo}
// service := NewXxxService(repos)
return service, aaaRepo, bbbRepo
}
Rules:
- Return the service AND all individual mock repos (so tests can configure Func fields)
- Match the real constructor — check
NewXxxService()signature - If the service takes a config, create a
testConfig()helper too
Step 5: Generate Tests
Domain Tests (internal/domain/*_test.go)
Pure unit tests — no mocks needed:
func TestXxx_MethodName(t *testing.T) {
tests := []struct {
name string
// input fields
wantErr error
}{
{
name: "valid case",
wantErr: nil,
},
{
name: "invalid - reason",
wantErr: ErrSpecificError,
},
}
for _, tt := range tests {
t.Run(tt.name, func(t *testing.T) {
entity := &Xxx{/* fields */}
err := entity.MethodName()
if tt.wantErr != nil {
if err != tt.wantErr {
t.Errorf("MethodName() error = %v, want %v", err, tt.wantErr)
}
return
}
if err != nil {
t.Errorf("MethodName() unexpected error: %v", err)
}
})
}
}
Service Tests (internal/service/*_test.go)
func TestXxxService_Create(t *testing.T) {
service, xxxRepo, _ := setupXxxService()
ctx := context.Background()
t.Run("success", func(t *testing.T) {
xxxRepo.CreateFunc = func(ctx context.Context, entity *domain.Xxx) error {
return nil
}
req := &dto.CreateXxxRequest{
Name: "Test",
}
result, err := service.Create(ctx, req)
if err != nil {
t.Fatalf("Create() error = %v", err)
}
if result.Name != "Test" {
t.Errorf("Create() Name = %v, want %v", result.Name, "Test")
}
})
t.Run("validation error - empty name", func(t *testing.T) {
req := &dto.CreateXxxRequest{
Name: "",
}
_, err := service.Create(ctx, req)
if err == nil {
t.Error("Create() expected validation error")
}
})
t.Run("repository error", func(t *testing.T) {
xxxRepo.CreateFunc = func(ctx context.Context, entity *domain.Xxx) error {
return errors.New("db connection failed")
}
req := &dto.CreateXxxRequest{
Name: "Test",
}
_, err := service.Create(ctx, req)
if err == nil {
t.Error("Create() expected error when repo fails")
}
})
}
Handler Tests (internal/handler/*_test.go)
func TestXxxHandler_Create(t *testing.T) {
app := fiber.New()
mockService := &MockXxxService{}
handler := NewXxxHandler(mockService)
app.Post("/xxx", handler.Create)
t.Run("success - 201", func(t *testing.T) {
mockService.CreateFunc = func(ctx context.Context, req *dto.CreateXxxRequest) (*dto.XxxResponse, error) {
return &dto.XxxResponse{ID: uuid.New(), Name: req.Name}, nil
}
body := `{"name": "Test"}`
req := httptest.NewRequest("POST", "/xxx", strings.NewReader(body))
req.Header.Set("Content-Type", "application/json")
resp, err := app.Test(req)
if err != nil {
t.Fatalf("app.Test() error = %v", err)
}
if resp.StatusCode != fiber.StatusCreated {
t.Errorf("status = %d, want %d", resp.StatusCode, fiber.StatusCreated)
}
})
t.Run("bad request - invalid JSON", func(t *testing.T) {
req := httptest.NewRequest("POST", "/xxx", strings.NewReader("{invalid"))
req.Header.Set("Content-Type", "application/json")
resp, err := app.Test(req)
if err != nil {
t.Fatalf("app.Test() error = %v", err)
}
if resp.StatusCode != fiber.StatusBadRequest {
t.Errorf("status = %d, want %d", resp.StatusCode, fiber.StatusBadRequest)
}
})
}
Consumer/Messaging Tests (internal/messaging/*_test.go)
func TestProcessHandler_HandleEvent(t *testing.T) {
mockService := &MockXxxService{}
handler := NewProcessHandler(mockService)
t.Run("process.created event", func(t *testing.T) {
var called bool
mockService.HandleProcessCreatedFunc = func(ctx context.Context, event *domain.ProcessEvent) error {
called = true
return nil
}
payload := []byte(`{"process_id": "` + uuid.New().String() + `", "action": "created"}`)
err := handler.Handle(context.Background(), payload)
if err != nil {
t.Fatalf("Handle() error = %v", err)
}
if !called {
t.Error("HandleProcessCreated was not called")
}
})
}
Step 6: Test Coverage Cases
For EVERY method tested, always include these scenarios:
- Happy path — valid input, expected output
- Validation errors — missing required fields, invalid values
- Not found — entity doesn't exist (return nil from repo)
- Repository/dependency errors — database failures, external service failures
- Authorization (if applicable) — wrong scope, missing permissions
- Edge cases — empty lists, zero values, UUID nil, boundary values
Conventions
| Rule | Value |
|---|---|
| Test framework | Standard testing package only (NO testify) |
| Mock library | Hand-written MockFunc pattern (NO mockgen, gomock) |
| Test file location | Same package as source (_test suffix) |
| Mock file | mocks_test.go per package |
| Naming | Test{Type}_{Method} (e.g., TestMemberService_Create) |
| Structure | Table-driven with t.Run() subtests |
| Assertions | if got != want { t.Errorf(...) } |
| Fatal vs Error | t.Fatalf for setup failures, t.Errorf for assertion failures |
| Context | Always use context.Background() |
| UUIDs | Use uuid.New() for test IDs |
| Time | Use time.Now() or fixed time.Date() for deterministic tests |
Anti-patterns to AVOID
- Do NOT use
github.com/stretchr/testify - Do NOT generate mocks with
mockgenor any code generator - Do NOT put mocks in a separate
mocks/directory - Do NOT use
reflect.DeepEqual— compare fields individually - Do NOT test private functions directly — test through public API
- Do NOT create
TestMainunless writing integration tests with DB - Do NOT add build tags for unit tests
Verification
After generating tests, run:
cd services/{service-name} && go test ./internal/{layer}/... -v -count=1
If compilation fails, fix immediately. Common issues:
- Missing mock method (interface not fully implemented)
- Wrong import path
- Struct field mismatch (check domain structs again)
- Constructor signature changed
Reference Services
- Best example:
services/gob-member-service/internal/service/— full MockFunc pattern, setup helpers, table-driven tests - Auth patterns:
services/gob-auth-service/internal/service/— in-memory store mocks, complex scenario tests - Domain only:
services/gob-election-service/internal/domain/— pure domain validation tests
Frequently asked questions
What to verify before installation and use
What does the go-add-test source document cover?
Add unit/integration tests to a GOB Go microservice following established project patterns.
How do I install go-add-test?
The source record exposes this install command: npx skills add https://github.com/JotJunior/cstk --skill "plugins/cstk-language-go/skills/go-add-test". Inspect the command and pinned source before running it.
Which permission-related actions were detected?
Static rules flagged write-files in the source; the page lists the matching lines and excerpts.
Alternatives
Compare before choosing
coreyhaines31/marketingskills
ab-testing
When the user wants to plan, design, or implement an A/B test or experiment, or build a growth experimentation program. Also use when the user mentions "A/B test," "split test," "experiment," "test this change," "variant copy," "multivariate test," "hypothesis," "should I test this," "which version is better," "test two versions," "statistical significance," "how long should I run this test," "growth experiments," "experiment velocity," "experiment backlog," "ICE score," "experimentation program
garrytan/gbrain
bulk-ingestion
End-to-end discipline for turning any large data source (audio libraries, email takeouts, document corpora, chat exports, API dumps) into brain pages at scale. The lifecycle spine: SCHEMA → ACCESS → TRIAL → EVALUATE → IMPROVE → CODIFY → TEST → SKILLIFY → BULK → MONITOR. State is tracked in a durable JSON manifest (see MANIFEST-PATTERN.md) so any crash, session boundary, or subagent fan-out resumes from ground truth instead of memory.
alirezarezvani/claude-skills
app-store-optimization
App Store Optimization (ASO) toolkit for researching keywords, analyzing competitor rankings, generating metadata suggestions, and improving app visibility on Apple App Store and Google Play Store. Use when the user asks about ASO, app store rankings, app metadata, app titles and descriptions, app store listings, app visibility, or mobile app marketing on iOS or Android. Supports keyword research and scoring, competitor keyword analysis, metadata optimization, A/B test planning, launch checklist
dotnet/skills
migrate-vstest-to-mtp
Migrates .NET test projects from VSTest to Microsoft.Testing.Platform (MTP). Use when user asks to "migrate to MTP", "switch from VSTest", "enable Microsoft.Testing.Platform", "use MTP runner", set OutputType=Exe only for test projects in Directory.Build.props, or mentions EnableMSTestRunner, EnableNUnitRunner, or UseMicrosoftTestingPlatformRunner. USE FOR: MTP behavioral differences vs VSTest (exit code 8, zero tests discovered, --ignore-exit-code, TESTINGPLATFORM_EXITCODE_IGNORE); centralizing