Tester une intégration CAPTCHA en Go sans dépenser de crédit

1. 1.

   Installez la dépendance

   Utilisez Go 1.22 ou une version ultérieure. Dans votre module Go, utilisez go get pour installer solvethree.com/[email protected]. Le module est distribué depuis solvethree.com.

2. 2.

   Enregistrer et exécuter le test

   Enregistrez l’exemple sous le nom captcha_integration_test.go dans un répertoire réservé aux tests au sein de votre module, puis exécutez go test depuis ce répertoire. Ne modifiez pas la clé, le nom d’hôte ni le proxy du dispositif de test : ce sont des données de test, pas des identifiants ni des services à configurer.

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 accepte HTTP sur l’interface de bouclage pour les tests. Ici, server.URL remplace l’adresse de l’API de production et le gestionnaire répond localement. La valeur du proxy fait simplement partie de la tâche envoyée ; ce dispositif de test ne s’y connecte pas.

La réponse POST laisse la tâche en attente. Une requête ultérieure reçoit une réponse indiquant que la tâche est prête et contenant FIXTURE_TOKEN. L’assertion finale vérifie à la fois le jeton renvoyé et la présence d’exactement un POST, ce qui détecte la création accidentelle d’une tâche supplémentaire pendant ce déroulement.

Le gestionnaire reste volontairement minimal : toute requête autre que POST reçoit la réponse indiquant que la tâche est prête. Il ne vérifie ni la méthode d’interrogation, ni le chemin de la requête, ni le JSON envoyé. Pour tester aussi le contrat de requête, faites vérifier au gestionnaire les routes attendues de création et de récupération des tâches, ainsi que le site, l’action et le proxy envoyés.

La réussite de ce test prouve que le cycle de vie simulé du SDK fonctionne. Elle ne valide ni un profil de site réel, ni un proxy, ni l’acceptation du jeton par la cible. Le jeton renvoyé et l’identité du navigateur sont des valeurs de test.

Étendez le gestionnaire local pour qu’il renvoie les situations que votre application doit gérer. Conservez le compteur de POST : réessayer une interrogation ne doit pas créer une autre tâche.

Pour le cas de perte de réponse, donnez au test un identifiant de requête explicite et faites renvoyer la tâche existante par le dispositif de test lorsque cet identifiant et les mêmes données d’entrée sont renvoyés. Sinon, vous testez une seconde création, pas une reprise.