Eine Go-CAPTCHA-Integration testen, ohne Guthaben zu verbrauchen

1. 1.

   Abhängigkeit installieren

   Verwenden Sie Go 1.22 oder neuer. Installieren Sie in Ihrem Go-Modul mit go get das Modul solvethree.com/[email protected]. Das Modul wird über solvethree.com bereitgestellt.

2. 2.

   Test speichern und ausführen

   Speichern Sie das Beispiel als captcha_integration_test.go in einem reinen Testverzeichnis innerhalb Ihres Moduls und führen Sie dort go test aus. Lassen Sie den Fixture-Schlüssel, den Hostnamen und den Proxy unverändert: Das sind Testdaten, keine Zugangsdaten oder Dienste, die Sie konfigurieren müssen.

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 akzeptiert für Tests HTTP über die Loopback-Adresse. Hier ersetzt server.URL die Produktionsadresse der API, und der Handler antwortet lokal. Der Proxy-Wert ist lediglich Teil des übermittelten Tasks; diese Fixture stellt keine Verbindung zu ihm her.

Nach der POST-Antwort bleibt der Task im Status pending. Eine nachfolgende Anfrage erhält eine ready-Antwort mit FIXTURE_TOKEN. Die abschließende Assertion prüft sowohl das zurückgegebene Token als auch, dass genau ein POST gesendet wurde. So erkennt sie, wenn in diesem Ablauf versehentlich ein zusätzlicher Task erstellt wird.

Der Handler ist bewusst einfach gehalten: Jede Anfrage, die kein POST ist, erhält die ready-Antwort. Er prüft weder die Polling-Methode noch den Anfragepfad oder das übermittelte JSON. Um auch den Anfragevertrag zu testen, lassen Sie den Handler die erwarteten Routen für die Erstellung und den Task-Abruf sowie die übermittelte Site, Aktion und den Proxy prüfen.

Ein bestandener Test weist nach, dass der simulierte SDK-Lebenszyklus funktioniert. Er validiert weder ein echtes Site-Profil noch einen Proxy oder die Akzeptanz des Tokens durch das Ziel. Das zurückgegebene Token und die Browseridentität sind Fixture-Werte.

Erweitern Sie den lokalen Handler so, dass er die Bedingungen zurückgibt, die Ihre Anwendung behandeln muss. Behalten Sie den POST-Zähler bei: Die Wiederholung einer Polling-Anfrage sollte keinen weiteren Task erstellen.

Geben Sie dem Test für den Fall einer verlorenen Antwort eine explizite Anfrage-ID und lassen Sie die Fixture den bestehenden Task zurückgeben, wenn diese ID mit denselben Eingaben erneut gesendet wird. Andernfalls testen Sie eine zweite Erstellung statt der Wiederherstellung.