Three Things, Tested Three Ways

The confusion comes from treating “the LLM feature” as one indivisible thing. It is three:

The first row is 90% of your code and needs no model at all. Get that boundary right and the rest is manageable.

Put an Interface in Front of the Model

Do not scatter client.Messages.New through your handlers. Define the narrowest interface your code actually needs and depend on that:

// Completer turns a prompt into text. It is deliberately narrow — narrower
// than the SDK — so tests can implement it in five lines.
type Completer interface {
    Complete(ctx context.Context, req Request) (Response, error)
}

type Request struct {
    System   string
    Messages []Message
    Tools    []Tool
}

type Response struct {
    Text       string
    ToolCalls  []ToolCall
    StopReason string
    Usage      Usage
}

This is just the dependency-inversion habit that makes any external service testable, and it earns its keep faster here than almost anywhere else. Two things fall out of it:

Your business logic never imports the SDK. It imports your Request and Response types. When the SDK’s union types change shape, one adapter file changes.

The fake is trivial. No HTTP, no fixtures, no mocking library:

type fakeCompleter struct {
    responses []Response
    err       error
    calls     []Request // recorded for assertions
}

func (f *fakeCompleter) Complete(_ context.Context, req Request) (Response, error) {
    f.calls = append(f.calls, req)
    if f.err != nil {
        return Response{}, f.err
    }
    if len(f.responses) == 0 {
        return Response{}, errors.New("fakeCompleter: no responses left")
    }
    resp := f.responses[0]
    f.responses = f.responses[1:]
    return resp, nil
}

Returning a queue rather than a single value is what lets you test multi-turn loops: the first call returns a tool request, the second returns the final answer.

Test the Loop, Not the Model

An agent loop has plenty of logic worth testing, none of which needs a model. Does it stop when it should? Does it return a result for every tool call? Does it hand a tool failure back rather than aborting?

func TestLoopReturnsResultForFailedTool(t *testing.T) {
    fake := &fakeCompleter{responses: []Response{
        {StopReason: "tool_use", ToolCalls: []ToolCall{
            {ID: "t1", Name: "lookup", Input: []byte(`{"id":"missing"}`)},
        }},
        {StopReason: "end_turn", Text: "I couldn't find that record."},
    }}

    agent := New(fake, map[string]ToolFunc{
        "lookup": func(context.Context, []byte) (string, error) {
            return "", errors.New("not found")
        },
    })

    got, err := agent.Run(context.Background(), "look up record missing")
    if err != nil {
        t.Fatalf("Run() error = %v, want nil", err)
    }
    if got != "I couldn't find that record." {
        t.Errorf("got %q", got)
    }

    // The failure must reach the model as a tool result, not abort the loop.
    second := fake.calls[1]
    result := findToolResult(t, second, "t1")
    if !result.IsError {
        t.Error("tool failure was not marked as an error result")
    }
}

That test catches a real bug — a loop that drops the failed call instead of reporting it — and runs in microseconds with no API key.

The same approach covers the rest of the loop’s contract — the invariants from the agent-loop article: that it stops at MaxIterations, that every tool_use block gets exactly one result, that results come back in one message. Table-driven tests fit this beautifully, since each case is just a different queue of canned responses.

Golden Files for Prompt Assembly

Prompt building is string manipulation, and it drifts. Someone adds a field, reorders a section, changes a heading — and unlike code, a prompt regression produces no compile error and no failing assertion, just slightly worse output that nobody attributes to the change.

Golden files make the diff visible in review:

var update = flag.Bool("update", false, "update golden files")

