¡Hola a todos!
Mis alumnos y aprendices me inspiraron para escribir este artículo. A menudo recomiendo que aprendan TypeScript tan pronto como se sientan cómodos con el proceso de automatización de pruebas en JavaScript . Veamos cuáles son las características de usar TypeScript en su marco de automatización de pruebas en términos de pruebas de API REST…
Puede encontrar el código completo de un proyecto de prueba aquí .
No profundicemos demasiado en qué es TypeScript y en qué se diferencia de JavaScript y digamos lo importante:
TypeScript se presenta como un paquete de Node.js , por lo que veo esto como JavaScript con algunas características interesantes.
Para obtener más información sobre el lenguaje en sí y lo que tiene para ofrecer, visite el sitio web oficial mientras hablamos sobre sus características en términos de automatización de pruebas...
Repasemos el proceso de creación del proyecto de automatización de pruebas en TypeScript :
Cree un proyecto de Node.js.
npm init -y
Instale el paquete TypeScript .
npm i typescript
Genere una configuración predeterminada de TypeScript para el proyecto: tsconfig.json
.
npx tsc --init
El comando anterior generará un archivo de configuración predeterminado, pero recomiendo acortarlo mucho a algo como esto :
{ "compilerOptions": { "baseUrl": "./", "module": "esnext", "target": "esnext", "sourceMap": false, "moduleResolution": "node", "allowJs": true, "skipLibCheck": true, "resolveJsonModule": true, "allowSyntheticDefaultImports": true, "paths": { "*": ["./*"] } } }
Esta configuración contiene el mínimo requerido:
Puede ampliar su configuración utilizando la documentación oficial .
Puede usar cualquier herramienta que el ecosistema Node.js tenga para ofrecer, pero según mi experiencia, la mayoría de los ingenieros que trabajan con TypeScript eligen Jest por un par de buenas razones:
Anteriormente, me divertía usando Mocha + Chai para configurar el núcleo del proyecto, pero ahora también me quedo con Jest , ya que contiene un ejecutor de pruebas y una biblioteca de afirmaciones.
Axios parece ser el cliente HTTP más popular, por lo que sugiero que esta también sea su elección.
No puedo decir que esté obligado a usar esto para su configuración, pero digo que es lo habitual cuando revisa los proyectos.
Ahora, simplemente instale estos paquetes como dependencias:
npm i jest axios
Algunos paquetes (como Axios ) contienen tipos de TypeScript en su interior, pero Jest y Mocha no. Además, Jest requiere un paquete ts-jest junto con @types/jest para funcionar correctamente: el primero habilita las funciones de TypeScript y el segundo le permite usar IntelliSense .
Así que tenga en cuenta que si no tiene la función de autocompletar cuando intenta usar algunos de los paquetes, probablemente le falten declaraciones de tipo.
Instalemos también las extensiones (paquetes) relacionadas con TypeScript :
npm i ts-jest @types/jest
Jest requiere un ajuste preestablecido de configuración ts-jest , por lo que debe declararlo en su archivo de configuración (o paquete.json ):
{ "jest": { "preset": "ts-jest" } }
Si planea usar una ruta absoluta dentro de un proyecto , también deberá ajustar su configuración:
{ "jest": { "preset": "ts-jest", "moduleDirectories": [ "node_modules", "<rootDir>" ] } }
Esta configuración le permite ejecutar pruebas con un comando simple... jest
Entonces, configure su script de prueba en package.json para que sea:
{ "scripts": { "test": "jest" } }
Y luego ejecute sus pruebas en cualquier momento con el comando npm test
o npm run test
.
También le recomiendo que instale una extensión de Jest Runner si es usuario de Visual Studio Code ; le permite ejecutar / depurar las pruebas/suites deseadas con solo un clic. En WebStorm, es una función integrada.
La característica principal que introduce TypeScript en las pruebas de la API REST es...
Puede declarar cómo debería verse el cuerpo de su solicitud y respuesta, es decir,
Tomemos un servidor Paysis como ejemplo: podemos escribir la carga útil del cuerpo de la solicitud para el punto final /auth
como un tipo:
export type AuthRequestBody = { login: string password: string }
Y lo mismo para el cuerpo de respuesta: qué servidor debe enviar a nuestra solicitud:
export type AuthResponseBody = { token?: string message?: string }
Dado que habría una carga útil diferente para los escenarios de éxito/fracaso, puede marcar las claves como "opcionales" a través de " ?" personaje.
Una vez hecho esto, puede usar estos tipos para redactar solicitudes y verificaciones en sus pruebas...
En Axios , puede decir qué cuerpo está enviando a través de la configuración de solicitud:
const payload: AxiosRequestConfig<AuthRequestBody> = { method: 'post', url: '/auth', data: { login: process.env.USERNAME, password: process.env.PASSWORD, }, }
AuthRequestBody
en AxiosRequestConfig<AuthRequestBody>
significa exactamente eso ☝️
Significa que se verá obligado a usar la carga útil que coincida con el tipo AuthRequestBody
proporcionado en el objeto data
. Si olvida establecer algunos campos obligatorios o establece algunos excesivos, verá un error.
Se puede hacer lo mismo con respecto a la respuesta:
const response: AxiosResponse<AuthResponseBody> = await client.request(payload)
Agregará autocompletar al objeto response.data
, por lo que podrá acceder a los campos de response.data.token
o response.data.message
.
Además de las cosas simples anteriores, también es posible generar un esquema JSON a partir de sus tipos personalizados . No le permite verificar cada clave individual en un cuerpo de respuesta para ver si coincide con el esquema, sino verificar toda la carga útil .
Entonces la idea es:
Cosas bastante interesantes, pero tenga en cuenta que sus pruebas pueden volverse inestables después de estos cambios; sucede cuando aparecen algunos campos adicionales, por lo que deberá actualizar el esquema regularmente.
La configuración de TypeScript puede ser complicada, especialmente si es la primera vez, ¡pero vale la pena!
Si cubre sus datos de entrada y salida con tipos, no hay forma de que cometa un error tipográfico o algún otro error de sintaxis cuando analice estos objetos. Lo salva de errores simples y le permite ver la estructura de sus solicitudes directamente en su código, por lo que no tiene que abrir ninguna colección HTTP (como Postman ) y buscar la solicitud que necesita para ver qué cuerpo solicita/responde con.
Cuéntame sobre tu experiencia y lo que piensas al respecto.