Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Feature proposal: official scripted HTTP test client for offline SDK tests

Aperta
  • Qualcosa non va?
#956 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Attiva
Stack tecnologico
java
Ambito
testing

Direzione di ricerca

Inizia esaminando l’astrazione centrale HttpClient esistente e la sua implementazione OkHttp per comprendere l’interfaccia disponibile per un transport di test. La proposta descrive una prima versione di ampio respiro che copre risposte definite da script, asserzioni sulle richieste, streaming, errori, cancellazione e completamento delle interazioni; per considerarla completata sarebbero necessari un ambito concordato e test per i comportamenti selezionati senza accesso alla rete.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Proposal

Add a small official scripted/test HttpClient implementation so Java applications can test OpenAI SDK integration deterministically without making live network/API calls or standing up a local HTTP server.

The SDK already has a core HttpClient abstraction underneath the OkHttp implementation. A test-focused implementation could use that same boundary while remaining separate from generated resource/model code.

Conceptually:

ScriptedHttpClient http = ScriptedHttpClient.builder()
    .expectRequest(request -> {
        assertEquals("POST", request.method().name());
        assertEquals("/v1/responses", request.path());
    })
    .respondJson(200, fixture("response.json"))
    .build();

OpenAIClient client = OpenAIClient.builder()
    .httpClient(http)
    .apiKey("test")
    .build();

A deliberately small first version could support:

  • queueing scripted HTTP responses;
  • capturing requests and asserting method/path/query/headers/body;
  • ordinary JSON responses;
  • SSE/streaming response fixtures;
  • scripted HTTP error responses and transport failures;
  • cancellation/async completion behaviour where applicable;
  • request history plus a final assertion that all expected interactions occurred;
  • no network access and no dependency on a real API key.
Why this is useful

SDK users often need to test their own integration logic around request construction, streaming, retries/errors, cancellation, and response handling. Today that generally requires a third-party HTTP mock server, custom fake transport, or live API calls.

A first-party scripted transport would let tests exercise the real generated OpenAI client and serialization/parsing layers while replacing only the HTTP boundary. It would also provide a stable testing primitive that follows SDK changes rather than forcing applications to maintain their own transport doubles.

Scope / compatibility

This should be Java 8-compatible and can live in a small optional testing module/package so normal runtime users do not pay for additional dependencies or custom-code surface unnecessarily.

This is not a production traffic recorder/replayer. Responses and expected requests are explicitly authored test fixtures, which avoids accidentally capturing prompts, credentials, or production data.

I searched current issues for mock/test transports, offline testing, fixtures, record/replay, and MockWebServer-style support and did not find an equivalent proposal.

Given that much of this SDK is generated and the custom-code budget is intentionally limited, I am proposing this as a bounded helper around the existing HttpClient abstraction rather than changes throughout the generated API surface.

Lingua principale
Kotlin
Stelle
1.5k
Fork
266
Merge medio
9h 50m
PR unite (30g)
146

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di openai/openai-java

Tutte le issue di openai/openai-java

Issue simili

Altre issue su Kotlin

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.