Escribir un script de prueba automatizado es fácil. Escribir uno que siga siendo útil seis meses después es lo difícil. Muchos scripts de prueba se escriben, se ejecutan en verde una vez y luego se deterioran silenciosamente, fallando por cambios no relacionados, sin afirmar nada significativo y entrenando al equipo para ignorar las compilaciones en rojo. Un buen script de prueba es preciso, aislado y duradero.
Esta guía cubre qué es un script de prueba automatizado, la estructura que lo hace confiable, dos formas de escribir scripts de prueba de API y una construcción paso a paso en Apidog.
Qué es un script de prueba automatizado
Un script de prueba automatizado es un conjunto de instrucciones definido y repetible que ejercita una parte de su software y verifica el resultado, sin que un humano ejecute los pasos. El script envía una entrada, realiza una acción y compara el resultado con una expectativa. Si coinciden, pasa. Si no, falla e informa el motivo.
Un script de prueba es la forma ejecutable de un caso de prueba. El caso de prueba describe la intención, la entrada, la acción y el resultado esperado, en términos humanos. El script convierte esa intención en algo que una máquina ejecuta en cada commit. Un caso de prueba puede convertirse en un script; un escenario de prueba generalmente se convierte en varios encadenados.
El valor de un script de prueba automatizado es que se ejecuta de la misma manera cada vez. Eso solo se cumple si el script está escrito para ser determinista. Un script que depende del orden en que se ejecutaron otros scripts, o de datos dejados por una ejecución anterior, no es una automatización confiable; es una responsabilidad inestable.
La estructura de un script de prueba confiable
Casi todos los scripts de prueba bien escritos, en cualquier lenguaje o herramienta, siguen la misma forma de cuatro partes. A menudo se le llama Organizar-Actuar-Verificar (Arrange-Act-Assert), con la adición de la limpieza.
Organizar (Arrange). Configurar todo lo que la prueba necesita: los datos de entrada, la autenticación, cualquier condición previa. El script debe crear su propio estado en lugar de asumir que existe. Si la prueba necesita un usuario, lo crea o utiliza un fixture conocido, no lo que sea que haya en la base de datos.
Actuar (Act). Realizar la única acción bajo prueba. Un buen script prueba un comportamiento. Enviar una solicitud, llamar a una función, activar un evento, ese es el acto, y debería haber exactamente uno de ellos por script.
Verificar (Assert). Comprobar el resultado frente a las expectativas. Esta es la parte en la que los equipos invierten poco. Un script que solo afirma "no se lanzó ningún error" o "el estado fue 200" apenas prueba nada. Las aserciones sólidas verifican los valores reales: el cuerpo de la respuesta, el esquema, los efectos secundarios, el tiempo.
Limpiar (Cleanup). Deshacer lo que el script creó para que pueda ejecutarse de nuevo desde cero. Un script que deja datos de prueba atrás eventualmente chocará consigo mismo o con otro script.
Tres hábitos separan los scripts duraderos de los frágiles. Probar una cosa por script, para que un fallo tenga una causa obvia. Mantener los scripts independientes, para que se ejecuten en cualquier orden. Y verificar valores estables, nunca datos volátiles como ID generados o marcas de tiempo, que hacen que un script falle sin una razón real.
Dos formas de escribir scripts de prueba de API
Para las pruebas de API específicamente, existen dos enfoques comunes, y se adaptan a diferentes equipos.
El enfoque "code-first" (primero el código) escribe scripts de prueba en un lenguaje de propósito general. En Python, eso significa un framework como pytest más una biblioteca HTTP; en JavaScript, un ejecutor de pruebas más fetch. Se escribe la solicitud, las aserciones y la configuración como código real, y los scripts residen en su repositorio junto con la aplicación.
Este enfoque ofrece un control programático completo. La lógica compleja, los fixtures personalizados y las aserciones inusuales son solo código. El costo es que cada script es código que usted escribe y mantiene, el equipo necesita habilidades en el lenguaje, y gran parte del código repetitivo (boilerplate), el manejo de autenticación, la construcción de solicitudes, el análisis de respuestas, se reescribe en varios scripts. Se adapta a los equipos de ingeniería que desean pruebas versionadas con el código y se sienten cómodos asumiendo ese mantenimiento.
El enfoque visual construye el script de prueba en una herramienta dedicada de prueba de API. Se define la solicitud, se añaden aserciones haciendo clic y se encadenan las solicitudes en escenarios, sin escribir ni mantener código de script para los casos comunes. Herramientas como Apidog siguen esta ruta.
Este enfoque elimina el código repetitivo y hace que los scripts sean legibles por cualquier miembro del equipo, no solo por aquellos que conocen el lenguaje. Aún puede recurrir a código personalizado para la lógica rara que el constructor visual no puede expresar. Se adapta a equipos mixtos, pruebas lideradas por QA y cualquier persona que desee un conjunto de pruebas funcionando rápidamente sin un proyecto de scripting asociado.
Ninguno es incorrecto. La pregunta decisiva es quién mantiene los scripts y si deben residir en el repositorio de la aplicación. Para la mayoría de las pruebas de API, el enfoque visual permite tener un conjunto confiable funcionando más rápido y con menos mantenimiento.
Escribir un script de prueba de API automatizado en Apidog
Aquí está el flujo completo para construir un script de prueba de API duradero de forma visual.
Paso 1: Definir la solicitud. Importe el endpoint a Apidog desde un archivo OpenAPI o defínalo directamente. Este es el paso de Organización (Arrange); la solicitud lleva su método, ruta, encabezados y cuerpo.
Paso 2: Añadir los datos de prueba. Establezca la carga útil de entrada para el caso que está probando. Para cubrir muchas entradas con un solo script, adjunte un archivo CSV o JSON para que el script se ejecute una vez por fila; las pruebas basadas en datos reemplazan una docena de scripts casi idénticos con uno.
Paso 3: Escribir las aserciones. Este es el núcleo. Agregue verificaciones visuales: el estado es igual al código esperado, los campos clave del cuerpo existen y tienen los valores correctos, la respuesta se ajusta al esquema, el tiempo de respuesta está dentro del presupuesto. Para casos negativos, aserte la forma del error, no solo el código de fallo. Resista la tentación de asertar datos volátiles.
Paso 4: Encadenar solicitudes en un escenario. Los flujos de trabajo reales abarcan varias llamadas. Construya un escenario que inicie sesión, cree un recurso, lo lea y lo elimine, pasando valores de un paso al siguiente. Cada paso es un script; juntos prueban un flujo completo.
Paso 5: Añadir lógica de script personalizada solo cuando sea necesario. Para verificaciones que las aserciones visuales no pueden expresar, lógica condicional, valores calculados, comparaciones entre solicitudes, agregue un pre- o post-procesador de JavaScript. Mantenga esto al mínimo; la mayoría de los scripts nunca lo necesitan.
Paso 6: Ejecutarlo y leer el informe. Ejecute el escenario. Apidog ejecuta cada script, evalúa cada aserción e informa la verificación exacta que falló con los valores esperados y reales uno al lado del otro.
Paso 7: Automatizar la ejecución. Conecte el escenario a CI/CD para que se ejecute en cada commit. Un script de prueba que solo se ejecuta cuando alguien lo recuerda no está realmente automatizado. Descargue Apidog para construir su primer escenario.
Mantener los scripts de prueba saludables
Una suite de pruebas es un ser vivo. Los scripts que eran perfectos en el lanzamiento quedan obsoletos a medida que la API cambia. Tres prácticas mantienen la confiabilidad de una suite.
Actualice los scripts con la API, no después. Cuando el contrato de un endpoint cambia, el script cambia en el mismo commit. Un script que aserta un esquema antiguo falla por la razón equivocada y erosiona la confianza en todos los demás scripts.
Trate los scripts inestables como errores reales. Un script que pasa la mayor parte del tiempo es peor que ningún script, porque le enseña al equipo que el rojo no significa que esté roto. Investigue la causa, generalmente un estado compartido o una suposición de tiempo, y corríjalo.
Revise los scripts como código de producción. Un script con aserciones débiles, una verificación de solo 200, parece verde y se siente seguro mientras prueba casi nada. Un segundo lector detecta eso.
Preguntas frecuentes
¿Cuál es la diferencia entre un caso de prueba y un script de prueba? Un caso de prueba describe la intención en términos humanos: entrada, acción, resultado esperado. Un script de prueba es la versión ejecutable que una máquina ejecuta. El caso es el plan; el script es la implementación.
¿Necesito saber codificar para escribir scripts de prueba automatizados? No para las pruebas de API con una herramienta visual. En Apidog, construye solicitudes, aserciones y escenarios haciendo clic, y escribe código solo para lógica inusual. Los frameworks "code-first" sí requieren habilidades en el lenguaje.
¿Por qué mis scripts de prueba siguen fallando? Las causas habituales son aserciones sobre datos volátiles, scripts que dependen del estado de otros y no actualizar los scripts cuando la API cambia. Aísle los datos de prueba, mantenga los scripts independientes y actualícelos con el contrato.
¿Cuántas aserciones debería tener un script de prueba? Las suficientes para verificar genuinamente el resultado, típicamente el estado, los campos clave del cuerpo, el esquema y el tiempo. Una única aserción de código de estado es demasiado poca; pasa mientras la respuesta es incorrecta.
¿Deberían los scripts de prueba residir en el repositorio de la aplicación? Con un enfoque "code-first", generalmente sí, para que las pruebas versionen con el código. Con una herramienta visual, los scripts residen en la plataforma de pruebas y se sincronizan con la definición de la API. Ambas opciones funcionan; la consistencia importa más que la elección.
¿Cómo escribo scripts de prueba antes de que se construya la API? Escríbalos contra el diseño de la API. Si tiene una especificación OpenAPI, puede definir solicitudes y aserciones a partir de ella, luego ejecutarlas contra un servidor simulado hasta que exista el endpoint real. Los scripts estarán listos en el momento en que se implemente.
¿Cuál es la diferencia entre un script de prueba y una suite de pruebas? Un script de prueba ejecuta una verificación. Una suite de pruebas es una colección de scripts agrupados para ejecutarse juntos, a menudo cubriendo una API o característica completa. Las suites mantienen un conjunto creciente de scripts organizados y le permiten ejecutar una cobertura amplia con un solo comando.
¿Qué tan largo debe ser un script de prueba automatizado? Tan corto como sea posible, mientras aún realice las cuatro partes: organizar, actuar, asertar, limpiar. Si un script es largo, generalmente está probando más de una cosa y debería dividirse. Un comportamiento por script facilita el diagnóstico de fallos.