func TestBuildSystemPrompt(t *testing.T) {
    tests := []struct {
        name   string
        cfg    Config
        golden string
    }{
        {"default", Config{}, "system_default.txt"},
        {"with_tools", Config{Tools: allTools}, "system_with_tools.txt"},
        {"terse_mode", Config{Terse: true}, "system_terse.txt"},
    }

    for _, tt := range tests {
        t.Run(tt.name, func(t *testing.T) {
            got := BuildSystemPrompt(tt.cfg)
            path := filepath.Join("testdata", tt.golden)

            if *update {
                if err := os.WriteFile(path, []byte(got), 0o644); err != nil {
                    t.Fatal(err)
                }
                return
            }

            want, err := os.ReadFile(path)
            if err != nil {
                t.Fatal(err)
            }
            if diff := cmp.Diff(string(want), got); diff != "" {
                t.Errorf("prompt changed (-want +got):\n%s", diff)
            }
        })
    }
}

Run go test ./... -update to accept a change deliberately. The point is not that the golden file is correct — it is that changing it requires saying so out loud, in a diff a reviewer can read.

This also catches the caching bugs from the prompt caching article before they cost you anything. A golden test on the system prompt fails the moment somebody interpolates time.Now() into it, because the output differs on every run.

Which suggests a second, blunter test worth having:

func TestPromptAssemblyIsDeterministic(t *testing.T) {
    // Go randomises map iteration order, so a prompt built by ranging over a
    // map differs run to run — and silently never caches.
    first := BuildSystemPrompt(cfg)
    for i := 0; i < 20; i++ {
        if got := BuildSystemPrompt(cfg); got != first {
            t.Fatalf("prompt is not deterministic on run %d", i)
        }
    }
}

Twenty iterations is enough to make a randomised map order fail essentially every time.

Integration Tests, Behind a Build Tag

You do need a handful of tests that touch the real API — enough to catch an SDK upgrade that changed a union type, a model id that no longer resolves, or streaming that broke. But they cost money and need a key, so they must not run on every go test ./...:

//go:build integration

package llm_test

func TestStreamingReturnsCompleteMessage(t *testing.T) {
    if os.Getenv("ANTHROPIC_API_KEY") == "" {
        t.Skip("no API key; skipping integration test")
    }
    // ... real call, assert on shape rather than content
}

go test ./...                    # fast, free, no key
go test -tags=integration ./...  # the real thing, on demand

Assert on shape, never on wording. resp.Text being non-empty, StopReason being end_turn, Usage.OutputTokens being greater than zero, a streamed message accumulating to the same content as a non-streamed one. Those hold across model versions. “The answer contains the word Paris” does not, and a flaky test that fails once a month teaches your team to ignore failures.

There is a middle option that gets you a long way for free: point the SDK at a local httptest.Server via the ANTHROPIC_BASE_URL environment variable and serve canned JSON. That exercises the real SDK — its parsing, its retry behaviour, its streaming decoder — without a key or a bill. It is the closest analogue to what go-sqlmock does for the database layer: a real driver, a fake server.

It is also the only sane way to test the paths you cannot easily provoke on purpose:

// Rate limiting: does the caller back off, or hammer?
mux.HandleFunc("/v1/messages", func(w http.ResponseWriter, r *http.Request) {
    w.Header().Set("Retry-After", "1")
    w.WriteHeader(http.StatusTooManyRequests)
    fmt.Fprint(w, `{"type":"error","error":{"type":"rate_limit_error","message":"..."}}`)
})

Do the same for a 500, a connection dropped mid-stream, and a malformed body. Those are the failures that actually page you, and they are trivial to simulate and nearly impossible to trigger on demand against the real API.

The Refusal Case Nobody Tests

Worth its own paragraph because it is so easy to miss: a safety refusal comes back as HTTP 200 with StopReason set to refusal. Your error handling never fires. Code that goes from if err != nil straight to reading the first content block treats it as an empty answer.

func TestRefusalIsNotTreatedAsEmptyAnswer(t *testing.T) {
    fake := &fakeCompleter{responses: []Response{
        {StopReason: "refusal", Text: ""},
    }}

    _, err := New(fake, nil).Run(context.Background(), "...")
    if !errors.Is(err, ErrDeclined) {
        t.Errorf("got %v, want ErrDeclined", err)
    }
}

