Test a Go CAPTCHA integration without spending credit

1. 1.

   Install the dependency

   Use Go 1.22 or later. In your Go module, use go get to install solvethree.com/[email protected]. The module is served from solvethree.com.

2. 2.

   Save and run the test

   Save the example as captcha_integration_test.go in a test-only directory within your module, then run go test from that directory. Keep the fixture key, hostname and proxy unchanged: they're test data, not credentials or services you need to configure.

package integration_test

import (
    "context"
    "fmt"
    "net/http"
    "net/http/httptest"
    "sync/atomic"
    "testing"
    "time"
    solvethree "solvethree.com/sdk"
)

func TestSolve(t *testing.T) {
    var posts atomic.Int32
    server := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        w.Header().Set("Content-Type", "application/json")
        if r.Method == "POST" {
            posts.Add(1)
            fmt.Fprint(w, `{"id":"fixture-1","status":"pending"}`)
            return
        }
        fmt.Fprint(w, `{"id":"fixture-1","status":"ready","solution":{"token":"FIXTURE_TOKEN","userAgent":"fixture-browser-identity","secChUa":"fixture-hints"}}`)
    }))
    defer server.Close()
    client, err := solvethree.NewClientWithBaseURL("fixture-key", server.URL, nil)
    if err != nil { t.Fatal(err) }
    result, err := client.Solve(context.Background(), solvethree.TaskRequest{
        Site: "accounts.example.com", Action: "login", Proxy: "http://proxy.example:8080",
    }, solvethree.SolveOptions{Timeout: time.Second, PollInterval: time.Millisecond})
    if err != nil { t.Fatal(err) }
    if result.Solution.Token != "FIXTURE_TOKEN" || posts.Load() != 1 { t.Fatal("incorrect lifecycle") }
}

NewClientWithBaseURL accepts loopback HTTP for tests. Here, server.URL replaces the production API address, and the handler answers locally. The proxy value is just part of the submitted task; this fixture doesn't connect to it.

The POST response leaves the task pending. A subsequent request receives a ready response containing FIXTURE_TOKEN. The final assertion checks both the returned token and exactly one POST, catching an accidental extra task creation during this flow.

The handler deliberately stays small: every non-POST request gets the ready response. It doesn't assert the polling method, request path or submitted JSON. To test the request contract too, make the handler check the expected creation and task-retrieval routes, plus the submitted site, action and proxy.

Passing this test proves the simulated SDK lifecycle works. It doesn't validate a real site profile, proxy or token acceptance by the target. The returned token and browser identity are fixture values.

Extend the local handler to return the conditions your application must handle. Keep the POST counter: retrying a poll shouldn't create another task.

For the lost-response case, give the test an explicit request ID and make the fixture return the existing task when that ID and the same inputs are replayed. Otherwise, you're testing a second creation—not recovery.