Escribir una verificación de integración sin secretos

1297. Identidad de la lección

Módulo

3.12 — Integración Steam

Lección

Escribir una verificación de integración sin secretos

Tipo académico

Flujo de trabajo

Tipo de esquema

mixto

Orden

2 del módulo

Tiempo estimado

45–60 minutos, incluida la práctica

Esta lección define un flujo seguro para verificar una integración de plataforma. El resultado es una matriz de integración de Steam organizada alrededor de cinco campos canónicos: quién es responsable del comportamiento, qué configuración requiere, cómo se probará, cómo se comporta ante un fallo y qué evidencia resulta suficiente.

1298. Objetivo de aprendizaje

Al finalizar esta lección, podrás producir una matriz de integración de Steam con propiedad explícita, marcadores de configuración, modos de prueba, comportamiento de fallo y requisitos de evidencia, sin exponer credenciales.

1299. Por qué importa

El trabajo de plataforma se vuelve arriesgado cuando una afirmación vaga como “Steam funciona” se trata como un resultado de prueba. Una verificación útil identifica el límite responsable, separa la configuración del comportamiento en runtime y registra qué puede demostrarse realmente en el entorno disponible. Así puedes dirigir a la IA con precisión sin entregarle secretos ni permitir que sugiera que una prueba no ejecutada fue aprobada. El resultado es una decisión técnica acotada, no una promesa basada únicamente en la configuración.

1300. Conocimientos previos

Debes poder distinguir la configuración de la store, el cliente de Steam y el juego en ejecución como límites separados. También debes poder describir un comportamiento de integración en runtime y su alternativa cuando el cliente de plataforma no está disponible. Esta lección depende directamente de Store, cliente y juego son límites distintos.

1301. Concepto central

Una verificación de integración es una afirmación limitada respaldada por evidencia observable. La matriz debe separar cinco preguntas:

1. Propiedad: ¿Qué límite es responsable del comportamiento o la configuración: la store, el cliente de plataforma, el runtime del juego o el arnés de pruebas?
2. Configuración: ¿Qué valor público, fixture local o marcador se necesita? Nunca coloques un secreto real en el artefacto de la lección.
3. Modo de prueba: ¿En qué modo controlado se ejecutará la verificación, por ejemplo con un fixture local, una simulación de cliente no disponible o un build de prueba designado?
4. Comportamiento de fallo: ¿Qué ocurre cuando la dependencia falta, es inválida o no está disponible?
5. Evidencia: ¿Qué artefacto, registro, captura o salida de prueba respalda únicamente la afirmación indicada?

Usa marcadores como <STEAM_APP_ID>, <TEST_BUILD_ID> o <PLATFORM_CLIENT_STATE>. Un marcador documenta un requisito de interfaz; no demuestra que el valor sea válido ni que la integración se haya ejecutado.

1302. Modelo mental

Usa la matriz Propiedad → Configuración → Modo de prueba → Comportamiento de fallo → Evidencia:

Cada fila debe describir un comportamiento y señalar a su responsable. La configuración no es evidencia, y un modo de prueba no constituye una afirmación sobre producción. La matriz está completa únicamente cuando cada fila contiene los cinco campos y su límite de evidencia está claro.

1303. Ejemplo concreto

Supón que la verificación trata sobre la disponibilidad del cliente. Una fila acotada podría escribirse así:

Límite de la afirmación: Esta fila verifica la respuesta del juego ante dos estados de disponibilidad controlados. No verifica la propiedad de una cuenta, los metadatos de la store, una respuesta de servicio en vivo ni la preparación para producción.

Esta estructura evita dos errores de categoría habituales. Un identificador de aplicación configurado puede aparecer en el campo de configuración, pero su presencia no demuestra el comportamiento en runtime. Del mismo modo, un fixture local puede demostrar la respuesta del juego ante un cliente no disponible, pero no puede demostrar que un cliente real de plataforma devuelva el mismo estado.