One line in the fake, and you have covered a branch most production code does not have at all. The sentinel-error pattern behind ErrDeclined is the one from error handling in Go.

Evals: For Quality, Not Correctness

Everything above tests whether your code is right. None of it tells you whether the answers are any good. That needs a different instrument, and the mistake is trying to force it into go test.

An eval is a fixed set of inputs, run against the real model, scored rather than asserted:

//go:build eval

func TestClassificationAccuracy(t *testing.T) {
    cases := loadEvalCases(t, "testdata/eval/classification.jsonl")

    var correct int
    for _, c := range cases {
        got, err := classify(context.Background(), realClient, c.Input)
        if err != nil {
            t.Fatal(err)
        }
        if got == c.Want {
            correct++
        } else {
            t.Logf("MISS: input=%q got=%q want=%q", c.Input, got, c.Want)
        }
    }

    accuracy := float64(correct) / float64(len(cases))
    t.Logf("accuracy: %.1f%% (%d/%d)", accuracy*100, correct, len(cases))

    // A floor, not an equality check. Below this, something regressed.
    if accuracy < 0.90 {
        t.Errorf("accuracy %.1f%% below the 90%% floor", accuracy*100)
    }
}

Two things make this useful rather than annoying. The threshold is a floor, not a target — you are detecting regression, not demanding perfection. And the misses get logged, because the list of what it got wrong is the actual output; the pass/fail is almost incidental.

Run evals when you change a prompt, a model, or an effort setting — not on every commit. They cost money and take minutes.

What Not to Do

Do not assert on model wording. strings.Contains(resp, "Paris") passes today and fails after a model update that phrases it differently. It is not testing your code.

Do not set temperature to zero and call it deterministic. Sampling parameters are not even accepted on current models, and identical output was never guaranteed regardless.

Do not mock the SDK’s types. Mocking anthropic.Message and its union blocks is a lot of work to test the adapter you wrote to avoid exactly that. Fake your own interface instead.

Do not let integration tests run by default. A test suite that needs an API key is a test suite that new contributors cannot run, and CI cost that grows with every push.

Do not skip testing the error paths because they are “just the SDK’s job”. Rate limits, refusals and mid-stream disconnects are the failures you will actually see in production, and they are the cheapest things in this article to cover.

Checklist

• A narrow interface between your logic and the SDK; business code never imports the SDK.
• A fake with a queue of canned responses for multi-turn loops.
• Unit tests for the loop’s contract: one result per tool call, errors handed back, iteration cap honoured.
• Golden files for prompt assembly, plus a determinism test.
• Integration tests behind //go:build integration, asserting on shape not wording.
• An httptest.Server for 429s, 500s and truncated streams.
• A test for the refusal path.
• Evals behind their own tag, scored against a floor, misses logged.

Conclusion

“You cannot test LLM code” conflates the model with the code around it. The code around it — the prompt builder, the parser, the loop, the tool handlers, the error branches — is ordinary Go, and it becomes easy to test the moment there is an interface between it and the SDK. Push non-determinism out to the edges, cover the edges with evals scored against a floor, and the rest of your suite stays fast, free and green.

The One Rule That Fixes Most of It

Handle an error once. Everywhere else, add context and pass it up.

“Handling” means doing something a caller cannot: returning a 404, retrying, falling back to a default, logging and moving on. If you are not doing one of those, you are just a link in the chain — and a link’s only job is to explain where it sits.

// Bad: the error is logged here and returned, so it will be logged again
// by every caller on the way up.
func (s *Store) User(ctx context.Context, id int64) (*User, error) {
    u, err := s.query(ctx, id)
    if err != nil {
        log.Printf("failed to load user: %v", err)
        return nil, err
    }
    return u, nil
}

