Source profileQuality 96/100

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.

Best for

    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

    PlatformStatusEvidenceWhat to check
    CodexNot declaredNo explicit evidencePortability before use
    Claude CodeNot declaredNo explicit evidencePortability before use
    CursorNot declaredNo explicit evidencePortability before use
    Gemini CLINot declaredNo explicit evidencePortability before use
    Open the compatibility checker

    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.

    Source-detected install commandSource
    npx skills add https://github.com/JotJunior/cstk --skill "plugins/cstk-language-go/skills/go-add-test"
    Safe inspection promptEditorial

    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

    1. 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
    2. 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
    3. 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)
    4. 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
    5. 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

    medium · line 202

    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

    EvidenceSourceComputedTestedEditorial
    SignalValueEvidence typeMeaning
    Quality score96/100ComputedDocumentation, specificity, maintenance, and trust rules
    Repository stars22SourceRepository attention, not individual Skill quality
    Compatibility0 platformsSourceDeclared in the catalog source record
    Usage guideautomated source guideEditorialGenerated 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:

    1. Repository interfacesinternal/repository/repository.go or similar interface files
      • These define the methods you need to mock
    2. Target source file — the file being tested (e.g., internal/service/member_service.go)
      • Understand every method signature, dependencies, and error paths
    3. Domain structsinternal/domain/*.go
      • Needed for creating test fixtures
    4. Existing tests — any *_test.go files in the target package
      • Follow existing patterns if tests already exist
    5. DTO structsinternal/dto/dto.go if 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 MockXxxRepository struct per repository interface
    • Field name = method name + Func suffix
    • Safe defaults: return nil, nil for pointer returns, nil for error-only returns
    • Mocks live in mocks_test.go in the SAME package (not a separate mocks directory)
    • Build tag: none needed (they're _test.go files)

    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:

    1. Happy path — valid input, expected output
    2. Validation errors — missing required fields, invalid values
    3. Not found — entity doesn't exist (return nil from repo)
    4. Repository/dependency errors — database failures, external service failures
    5. Authorization (if applicable) — wrong scope, missing permissions
    6. Edge cases — empty lists, zero values, UUID nil, boundary values

    Conventions

    RuleValue
    Test frameworkStandard testing package only (NO testify)
    Mock libraryHand-written MockFunc pattern (NO mockgen, gomock)
    Test file locationSame package as source (_test suffix)
    Mock filemocks_test.go per package
    NamingTest{Type}_{Method} (e.g., TestMemberService_Create)
    StructureTable-driven with t.Run() subtests
    Assertionsif got != want { t.Errorf(...) }
    Fatal vs Errort.Fatalf for setup failures, t.Errorf for assertion failures
    ContextAlways use context.Background()
    UUIDsUse uuid.New() for test IDs
    TimeUse 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 mockgen or 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 TestMain unless 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

    Computed 10045,511

    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

    Computed 10029,034

    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.

    Computed 10024,921

    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

    Computed 1005,241

    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