Compartir a través de

Prueba del portal para desarrolladores autohospedado

APLICABLE A: Desarrollador | Básico | Básico v2 | Estándar | Estándar v2 | Premium | Premium v2

En este artículo se explica cómo configurar pruebas unitarias y pruebas integrales para el portal autohospedado.

Crear pruebas unitarias

Una prueba unitaria es un enfoque para validar pequeños fragmentos de funcionalidad. Una prueba unitaria funciona de forma aislada de otras partes de la aplicación.

Escenario de ejemplo

En este escenario, está probando un control de entrada de contraseñas. Solo acepta contraseñas que contengan al menos:

  • Una letra
  • Un número
  • Un carácter especial

La prueba para validar estos requisitos tiene el siguiente aspecto:

const passwordInput = new PasswordInput();

passwordInput.value = "";
expect(passwordInput.isValid).to.equal(false);

passwordInput.value = "password";
expect(passwordInput.isValid).to.equal(false);

passwordInput.value = "p@ssw0rd";
expect(passwordInput.isValid).to.equal(true);

Estructura del proyecto

Es habitual mantener una prueba unitaria junto al componente que valida.

component.ts
component.spec.ts

Simulación de solicitudes HTTP

Hay casos en los que espera que un componente haga solicitudes HTTP. El componente tiene que reaccionar correctamente a diferentes tipos de respuestas. Para simular respuestas HTTP específicas, use MockHttpClient. Implementa la interfaz HttpClient usada por muchos otros componentes del proyecto.

const httpClient = new MockHttpClient();

httpClient.mock()
    .get("/users/jane")
    .reply(200, {
        firstName: "Jane",
        lastName: "Doe"
    });

Creación de pruebas integrales

Una prueba de un extremo a otro ejecuta un escenario de usuario determinado que realiza pasos exactos que espera que lleve a cabo el usuario. En una aplicación web como el portal para desarrolladores de Azure API Management, el usuario se desplaza por el contenido y selecciona opciones para lograr determinados resultados.

Para replicar la navegación del usuario, puede usar bibliotecas auxiliares de manipulación del explorador, como Puppeteer. Esto le permite simular acciones del usuario y automatizar escenarios supuestos. Puppeteer también toma automáticamente capturas de pantalla de páginas o componentes en cualquier fase de la prueba. Más adelante, compare los resultados con los anteriores para detectar desviaciones y posibles regresiones.

Escenario de ejemplo

En este escenario, tiene que validar un flujo de inicio de sesión de usuario. Para este escenario, se deberían seguir los pasos a continuación:

  1. Abra el explorador y vaya a la página de inicio de sesión.
  2. Introduzca la dirección de correo electrónico.
  3. Escriba la contraseña.
  4. Seleccione Registrarse.
  5. Compruebe que se redirija al usuario a la página principal.
  6. Compruebe que la página incluye el elemento de menú Perfil. Es uno de los posibles indicadores de que ha iniciado sesión correctamente.

Para ejecutar la prueba automáticamente, cree un script con exactamente los mismos pasos:

// 1. Open browser and navigate to the sign-in page.
const page = await browser.newPage();
await page.goto("https://contoso.com/signin");

// 2. Enter email.
await this.page.type("#email", "john.doe@contoso.com");

// 3. Enter password.
await this.page.type("#password", "p@s$w0rd");

// 4. Click Sign-in.
await this.page.click("#signin");

// 5. Verify that user got redirected to Home page.
expect(page.url()).to.equal("https://contoso.com");

// 6. Verify that the page includes the Profile menu item.
const profileMenuItem = await this.page.$("#profile");
expect(profileMenuItem).not.equals(null);

Nota:

Las cadenas como #email, #passwordy #signin son selectores similares a CSS que identifican elementos HTML en la página. Para obtener más información, vea Selectores nivel 3 especificación W3C.

Asignación de componentes de UI

Los flujos de usuario suelen pasar por las mismas páginas o componentes. Un buen ejemplo es el menú principal del sitio web que está presente en cada página.

Cree una asignación de componentes de la interfaz de usuario para evitar configurar y actualizar los mismos selectores para cada prueba. Por ejemplo, podría reemplazar los pasos del 2 al 6 del ejemplo anterior por solo dos líneas:

const signInWidget = new SigninBasicWidget(page);
await signInWidget.signInWithBasic({ email: "...", password: "..." });

Configuración de prueba

Algunos escenarios requieren datos o configuración creados previamente. Por ejemplo, es posible que tenga que automatizar el inicio de sesión de usuario con cuentas de redes sociales. Es difícil crear esos datos de forma rápida o sencilla.

Para ello, podría agregar un archivo de configuración especial al escenario de prueba. Los scripts de prueba pueden obtener del archivo los datos necesarios. En función de la canalización de compilación y prueba, las pruebas pueden extraer los secretos de un almacén seguro con nombre.

Este es un ejemplo de un archivo validate.config.json que se almacenaría en la carpeta src del proyecto.

{
    "environment": "validation",
    "urls": {
        "home": "https://contoso.com",
        "signin": "https://contoso.com/signin",
        "signup": "https://contoso.com/signup/"
    },
    "signin": {
        "firstName": "John",
        "lastName": "Doe",
        "credentials": {
            "basic": {
                "email": "johndoe@contoso.com",
                "password": "< password >"
            },
            "aadB2C": {
                "email": "johndoe@contoso.com",
                "password": "< password >"
            }
        }
    },
    "signup": {
        "firstName": "John",
        "lastName": "Doe",
        "credentials": {
            "basic": {
                "email": "johndoe@contoso.com",
                "password": "< password >"
            }
        }
    }
}

Pruebas desatendidas frente a pruebas normales

Los exploradores modernos, como Chrome o Microsoft Edge, permiten ejecutar la automatización tanto en modo sin encabezado como en modo normal. El explorador funciona sin una interfaz gráfica de usuario en el modo desatendido. Todavía lleva a cabo las mismas manipulaciones de página y Document Object Model (DOM). Normalmente, la interfaz de usuario del explorador no es necesaria en las canalizaciones de entrega. En ese caso, la ejecución de pruebas en modo desatendido es una excelente opción.

Al desarrollar un script de prueba, resulta útil ver lo que sucede exactamente en el explorador. Ese es un buen momento para usar el modo normal.

Para cambiar entre modos, cambie la opción headless en el archivo constants.ts. Se encuentra en la carpeta tests del proyecto:

export const LaunchOptions = {
    headless: false
};

Otra opción útil es slowMo. Pausa la ejecución de la prueba entre cada acción:

export const LaunchOptions = {
    slowMo: 200 // milliseconds
};

Ejecutar pruebas

Hay dos maneras integradas de ejecutar pruebas en este proyecto:

Comando npm

npm run test

Explorador de pruebas

Use una extensión del Explorador de pruebas para VS Code. Por ejemplo, el Explorador de pruebas de Mocha tiene una interfaz de usuario cómoda y una opción para ejecutar pruebas automáticamente en cada cambio del código fuente:

Captura de pantalla del Explorador de pruebas de Visual Studio Code

Contenido relacionado

Obtenga más información sobre el portal para desarrolladores:

  • Last updated on