// Good: add what this layer knows, and let the caller decide.
func (s *Store) User(ctx context.Context, id int64) (*User, error) {
    u, err := s.query(ctx, id)
    if err != nil {
        return nil, fmt.Errorf("load user %d: %w", id, err)
    }
    return u, nil
}

The second version produces messages that read like a stack trace written in English:

handle GET /users/42: load user 42: query users: sql: no rows in result set

Wrapping With %w

fmt.Errorf has a special verb, %w, that wraps the original error instead of flattening it to a string. The result behaves like a normal error, but the original stays reachable underneath.

_, err := os.Open("/etc/app/config.yaml")
wrapped := fmt.Errorf("read config: %w", err)

fmt.Println(wrapped)
// read config: open /etc/app/config.yaml: no such file or directory

fmt.Println(errors.Is(wrapped, os.ErrNotExist)) // true

That last line is the whole point. %v would have given you the same message, but errors.Is would have returned false because the chain was broken.

A few conventions that keep the output readable:

• Start the message with a lowercase verb phrase describing what this function was doing: "load user", "encode response", "dial redis".
• Do not end with punctuation, and do not include the word “error” or “failed” — the chain already reads as a failure.
• Put the wrapped error last, after a colon and a space.

Since Go 1.20 you can wrap more than one error in a single call, which is handy when you are cleaning up:

err := doWork()
if cerr := f.Close(); cerr != nil {
    err = fmt.Errorf("work failed: %w; close failed: %w", err, cerr)
}

Sentinel Errors: For Conditions Callers Branch On

A sentinel is a package-level error value that callers are meant to recognise.

package store

import "errors"

var (
    ErrNotFound  = errors.New("not found")
    ErrConflict  = errors.New("conflict")
    ErrForbidden = errors.New("forbidden")
)

Return them wrapped, so the caller gets both the identity and the context:

func (s *Store) User(ctx context.Context, id int64) (*User, error) {
    u, err := s.query(ctx, id)
    if errors.Is(err, sql.ErrNoRows) {
        return nil, fmt.Errorf("load user %d: %w", id, ErrNotFound)
    }
    if err != nil {
        return nil, fmt.Errorf("load user %d: %w", id, err)
    }
    return u, nil
}

And check them with errors.Is, which walks the whole chain:

u, err := store.User(ctx, id)
switch {
case errors.Is(err, store.ErrNotFound):
    http.Error(w, "user not found", http.StatusNotFound)
    return
case err != nil:
    log.Error("load user", "err", err)
    http.Error(w, "internal error", http.StatusInternalServerError)
    return
}

Never compare with == when the error might be wrapped, and never compare error strings. errors.Is(err, ErrNotFound) keeps working when someone adds another wrapping layer three months from now; err == ErrNotFound silently stops working.

Keep the list short. Sentinels are part of your package’s public API — every one you export is a promise. If callers cannot meaningfully branch on it, it should not be a sentinel.

Custom Error Types: When You Need to Carry Data

A sentinel says what went wrong. A custom type also says with what. Reach for one when the caller needs a field, not just an identity.

// ValidationError reports a single field that failed validation.
type ValidationError struct {
    Field  string
    Reason string
}

func (e *ValidationError) Error() string {
    return fmt.Sprintf("field %q is invalid: %s", e.Field, e.Reason)
}

errors.As finds it anywhere in the chain and assigns it to your variable:

var vErr *ValidationError
if errors.As(err, &vErr) {
    w.WriteHeader(http.StatusBadRequest)
    json.NewEncoder(w).Encode(map[string]string{
        "field":  vErr.Field,
        "reason": vErr.Reason,
    })
    return
}

Two details that trip people up:

1. Pass a pointer to the target. errors.As(err, &vErr) where vErr is already a *ValidationError. Passing vErr directly panics.
2. Be consistent about pointer vs. value receivers. If Error() is defined on *ValidationError, then only *ValidationError implements error. Return &ValidationError{...}, and match against *ValidationError.

If your type wraps another error, give it an Unwrap method so errors.Is can keep walking:

