Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#956 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Activo
Stack tecnológico
java
Área
testing

Línea de trabajo

Empieza inspeccionando la abstracción central HttpClient existente y su implementación con OkHttp para entender la interfaz disponible para un transporte de prueba. La propuesta describe una primera versión de amplio alcance que cubre respuestas guionizadas, aserciones de solicitudes, streaming, fallos, cancelación y finalización de interacciones; para darla por terminada harían falta un alcance acordado y pruebas para los comportamientos seleccionados sin acceso a la red.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Kotlin
Estrellas
1.5k
Forks
265
Merge medio
12 h 3 min
PR fusionados (30 d)
131

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de openai/openai-java

Todos los issues de openai/openai-java

Issues similares

Más issues de Kotlin

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.