1304. Flujo de trabajo nativo de IA

Usa la IA como compañera para redactar y cuestionar, no como fuente de evidencia de plataforma no verificada.

1. Proporciona a la IA los límites responsables y el único comportamiento que quieres comprobar. Usa marcadores en lugar de claves de aplicación, datos de cuentas, tokens o configuración privada.
2. Pídele que redacte una fila con los cinco campos canónicos: propiedad, configuración, modo de prueba, comportamiento de fallo y evidencia.
3. Pídele que cuestione la fila: “¿Qué no demostraría esta verificación?”.
4. Compara el borrador con el comportamiento observable disponible en tu entorno de prueba.
5. Reescribe la fila para que su requisito de evidencia pueda satisfacerse sin secretos.
6. Pide a la IA que revise la matriz final en busca de valores con apariencia de secreto, afirmaciones ambiguas de éxito, fallos ausentes, propiedad poco clara y filas que mezclen varias capacidades.

Una instrucción adecuada sería:

Redacta una fila de matriz para este único comportamiento de integración con Steam. Incluye propiedad, configuración usando solamente marcadores, modo de prueba, comportamiento esperado y de fallo, evidencia y límite de la afirmación. No inventes respuestas de API, credenciales ni resultados de pruebas completadas.

La responsabilidad de decidir si la evidencia es real y si el alcance es honesto sigue siendo del estudiante. La IA puede mejorar la redacción; no puede convertir una verificación no ejecutada en una prueba aprobada.

1305. Error común

El error más común es confundir la presencia de una configuración con una verificación en tiempo de ejecución. Ver un marcador, un identificador de aplicación o una ruta configurada del cliente no demuestra que el juego pueda utilizar la dependencia. Otro error frecuente es escribir “falla correctamente” sin indicar el responsable, el modo de prueba, el comportamiento visible, la regla de continuidad y la evidencia necesaria para confirmarlo. Una verificación sin modo de prueba o caso de fallo definido está incompleta aunque su ruta de éxito sea clara.

1306. Práctica guiada

Crea una matriz con al menos cuatro filas para una revisión hipotética de integración con Steam. Usa estos alcances de comportamiento único:

1. El juego detecta si el cliente de plataforma está disponible.
2. El juego gestiona un cliente no disponible sin bloquear el bucle principal.
3. Un identificador de aplicación configurado atraviesa el límite previsto sin exponer un secreto.
4. El resultado del diagnóstico se registra de forma que pueda revisarse sin datos de cuenta.

Para cada fila, completa exactamente estos campos:

• propiedad: el límite responsable del comportamiento o la configuración;
• configuración: un valor público, fixture controlado o marcador;
• modo de prueba: las condiciones controladas en las que se ejercita la verificación;
• comportamiento de fallo: la respuesta observable cuando la dependencia falta, es inválida o no está disponible; y
• evidencia: el artefacto que respalda la afirmación y el límite que no respalda.

Después toma una decisión deliberada de alcance: elige una fila y reduce su afirmación hasta que la evidencia pueda respaldarla sin una credencial activa. Registra qué eliminaste, qué campo cambió y por qué. No uses credenciales reales, información de cuentas, tokens privados ni valores copiados con apariencia de secreto en la matriz.

1307. Validación / evidencia

1308. Puntos clave

• La propiedad distingue la responsabilidad de la configuración y de la observación en runtime.
• Los marcadores documentan interfaces necesarias sin exponer credenciales ni insinuar que existe una configuración activa válida.
• El modo de prueba define cómo se ejercita un comportamiento; no amplía la afirmación a producción.
• Cada fila necesita un comportamiento de fallo explícito y evidencia con un límite declarado.
• La IA puede redactar y cuestionar la matriz, pero el estudiante debe verificar el alcance y la evidencia.

1309. Siguiente lección

Continúa con La identidad de versión tiene más de un significado.

1310. Comprobación