type QueryError struct {
    Query string
    Err   error
}

func (e *QueryError) Error() string { return e.Query + ": " + e.Err.Error() }
func (e *QueryError) Unwrap() error { return e.Err }

Now errors.Is(err, sql.ErrNoRows) still works even with a QueryError in the middle.

Collecting Several Errors With errors.Join

When you validate a whole struct, failing on the first problem makes for a frustrating API. errors.Join (Go 1.20) combines errors into one value that errors.Is and errors.As can still search.

func (r CreateUserRequest) Validate() error {
    var errs []error
    if r.Email == "" {
        errs = append(errs, &ValidationError{Field: "email", Reason: "required"})
    }
    if len(r.Password) < 12 {
        errs = append(errs, &ValidationError{Field: "password", Reason: "too short"})
    }
    // Join returns nil when every element is nil, so this is safe as-is.
    return errors.Join(errs...)
}

The joined error prints one message per line, and errors.As will find the first *ValidationError inside it.

Which Tool for Which Job

That last row matters more than it looks. A cache miss is not an error. An empty search result is not an error. Reserve errors for situations where the caller genuinely cannot continue as planned.

Errors at the HTTP Boundary

The boundary is where errors finally get handled, and it is worth doing that in exactly one place. Middleware is a natural home for it — the same pattern as the Go middleware example, just applied to errors instead of responses.

// handlerFunc is like http.HandlerFunc but may return an error.
type handlerFunc func(http.ResponseWriter, *http.Request) error

// wrap turns a handlerFunc into a plain http.Handler, translating
// errors into status codes in one place.
func wrap(h handlerFunc) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        err := h(w, r)
        if err == nil {
            return
        }

        var vErr *ValidationError
        switch {
        case errors.Is(err, store.ErrNotFound):
            http.Error(w, "not found", http.StatusNotFound)
        case errors.Is(err, store.ErrForbidden):
            http.Error(w, "forbidden", http.StatusForbidden)
        case errors.As(err, &vErr):
            http.Error(w, vErr.Error(), http.StatusBadRequest)
        case errors.Is(err, context.Canceled):
            // The client hung up. Nothing to report.
            return
        default:
            // Log the full chain, tell the client nothing.
            slog.Error("request failed",
                "method", r.Method, "path", r.URL.Path, "err", err)
            http.Error(w, "internal error", http.StatusInternalServerError)
        }
    })
}

Handlers become quiet and linear:

func getUser(w http.ResponseWriter, r *http.Request) error {
    id, err := strconv.ParseInt(r.PathValue("id"), 10, 64)
    if err != nil {
        return &ValidationError{Field: "id", Reason: "must be an integer"}
    }

    u, err := store.User(r.Context(), id)
    if err != nil {
        return fmt.Errorf("get user: %w", err)
    }

    return json.NewEncoder(w).Encode(u)
}

The context.Canceled case is easy to forget and shows up constantly in production: a user closes the tab, the request context is cancelled, and your dashboard fills with 500s that nothing went wrong for. If you have not met that machinery yet, understanding Golang context covers where those cancellations come from.

Common Pitfalls

One more, subtle enough to deserve its own note: a non-nil interface holding a nil pointer is not nil.

func find() *ValidationError { return nil }

func check() error {
    return find() // returns a non-nil error holding a nil *ValidationError
}

fmt.Println(check() == nil) // false — almost certainly not what you wanted

Declare the return type as error and return a literal nil, or check the concrete value before returning it.

Testing Error Paths

Assert on identity and type, never on the message text. Messages are for humans and will change.

func TestUserNotFound(t *testing.T) {
    _, err := store.User(context.Background(), 999)

    if !errors.Is(err, store.ErrNotFound) {
        t.Fatalf("got %v, want ErrNotFound", err)
    }
}

