Service Unit Test Writer

Identify:

• The service interface and its method signatures.
• The concrete struct and its dependency fields injected via constructor.
• All exported error variables (e.g., ErrUserIDRequired).
• All validation branches that short-circuit before calling any dependency.

Step 2 — Read the port interfaces

Read internal/core/ports/repository.go.

For each dependency used by the service, note:

• The interface name (e.g., UserRepository).
• The methods it exposes and their signatures.

Step 3 — Check for existing mocks

Check internal/core/ports/ports_mocks/ for a generated mock file matching each required dependency interface.

• If a mock file exists, proceed to Step 4.

• If a mock file is missing, run:

  go generate ./internal/core/ports/...
  

  Confirm the mock file was created before proceeding.

Step 4 — Read the domain types

Read internal/core/domain/ files for any domain structs returned or accepted by the service methods under test. Note field names and types.

Step 5 — Determine test cases

For each method under test, define test cases covering:

1. Happy path — valid inputs, dependency returns expected data, service returns it unchanged.
2. Dependency error path — dependency returns an error, service propagates it.
3. Validation / short-circuit paths — invalid inputs (empty string, blank string, nil, zero value) that cause the service to return an error without calling the dependency.
4. Multi-dependency paths (if applicable) — when a method calls more than one dependency method, include cases where early calls succeed but later ones fail.

Step 6 — Write the test file

Write internal/core/services/<service_name>_test.go.

Follow all conventions below.

Step 7 — Run go test

Run:

go test ./internal/core/services/... -v -run Test

If the tests fail, diagnose and fix. Repeat until all tests pass.

Naming Conventions

<depName> is the variable name of the dependency in the service struct (e.g., userRepo, mailer, cache). It is not always a repository — use the actual dependency name.

Do not use generic field names like name, input, result, or error.

Test File Template

Use this template as the structural pattern. Replace all <...> placeholders with values specific to the service under test.

Key structural rules:

• t.Parallel() on both the top-level test and each sub-test.
• One Test<MethodName> function per service method; all cases live inside it.
• Mock setup (On(...)) is gated by the shouldCall* flag.
• Use require.Error / require.NoError before assert.* so the test stops early on unexpected nil/non-nil errors.
• Use AssertNumberOfCalls when the method should be called; use AssertNotCalled otherwise.
• For methods with multiple dependency calls, add a separate block of fields and setup/assertion per call.

Multi-Dependency Method Pattern

When a service method calls more than one dependency, or calls the same dependency multiple times, add explicit fields for each call:

// fields
firstDep<MethodName>Resp   <Type>
firstDep<MethodName>Err    error
shouldCallFirstDep<MethodName> bool
expectedFirstDep<MethodName>CallCount int

secondDep<MethodName>Resp   <Type>
secondDep<MethodName>Err    error
shouldCallSecondDep<MethodName> bool
expectedSecondDep<MethodName>CallCount int

Set up and assert each independently inside the test loop.

Important Constraints

• Never write tests for adapters (HTTP, SQLite). Those are integration tests.
• Never import the adapter packages from a service test.
• Never define mocks manually; always use the generated mocks from ports_mocks/.
• Never set a fixed coverage percentage target; focus on critical paths and edge cases.
• Keep test logic inside the table loop — avoid large helper functions unless multiple test functions share non-trivial setup.
• Do not skip the go test verification step.