func TestValidation(t *testing.T) {
    err := CreateUserRequest{}.Validate()

    var vErr *ValidationError
    if !errors.As(err, &vErr) {
        t.Fatalf("got %v, want *ValidationError", err)
    }
    if vErr.Field != "email" {
        t.Errorf("got field %q, want email", vErr.Field)
    }
}

This pairs nicely with mocking the database layer, which I covered in how to test database interactions in Golang applications — you can force sql.ErrNoRows and check that your store translates it into ErrNotFound.

Conclusion

Go’s error handling is verbose, but it is also unusually honest: every failure is a value you can inspect, wrap and route. Wrap with %w on the way up, export a small set of sentinels for the conditions callers care about, use custom types when they need the details, and handle everything exactly once at the boundary. Do that and the if err != nil blocks stop feeling like noise and start reading like documentation.

One case that breaks the usual rules and deserves a look: an LLM call can return HTTP 200 while declining to answer, so err is nil and there is nothing in the content. Calling an LLM from Go covers that branch.

When you develop web applications, it’s crucial to have a testing strategy. Nobody argues about the importance of unit, functional, and integration testing. Nevertheless, very often developers forget to test how their application works under high load. Even, when we have a “green light” from all our testing stages, including manual testing, better to not release it to production, until you load test it. Otherwise, nobody can guarantee, that application will work properly when 50 users will use it simultaneously.

In this article I’m going to load test our web application from the previous article.

For that, we are going to use a K6 tool, written in Go, and uses JavaScript for scripting.

k6 is a developer-centric, free and open-source load testing tool built for making performance testing a productive and enjoyable experience.

Let’s install this tool:

brew install k6

If you have different from the macOS operating system, please read about others ways to install here.

Next, we create a loadtests folder in the root of our project and inside we add a test.js file, where we are going to write our load tests scenarios:

import { sleep } from 'k6';
import http from 'k6/http';
import { check } from 'k6';
import { Rate } from 'k6/metrics';

export let errorRate = new Rate('errors');

export let options = {
    // Here we define our scenarios.
    scenarios: {
        sign_in_page_test: {
            executor: 'constant-vus',
            duration: '1m',
            vus: 100, // amount of the virtual users
            tags: { test_type: 'signInPage' },
            exec: 'signInPage',
        },
    },
    // List of thresholds.
    thresholds: {
        http_req_duration: ['avg<500'], // avg response times must be below 0.5s
        errors: ['rate<0.1'], // <10% errors
    },
};

export function signInPage() {
    const res = http.get(getDomain() + '/user/signin');
    // Here we check the response status.
    const result = check(res, {
        'status is 200': (r) => r.status == 200,
    });
    // If it's different from 200, add info to the errorRate.
    errorRate.add(!result);
    sleep(3)
}

// Gets the domain from the environment variables.
function getDomain() {
    return __ENV.DOMAIN;
}

Above, we have declared a scenario to load test /user/signin page with 100 virtual users who continuously accessing our page in parallel.

To run this load test, we need to execute this command in the terminal:

k6 run --env DOMAIN="http://localhost:8777" ./loadtests/test.js

After some time we will see this results output:

As you could notice, all our defined thresholds were satisfied. So far so good!

Now, let’s see how we can integrate load testing to the Gitlab CI pipeline. Fortunately, it’s easy to do :)

Inside .gitlab-ci.yml we need to add this:

stages:
  - loadtest

loadtesting:
  stage: loadtest
  image:
    name: loadimpact/k6:latest
    entrypoint: [ '' ]
  variables:
    DOMAIN: '[your-testing-domain-here]'  
  script:
    - echo "executing K6 load tests in k6 container..."
    - k6 run --env DOMAIN=${DOMAIN} ./loadtests/test.js

That was it! I’ve described just an idea how you can easily integrate the load testing in your development routine. In the real-world situations you might create more complex load testing scenarios, which will help you find weak points of your application and prevent unexpected downtimes.

I wish you happy coding and no pagerduty calls during the night!😉

Once you can measure, you have something to optimise against. Two places I usually look first: 103 Early Hints in Go for front-end latency, and Ristretto caching for the expensive calls behind it. It is also the right tool to prove your graceful shutdown really does keep errors at zero during a deploy.

And I want to share a short example of how to work with it.

First, we have to install it

go get github.com/DATA-DOG/go-sqlmock

We have this function with SQL query:

func MenuByNameAndLanguage(ctx context.Context, db *sql.DB, name string, langcode string) (*models.Menu, error) {
    result, err := db.Query("SELECT id, langcode, title, link__uri, view_sidemenu FROM menu_link_content_data WHERE menu_name=? AND langcode=?",
         name,
         langcode,
    )
    defer result.Close()
    
    var menuLinks []models.MenuLink
    for result.Next() {
         menuLink := models.MenuLink{}
         err = result.Scan(&menuLink.ID, &menuLink.Langcode, &menuLink.Title, &menuLink.URL, &menuLink.SideMenu)
         menuLinks = append(menuLinks, menuLink)    
    }
    menu := &models.Menu{
         Name: name,
         Links: menuLinks,
    }
    return menu, err
}

This function just getting menu links by menu name and language.

And now let’s test it.

We are going to test that MenuByNameAndLanguage function will return correct Menu structure.

package menu


import (
    "context"
    "testing"


    "github.com/DATA-DOG/go-sqlmock"
    "github.com/stretchr/testify/assert"
    "gitlab.mfb.io/user/graphql_server/models"
)


func TestShouldReturnCorrectMenu(t *testing.T) {

    // Creates sqlmock database connection and a mock to manage expectations.
    db, mock, err := sqlmock.New()

    if err != nil {
        t.Fatalf("an error '%s' was not expected when opening a stub database connection", err)
    }
    // Closes the database and prevents new queries from starting.
    defer db.Close()

    // Here we are creating rows in our mocked database.
    rows := sqlmock.NewRows([]string{"id", "langcode", "title", "link__uri", "view_sidemenu"}).
        AddRow(1, "en", "enTitle", "/en-link", "0").
        AddRow(2, "en", "enTitle2", "/en-link2", "0")

    // This is most important part in our test. Here, literally, we are altering SQL query from MenuByNameAndLanguage
    // function and replacing result with our expected result. 
    mock.ExpectQuery("^SELECT (.+) FROM menu_link_content_data*").
        WithArgs("main", "en").
        WillReturnRows(rows)


    ctx := context.TODO()

    // Calls MenuByNameAndLanguage with mocked database connection in arguments list. 
    menu, err := MenuByNameAndLanguage(ctx, db, "main", "en")

    // Here we just construction our expecting result.
    var menuLinks []models.MenuLink
    menuLink1 := models.MenuLink{
        ID:       1,
        Title:    "enTitle",
        Langcode: "en",
        URL:      "/en-link",
        SideMenu: "0",
    }
    menuLinks = append(menuLinks, menuLink1)

    menuLink2 := models.MenuLink{
        ID:       2,
        Title:    "enTitle2",
        Langcode: "en",
        URL:      "/en-link2",
        SideMenu: "0",
    }

    menuLinks = append(menuLinks, menuLink2)

    expectedMenu := &models.Menu{
        Name:  "main",
        Links: menuLinks,
    }
    
    // And, finally, let's check if result from MenuByNameAndLanguage equal with expected result.// Here I used Testify library (https://github.com/stretchr/testify).
    assert.Equal(t, expectedMenu, menu)
} 

As you see everything in this example was pretty straightforward.

For mo details, you can refer to GoDocs.

Mocking the database is also the easiest way to test your error paths: force sql.ErrNoRows and assert that your store turns it into a sentinel your handler can branch on. I covered how to build those sentinels in error handling in Go. The same fake-the-boundary trick works for code that calls a language model, which people usually assume is untestable — how to test Go code that calls an LLM.