DEV Community: Juan Martin Ruiz

Probé Playwright Agents en E2E: lo que realmente aportan (y dónde fallan)

Juan Martin Ruiz — Thu, 05 Feb 2026 19:26:27 +0000

En este post cuento mi experiencia probando Playwright Agents y qué aportan realmente en un contexto de automatización E2E.

Playwright Agents no se trata solo de “usar IA para escribir tests”, sino de trabajar con distintos agentes, cada uno con un rol concreto dentro del proceso de automatización. En lugar de escribir prompts sueltos, la idea es dividir responsabilidades y darle a cada agente una función clara, logrando más intención, contexto y consistencia.

Por ejemplo, hay agentes enfocados en planificar escenarios, que entienden el flujo funcional y definen qué se debería probar; otros que se encargan de generar los tests, transformando esos escenarios en acciones concretas sobre el navegador; y agentes orientados a ejecutar y validar, que recorren los flujos E2E respetando reglas y buenas prácticas. Esta separación ayuda a mantener el automation más ordenado y fácil de mantener.

El agente planner explora la aplicación y produce un plan de pruebas en formato Markdown.
El agente generator transforma el plan de pruebas de Markdown en scripts en Javascript/TypeScript (por ahora solo disponible en esos lenguajes) archivos de prueba de Playwright
El agente healer ejecuta el script del conjunto de pruebas y repara automáticamente las pruebas fallidas.

Detrás de todo esto aparece MCP (Model Context Protocol), que es lo que permite que cada agente interactúe con Playwright de forma controlada. MCP define qué acciones puede ejecutar cada agente y cómo, evitando comportamientos impredecibles y asegurando que todos operen dentro de límites claros. Gracias a esto, los agentes no actúan “libremente”, sino alineados con criterios de calidad y testing reales.

Instalación

Simplemente con el comando desde el proyecto raiz de Playwright

npx playwright init-agents --loop=vscode

El parámetro --loop=vscode se utiliza cuando los Playwright Agents van a ser controlados desde Visual Studio Code, usando su entorno de chat/IA (por ejemplo, GitHub Copilot Chat u otras extensiones compatibles).

Se genera los archivos markdowns de los agentes, la configuracion de MCP, la carpeta specs donde iran los planes de prueba generados por planner agent y el un archivo seed que sirve para indicarle la URL desde donde comienza la inspeccion el agente planner

Planner Agent

Se va automatizar con https://www.demoblaze.com/ que es un sitio web de ecommerce simulado.

// tests\seed.spec.ts
import { test, expect } from '@playwright/test';

test.describe('Test group', () => {
    test('seed', async ({ page }) => {
        await page.goto('https://www.demoblaze.com/');
    });
});

<!-- specs\product_purchase_test_plan.md -->
# Plan de Pruebas - Flujo de Compra de Producto

## Application Overview

Este plan de pruebas describe escenarios de prueba completos para validar el flujo de compra de productos en la tienda DemoBlaze. Incluye la navegación por categorías, selección de productos, gestión del carrito de compras y proceso de checkout.

## Test Scenarios

### 1. Navegación y Exploración de Productos

**Seed:** `tests/seed.spec.ts`

#### 1.1. Navegación por categorías de productos

**File:** `tests/product-navigation/category-navigation.spec.ts`

**Steps:**
  1. Navegar a la página principal de la tienda
    - expect: La página principal debe mostrarse con las categorías: Phones, Laptops, Monitors
  2. Hacer clic en la categoría 'Phones'
    - expect: Debe mostrarse una lista de productos de teléfonos (Samsung galaxy s6, Nokia lumia 1520, Nexus 6, etc.)
  3. Hacer clic en la categoría 'Laptops'
    - expect: Debe mostrarse una lista de productos de laptops (Sony vaio i5, Sony vaio i7, MacBook air, Dell i7 8gb, etc.)
  4. Hacer clic en la categoría 'Monitors'
    - expect: Debe mostrarse una lista de productos de monitores

Ejemplo del plan de pruebas completo

Generator Agent

// spec: specs/product_purchase_test_plan.md
// seed: tests/seed.spec.ts
// tests\checkout\purchase-success.spec.ts
import { test, expect } from '@playwright/test';

test.describe('Proceso de Checkout', () => {
    test('Completar compra con datos válidos', async ({ page }) => {
        await page.goto('https://www.demoblaze.com/');

        // 1. Agregar el producto 'Samsung galaxy s6' al carrito y navegar al carrito
        await page.getByRole('link', { name: 'Phones' }).click();
        await page.getByRole('link', { name: 'Samsung galaxy s6' }).click();

        // Accept product added confirmation dialog
        page.on('dialog', async dialog => {
            await dialog.accept();
        });

        await page.getByRole('link', { name: 'Add to cart' }).click();

        await page.getByRole('link', { name: 'Cart', exact: true }).click();

        // Wait for cart items to load
        await new Promise(f => setTimeout(f, 3 * 1000));

        // Verify Samsung galaxy s6 is in cart
        await expect(page.getByText('Samsung galaxy s6')).toBeVisible();

        // 2. Hacer clic en el botón 'Place Order'
        await page.getByRole('button', { name: 'Place Order' }).click();

        // Verify the checkout modal appears by checking form fields are visible
        await expect(page.locator('#name')).toBeVisible();

        // 3. Completar el formulario con datos válidos
        await page.locator('#name').fill('John Doe');
        await page.locator('#country').fill('United States');
        await page.locator('#city').fill('New York');
        await page.locator('#card').fill('4111111111111111');
        await page.locator('#month').fill('12');
        await page.locator('#year').fill('2026');
        // 4. Hacer clic en el botón 'Purchase'
        await page.getByRole('button', { name: 'Purchase' }).click();

        // Verify confirmation dialog appears
        await expect(page.getByText('Thank you for your purchase!')).toBeVisible();
        await expect(page.getByText('Name: John Doe')).toBeVisible();

        // Verify purchase details contain required information
        await expect(page.locator('text=Amount:')).toBeVisible();
        await expect(page.locator('text=Id:')).toBeVisible();

        // 5. Cerrar el cuadro de diálogo de confirmación
        await page.getByRole('button', { name: 'OK' }).click();

        // Verify cart is empty after successful purchase
        await page.getByRole('link', { name: 'Cart' }).click();

        // Verify cart is empty - no product rows should exist
        await expect(page.locator('table tbody tr').first()).not.toBeVisible();
    });
});

Si en el futuro es necesario editar el código de los tests generados, lo más conveniente es ajustar el prompt del Generator Agent para que genere el código teniendo en cuenta el patrón de diseño POM (Page Object Model). De esta forma se mejora la reutilización de código y se facilita el mantenimiento, tanto manual como automatizado.
Adjunto un ejemplo de edición del Generator Agent

Healer Agent

Si el test no fue exitoso porque el agent generator omitió un paso o una linea de codigo o hubo algun cambio en el DOM hay que seleccionar el healer agent y el archivo typescript especifico del test

A veces itera muchas veces gerando codigo innecesario y tal vez era sola agregar una linea de codigo para una acción específica que se omitió antes.

Lo que me gustó

Usándolos en la práctica, hay cosas que claramente suman:

Ayudan a reducir trabajo repetitivo, sobre todo al generar flujos E2E comunes
Obligan a pensar mejor la estructura del automation
Mantienen cierto orden y coherencia si el agente está bien definido
Son útiles para explorar escenarios o armar bases de tests más rápido
El plan de pruebas que genera sirve como borrador incluso para el tester manual.

No reemplazan el criterio del QA, pero sí aceleran etapas mecánicas.

Los límites que encontré

Si el agente no tiene reglas claras, puede generar automatización mediocre.
No siempre entiende el contexto funcional como lo haría alguien del negocio. Me pasó que al agente Generator omitió un paso que era simplemente hacer click en un boton para luego hacer otra accion encadenada. Luego el agente "Healer" estuvo iterando varias veces sin encontrar la solución y la tuve que revisar manualmente.
Requieren tiempo de setup y ajuste, no es “plug & play”
Si quieres aplicar POM (Page Object Model) y convenciones lo tienes que especificar en el agente generator.
Tener en cuenta que el agente Generator va generar siempre el code TypeScript dentro de la carpeta tests. Como en el ejemplo anterior el POM lo va a generar dentro de carpeta tests.

Mi sensación general

Playwright Agents no vienen a reemplazar al QA Automation, pero sí pueden ser una buena herramienta si ya tenés bases sólidas y criterios claros.

Bien usados, ayudan a ordenar, acelerar y estandarizar.

Mal usados, solo automatizan el caos más rápido.

Hoy los veo como un complemento interesante, no como una solución mágica. Y como casi todo en testing, el valor no está en la herramienta, sino en cómo y cuándo la usás.

Para quien quiera profundizar un poco más, dejo la documentación oficial de Playwright Agents
Mi repositorio en GitHub, don…

Cómo logré adjuntar videos comprimidos de Cypress en Allure Report

Juan Martin Ruiz — Thu, 02 Oct 2025 17:08:12 +0000

Cuando empecé a integrar Cypress con Allure Reports, me encontré con una limitación inesperada: los videos de ejecución no se adjuntaban correctamente al reporte.

La situación era frustrante porque Cypress sí generaba los videos, pero Allure lo hacía con los archivos sin comprimir, lo que aumentaba mucho el peso de los reportes.

npx cypress run
npx allure generate allure-results --clean
npx allure open

En este post quiero contar el problema, el análisis y la solución que implementé, por si le sirve a alguien más que esté atravesando lo mismo.

El problema

Por defecto, Cypress genera un video por cada spec ejecutado y lo comprime una vez finalizado el run. Si tenemos activado con video: true y videoCompression: true en cypress.config.js
Sin embargo, cuando usamos @shelex/cypress-allure-plugin, los archivos que quedaban en allure-results eran los videos sin comprimir.

La consecuencia:

Reportes con videos pesados.

El análisis

Revisando la configuración encontré dos puntos clave:

Cypress primero genera un video “crudo” y después lo reemplaza por uno comprimido. El problema es que Allure a veces copiaba el video crudo antes de la compresión.
Dependiendo de cómo configures after:spec y after:run, podés controlar si se eliminan videos de tests pasados o si se reemplazan manualmente los archivos que Allure guarda.

La solución

Decidí crear un script en la carpeta util que se ejecuta en el evento after:run y reemplaza en allure-results los videos por las versiones comprimidas que Cypress deja en cypress/videos.

Ejemplo:

// cypress.config.js
const { defineConfig } = require("cypress");
const allureWriter = require('@shelex/cypress-allure-plugin/writer');

const { attachCompressedVideosToAllure } = require('./cypress/utils/attachCompressedVideosToAllure');

module.exports = defineConfig({
  e2e: {
    setupNodeEvents(on, config) {
      allureWriter(on, config);

      on('after:run', (runResults) => attachCompressedVideosToAllure(runResults, { resultsDir: 'allure-results' }));

      return config;
    },
  },
  env: {
    allure: true,
    allureAddVideoOnPass: false
  },
  video: true,  
  videosFolder: 'cypress/videos',
  videoCompression: 32,
  screenshotOnRunFailure: false
});

//cypress\utils\attachCompressedVideosToAllure.js
const { promises: fsp } = require('fs');
const path = require('path');

async function attachCompressedVideosToAllure(runResults, { resultsDir = 'allure-results' } = {}) {
  if (!runResults?.runs?.length) return;
  const resultsAbs = path.resolve(resultsDir);

  let jsonFiles = [];
  try {
    jsonFiles = (await fsp.readdir(resultsAbs)).filter(f => f.endsWith('.json'));
  } catch { return; }

  const index = (await Promise.all(jsonFiles.map(async (f) => {
    try { return { file: f, fullPath: path.join(resultsAbs, f), data: JSON.parse(await fsp.readFile(path.join(resultsAbs, f), 'utf8')) }; }
    catch { return null; }
  }))).filter(Boolean);

  await Promise.all(runResults.runs.map(async (r) => {
    const video = r?.video;
    if (!video) return;
    try {
      const specName = path.basename(r.spec?.relative || r.spec?.name || video);
      const specKey  = (r.spec?.relative || specName).replace(/[\/\\]/g, '__');
      const target   = `video__${specKey}.mp4`;
      await fsp.copyFile(video, path.join(resultsAbs, target));

      const related = index.filter(it => JSON.stringify(it.data?.labels || []).includes(specName));
      await Promise.all(related.map(async (it) => {
        let touched = false;
        for (const att of (it.data.attachments || [])) {
          if (att?.type === 'video/mp4') { att.source = target; touched = true; }
        }
        if (touched) await fsp.writeFile(it.fullPath, JSON.stringify(it.data), 'utf8');
      }));
    } catch (e) {
      console.error('[after:run]', e?.message);
    }
  }));
}

module.exports = { attachCompressedVideosToAllure };

npx cypress run
npx allure generate allure-results --clean
npx allure open

De adjuntar videos 1.2 MB pasamos a adjuntar videos 300 KB

Eliminar videos de pruebas exitosas (opcional)

Si querés que los videos de pruebas exitosas se eliminen automáticamente para mantener el reporte más limpio, podés agregar un script dentro del evento after:spec

//cypress\utils\deleteVideoIfSpecPassed.js
const { promises: fsp } = require('fs');

async function deleteVideoIfSpecPassed(_spec, results) {
  if (!results?.video) return;
  const hasFailures =
    (results.tests || []).some(t => (t.attempts || []).some(a => a.state === 'failed')) ||
    (results.stats?.failures > 0);
  if (!hasFailures) {
    try { await fsp.unlink(results.video); }
    catch (e) { console.warn('[after:spec] No se pudo borrar el video:', e?.message); }
  }
}

module.exports = { deleteVideoIfSpecPassed };

Llamamos a deleteVideoIfSpecPassed dentro del evento after:spec

//cypress.config.js
const { defineConfig } = require("cypress");
const allureWriter = require('@shelex/cypress-allure-plugin/writer');

const { deleteVideoIfSpecPassed } = require('./cypress/utils/deleteVideoIfSpecPassed');
const { attachCompressedVideosToAllure } = require('./cypress/utils/attachCompressedVideosToAllure');

module.exports = defineConfig({
  e2e: {
    setupNodeEvents(on, config) {
      allureWriter(on, config);

      on('after:spec', deleteVideoIfSpecPassed);
      on('after:run', (runResults) => attachCompressedVideosToAllure(runResults, { resultsDir: 'allure-results' }));

      return config;
    },
  },
  env: {
    allure: true,
    allureAddVideoOnPass: false
  },
  video: true,  
  videosFolder: 'cypress/videos',
  videoCompression: 32,
  screenshotOnRunFailure: false
});

Resultado

Las versiones comprimidas de Cypress ahora se adjuntan correctamente en Allure Report, lo que hace que los reportes sean más livianos y fáciles de compartir.
Los videos de pruebas exitosas se eliminan automáticamente para mantener el reporte más limpio.

Reflexión

Muchas veces, cuando integramos herramientas, aparecen estos “detalles” que no están documentados en ningún lado.

Resolverlo me obligó a entender mejor cómo Cypress maneja los videos y cómo Allure gestiona los attachments.

Ahora que lo tengo funcionando, quise compartirlo porque seguramente más de uno se va a encontrar con el mismo dolor de cabeza.

Si querés ver el código completo y en contexto, lo publiqué en este repositorio: https://github.com/jmr85/cypress-video-allure-reports

Healenium Web: self-healing para tus localizadores

Juan Martin Ruiz — Mon, 31 Mar 2025 19:07:26 +0000

Quiero compartirles el proyecto Healenium Web Automation, un repositorio que creé para demostrar cómo mejorar la estabilidad de las pruebas automatizadas en Selenium usando auto-healing de localizadores. Si alguna vez tus tests, web scraping o automatización de tareas fallaron porque un desarrollador cambió un ID o XPath en la página, esta guía es para vos. A continuación te explicaré qué es Healenium Web Automation, los problemas comunes que resuelve, sus beneficios clave y cómo usarlo paso a paso.

¿Qué es Healenium Web Automation?

Healenium Web Automation es un proyecto de ejemplo (open source) que integra la librería Healenium en una suite de pruebas Selenium. Healenium es una extensión de Selenium que actúa como un “curador” automático de localizadores rotos. En otras palabras, si un elemento web cambia (por ejemplo, cambió su atributo id, nombre de campo, etc.) y tu script de Selenium no lo encuentra, Healenium detectará la falla en tiempo real y buscará el elemento correcto de forma inteligente, reemplazando el localizador quebrado por uno válido sobre la marcha. Healenium Web Automation pone en práctica esta magia usando un formulario web como caso de prueba. El proyecto está escrito en Java con Maven y emplea Selenium WebDriver junto con el patrón Page Object Model para organizar los elementos de la página. En resumen, es una demo completa de cómo añadir Healenium a tus pruebas existentes para hacerlas más robustas ante cambios inesperados en la interfaz.

Problemas comunes en la automatización que resuelve

Seguro te resultan familiares estos dolores de cabeza, localizadores frágiles: Construimos nuestros tests identificando elementos por id, xpath, css, etc. Pero cuando la aplicación cambia (nuevas versiones, rediseños, cambios de etiquetas), esos selectores dejan de funcionar y los tests fallan.

Mantenimiento constante: Pasas horas arreglando scripts rotos debido a cambios mínimos en la UI. Un simple cambio de texto o de atributo puede inutilizar decenas de pruebas, haciéndolas inestables y costosas de mantener.
Healenium aborda directamente estos problemas. En lugar de fallar inmediatamente cuando un elemento no coincide, intenta encontrar automáticamente el nuevo elemento equivalente. Esto significa menos tests fallidos por causas no relacionadas al producto, menos falsas alarmas, y una mayor confianza en tus suites de regresión aunque la aplicación evolucione.

Beneficios clave de Healenium Web

Implementar Healenium-Web en tus pruebas (tal como muestra Healenium Web Automation) trae múltiples beneficios:
Auto-healing de localizadores: Si un elemento cambia en la página, Healenium detecta el NoSuchElementException y busca un reemplazo apropiado en tiempo de ejecución. Tus tests se “curan” solos en lugar de fallar, reduciendo la fragilidad.
Ejemplo listo para usar: Este proyecto sirve como plantilla práctica. Incluye todo lo necesario (configuraciones Maven, Docker, TestNG, estructura de código con Page Objects, etc.) para que puedas experimentar rápidamente. En lugar de configurar desde cero, tienes un entorno funcional donde puedes ver cómo se integra Healenium con Selenium de manera correcta.
Reportes automáticos detallados: Al finalizar la ejecución de pruebas, Healenium genera un informe visual de los localizadores curados. El reporte muestra qué selector falló y con cuál valor fue reemplazado, junto a capturas de pantalla del elemento en la página y un indicador de éxito. Esto te permite verificar si la “curación” fue correcta y dar feedback para mejorar el algoritmo.
Integración sencilla y flexible: Añadir Healenium a un framework existente es muy fácil. Básicamente se agrega la dependencia al pom.xml

<!-- https://mvnrepository.com/artifact/com.epam.healenium/healenium-web -->
    <dependency>
        <groupId>com.epam.healenium</groupId>
        <artifactId>healenium-web</artifactId>
        <version>3.5.4</version>
    </dependency>

y se envuelve el WebDriver existente en un SelfHealingDriver con una línea de código. Por ejemplo:

WebDriver delegate = new ChromeDriver();
SelfHealingDriver driver = SelfHealingDriver.create(delegate);
//crear SelfHealingDriverWait - wrapper de WebDriverWait
WebElement element = new SelfHealingDriverWait(driver, Duration.ofSeconds(10))
            .until(ExpectedConditions.visibilityOfElementLocated(By.id("wait_new_element")));

¿Cómo funciona técnicamente Healenium?

Para lograr la magia del auto-healing, Healenium sigue una arquitectura cliente-servidor: Lado cliente (en tu prueba): Healenium proporciona un wrapper de WebDriver llamado SelfHealingDriver. Esta clase implementa la interfaz de Selenium WebDriver, pero internamente intercepta las llamadas a findElement. Cuando intentas encontrar un elemento y Selenium lanza una excepción de elemento no encontrado, el SelfHealingDriver interviene. ¿Qué hace? Ejecuta un algoritmo de comparación de árboles DOM (tree comparison) para analizar la página actual en busca de un elemento que coincida con el antiguo. Utiliza heurísticas y criterios de similitud (incluso podría considerarse un enfoque de machine learning) para identificar el nuevo selector más parecido al original. Por ejemplo, si antes buscabas un botón por el texto "Continue to checkout" y ahora el botón dice "Checkout", Healenium es capaz de encontrarlo asumiendo que la posición en el DOM o vecinos cercanos son similares, obteniendo un score de similitud. Si el algoritmo encuentra un candidato confiable (por encima de un puntaje umbral configurable), devuelve ese elemento como si nada hubiera pasado. Tu script de automatización continúa con el elemento actualizado, ¡y probablemente ni notes la diferencia! Healenium incluso puede intentar múltiples estrategias (varios recovery-tries) hasta dar con el elemento correcto. Lado servidor (backend de Healenium): Paralelamente, el cliente se comunica con un servicio backend (que corre en un contenedor Docker) para registrar y obtener información de los localizadores. Este backend utiliza una base de datos PostgreSQL para almacenar los selectores antiguos y los nuevos encontrados, junto con metadatos útiles (DOM de la página, nombre de la clase y método de test donde ocurrió, captura de pantalla del estado, etc.). Gracias a esto, Healenium construye un historial de cambios de elementos. Al finalizar la ejecución, el backend es quien genera el reporte de resultados de curación al que hacíamos referencia en los beneficios. Ajustes y configuraciones: Puedes controlar el comportamiento de Healenium mediante un archivo de propiedades (healenium.properties). Por ejemplo:

recovery-tries = 1
score-cap = .6
heal-enabled = true
hlm.server.url = http://localhost:7878
hlm.imitator.url = http://localhost:8000

recovery-tries indica cuántas veces intentar curar un mismo elemento (por defecto 1).
score-cap es el puntaje mínimo de coincidencia requerido (0.5 sería 50% de similitud) para aceptar un nuevo localizador.
heal-enabled permite activar/desactivar la autocuración globalmente (útil para hacer pruebas comparativas).
hlm.server.url y hlm.imitator.url apuntan al servidor de Healenium (si lo corres local, normalmente localhost:7878).
Con esta arquitectura, Healenium actúa como un “seguro” para tus scripts automatizados. Si todo está bien, usa los localizadores tal cual los escribiste. Si algo cambió, entra en acción para salvar la prueba. Ahora que entendemos la teoría, pasemos a la práctica: ¿cómo puedes probar tú mismo Healenium Web Automation?

Guía paso a paso: Probando Healenium Web Automation

A continuación te presento una guía sencilla para poner en marcha el proyecto Healenium Web Automation y comprobar sus capacidades de auto-healing. Asumo que tienes conocimientos intermedios de Java/Selenium y un ambiente preparado con Java y Maven.

Clona el repositorio y prepara el entorno: Empieza por clonar el repositorio desde GitHub git clone https://github.com/jmr85/healenium-web-automation.git (o descargando el ZIP). Luego, abre el proyecto en tu IDE favorito (por ejemplo, IntelliJ IDEA o tambien VSC) y asegúrate de tener Java (JDK 8+, yo tengo 21) y Maven instalados. Este proyecto incluye un conjunto de pruebas de ejemplo y la configuración necesaria de Healenium.
Instala los prerrequisitos (Docker): Healenium requiere ejecutar un pequeño servidor backend y una base de datos PostgreSQL. Para facilitar esto, el repo incluye un archivo Docker Compose que levanta ambos servicios fácilmente. Asegúrate de tener Docker instalado y en ejecución en tu máquina. No necesitas configurar nada manualmente en la base de datos; el Docker Compose ya contiene un script de inicialización para crear las tablas necesarias de Healenium.

infra\db\sql\init.sql

CREATE SCHEMA healenium AUTHORIZATION healenium_user;
GRANT USAGE ON SCHEMA healenium TO healenium_user;

Inicia el backend de Healenium: Abre una terminal en la carpeta del proyecto (donde esté el archivo docker-compose.yml provisto en el subdirectorio infra o en la raíz del repo). Ejecuta el comando:

docker-compose up -d

Esto descargará las imágenes Docker necesarias (el servidor de Healenium y Postgres) y levantará los contenedores en segundo plano. Una vez terminado, puedes verificar que todo esté corriendo con docker ps: deberías ver dos contenedores, uno para hlm-backend de Healenium y otro para postgres.

Ejecuta los tests por primera vez: Con el backend listo, es momento de correr la suite de pruebas. Puedes hacerlo desde tu IDE (ejecutando la clase de pruebas principal o usando la configuración Maven) o directamente vía terminal con Maven: mvn clean install (descarga las dependencias y ejecuta el test). En esta ejecución inicial, los tests utilizarán los localizadores tal como están definidos y, si todo está correcto, deberían pasar sin problemas. Healenium en este primer recorrido almacenará la información base de los elementos en su base de datos (pero como no hubo cambios, en realidad no tendrá que “curar” nada aún). Observa la consola al final: verás un mensaje de BUILD SUCCESS si todo salió bien, junto a la URL donde estará disponible el reporte de Healenium, algo como: Report available at http://localhost:7878/healenium/report/.

Simula un cambio en la interfaz: Para apreciar el poder de Healenium, vamos a forzar un cambio de localizadores. Supongamos que estamos probando un formulario de registro (campos de da datos de una persona firstName, lastName, email, etc.) y el desarrollador decidió renombrar algunos IDs en el HTML. En nuestro ejemplo, abre el archivo de recursos HTML src\main\resources\form-web\index.html y modifica intencionalmente algunos identificadores. Por ejemplo, donde antes el campo tenía id="firstName" cámbialo a id="firstName1", o si un botón tenía el texto "Submit", cámbialo a "Save". (Estos cambios simulan una nueva versión de la página). Guarda los cambios.

Ejecuta los tests nuevamente con Healenium activo: Vuelve a correr el test esta vez con mvn clean test o mvn clean test -Dtest=FormTest. Esta vez, sin Healenium nuestros tests seguramente fallarían (porque los localizadores ya no coinciden con el DOM actualizado). Pero gracias a Healenium, la ejecución debería pasar exitosamente. El SelfHealingDriver detectará cada NoSuchElementException y buscará el elemento correcto en base a la info almacenada y el DOM actual. Por ejemplo, encontrará que el nuevo ID "firstName1" coincide con el antiguo "firstName" con alta probabilidad, lo usará, y la prueba continuará como si nada. Healenium registrará cada “curación” realizada en la base de datos y marcará la prueba como exitosa. Revisa el reporte de Healenium: Al finalizar esta segunda ejecución, deberías ir a la URL del Healing Report generado http://localhost:7878/healenium/report/. Copia ese enlace y ábrelo en tu navegador web.

Este reporte web muestra el detalle de todas las curaciones realizadas durante la prueba. Verás una lista de cada elemento (Element) con su contexto (por ejemplo, la página y el nombre del método de test donde ocurrió), el valor fallido del localizador y el nuevo valor curado, el tipo de selector (By) utilizado, una captura de pantalla en miniatura y una columna de Success con un interruptor. El interruptor te permite marcar manualmente si consideras que la curación fue correcta o no, lo cual es útil para retroalimentar y mejorar el algoritmo en futuras ejecuciones. Como puedes apreciar en el reporte, Healenium Web Automation logró reemplazar correctamente los selectores cambiados por los nuevos valores, permitiendo que el flujo del test no se detuviera.

Por otro lado, podemos ver el archivo de test.log (configurado en src\test\resources\simplelogger.properties) luego de ejecutar el test.

org.slf4j.simpleLogger.log.healenium=debug

org.slf4j.simpleLogger.logFile=test.log

org.slf4j.simpleLogger.defaultLogLevel=info
org.slf4j.simpleLogger.showDateTime=true
org.slf4j.simpleLogger.dateTimeFormat=yyyy-MM-dd HH:mm:ss

test.log

2025-03-31 15:06:34 [main] INFO com.web.healing.listeners.TestListener - Test suite started: Surefire test
2025-03-31 15:06:38 [main] DEBUG healenium - [Init] sessionKey: fdb944f9380f05c03e18096a35494b79, serverUrl: http://localhost:7878/healenium, imitateUrl: http://localhost:8000/imitate
2025-03-31 15:06:38 [main] DEBUG healenium - [Get Elements] Request: (GET) /elements
2025-03-31 15:06:38 [main] DEBUG healenium - [Init Report] Request: (POST) /report/init/fdb944f9380f05c03e18096a35494b79
2025-03-31 15:06:38 [main] INFO com.web.healing.listeners.TestListener - Test started: testFormWithAllFields
2025-03-31 15:06:38 [main] WARN healenium - Failed to find an element using locator By.id: firstName
2025-03-31 15:06:38 [main] WARN healenium - Reason: no such element: Unable to locate element: {"method":"css selector","selector":"#firstName"}
  (Session info: chrome=134.0.6998.178)
For documentation on this error, please visit: https://www.selenium.dev/documentation/webdriver/troubleshooting/errors#no-such-element-exception
Build info: version: '4.25.0', revision: '8a8aea2337'
System info: os.name: 'Windows 11', os.arch: 'amd64', os.version: '10.0', java.version: '21.0.6'
Driver info: org.openqa.selenium.chrome.ChromeDriver
Command: [fdb944f9380f05c03e18096a35494b79, findElement {value=firstName, using=id}]
Capabilities {acceptInsecureCerts: false, browserName: chrome, browserVersion: 134.0.6998.178, chrome: {chromedriverVersion: 134.0.6998.165 (fd886e2cb29..., userDataDir: C:\Users\juani\AppData\Loca...}, fedcm:accounts: true, goog:chromeOptions: {debuggerAddress: localhost:61872}, networkConnectionEnabled: false, pageLoadStrategy: normal, platformName: windows, proxy: Proxy(), se:cdp: ws://localhost:61872/devtoo..., se:cdpVersion: 134.0.6998.178, setWindowRect: true, strictFileInteractability: false, timeouts: {implicit: 0, pageLoad: 300000, script: 30000}, unhandledPromptBehavior: dismiss and notify, webauthn:extension:credBlob: true, webauthn:extension:largeBlob: true, webauthn:extension:minPinLength: true, webauthn:extension:prf: true, webauthn:virtualAuthenticators: true}
Session ID: fdb944f9380f05c03e18096a35494b79
2025-03-31 15:06:38 [main] DEBUG healenium - [Get Reference Elements] Request. Locator: firstName, Command: findElement, Url: file:///C:/Dev/Java/Healenium/healenium-web-automation/target/classes/form-web/index.html
2025-03-31 15:06:39 [main] WARN healenium - Trying to heal...
2025-03-31 15:06:39 [main] WARN healenium - Using healed locator: Scored(score=0.9857142857142858, value=By.cssSelector: input#firstName1)
2025-03-31 15:06:39 [main] DEBUG healenium - [Save Healed Elements] Locator(value=input#firstName1, type=By.cssSelector)
2025-03-31 15:06:41 [main] DEBUG healenium - [Save Elements] By: By.id, Locator: lastName, Command: findElement, URL: file:///C:/Dev/Java/Healenium/healenium-web-automation/target/classes/form-web/index.html
2025-03-31 15:06:41 [main] DEBUG healenium - [Save Elements] By: By.id, Locator: email, Command: findElement, URL: file:///C:/Dev/Java/Healenium/healenium-web-automation/target/classes/form-web/index.html
2025-03-31 15:06:41 [main] DEBUG healenium - [Save Elements] By: By.id, Locator: male, Command: findElement, URL: file:///C:/Dev/Java/Healenium/healenium-web-automation/target/classes/form-web/index.html
2025-03-31 15:06:41 [main] DEBUG healenium - [Save Elements] By: By.id, Locator: mobile, Command: findElement, URL: file:///C:/Dev/Java/Healenium/healenium-web-automation/target/classes/form-web/index.html
2025-03-31 15:06:41 [main] DEBUG healenium - [Save Elements] By: By.id, Locator: dateOfBirth, Command: findElement, URL: file:///C:/Dev/Java/Healenium/healenium-web-automation/target/classes/form-web/index.html
2025-03-31 15:06:41 [main] DEBUG healenium - [Save Elements] By: By.id, Locator: subjects, Command: findElement, URL: file:///C:/Dev/Java/Healenium/healenium-web-automation/target/classes/form-web/index.html
2025-03-31 15:06:41 [main] DEBUG healenium - [Save Elements] By: By.id, Locator: currentAddress, Command: findElement, URL: file:///C:/Dev/Java/Healenium/healenium-web-automation/target/classes/form-web/index.html
2025-03-31 15:06:42 [main] DEBUG healenium - [Save Elements] By: By.id, Locator: country, Command: findElement, URL: file:///C:/Dev/Java/Healenium/healenium-web-automation/target/classes/form-web/index.html
2025-03-31 15:06:42 [main] DEBUG healenium - [Save Elements] By: [By.xpath, Locator: .//option[normalize-space(.) = "Argentina"]] on page null, Command: findElements, URL: file:///C:/Dev/Java/Healenium/healenium-web-automation/target/classes/form-web/index.html
2025-03-31 15:06:42 [main] DEBUG healenium - [Save Elements] By: By.xpath, Locator: //button[text()='Submit'], Command: findElement, URL: file:///C:/Dev/Java/Healenium/healenium-web-automation/target/classes/form-web/index.html
2025-03-31 15:06:42 [main] INFO com.web.healing.listeners.TestListener - Test passed: testFormWithAllFields
2025-03-31 15:06:42 [main] INFO com.web.healing.listeners.TestListener - Test suite finished: Surefire test

Explora el reporte Allure (adicional): Además del reporte de curación propio de Healenium, el proyecto incluye integración con Allure para reportar la ejecución general de las pruebas. Puedes generar el reporte con el historial de pasos de test, screenshots, etc. Ejecuta el comando allure serve target/allure-results una vez finalizados los tests. Se abrirá un informe interactivo donde podrás ver cada caso de prueba, incluyendo las acciones realizadas y evidencias. Es otra forma de inspeccionar que las pruebas corrieron correctamente. Ten en cuenta que Allure mostrará los pasos tal cual están en el código; la “curación” sucede tras bambalinas, pero podrás ver que no hubo errores en los pasos gracias a Healenium.

Personalmente, desarrollar Healenium Web Automation ha sido una experiencia muy gratificante. Me permitió comprobar de primera mano cómo una herramienta de auto-healing puede reducir drásticamente la fragilidad de nuestras pruebas Selenium. Ya no tengo que temer que un simple cambio de ID derrumbe mi suite de regresión: Healenium actúa como un escudero fiel, adaptándose a los cambios de la UI en tiempo real y manteniendo mis tests en verde. Te animo a que pruebes este proyecto y, más importante, que consideres integrar Healenium (o una solución similar) en tus propios frameworks de automatización. El repositorio está disponible en GitHub para que curiosees el código y lo adaptes a tus necesidades: https://github.com/jmr85/healenium-web-automation

Si integras Healenium, recuerda igualmente mantener buenas prácticas en tus localizadores (usar atributos estables cuando sea posible, evitar selectores extremadamente frágiles, etc.). Healenium es una red de seguridad, pero un código bien diseñado siempre es la primera línea de defensa. También puedes aprovechar el plugin de Healenium para IntelliJ: este te permite actualizar automáticamente tus selectores en el código con solo un click, tomando los valores curados desde el reporte (muy útil para refactorizar rápidamente). Espero que esta guía te haya resultado útil. Healenium Web es tan solo un paso hacia pruebas más resilientes. Con herramientas así, podemos dedicar más tiempo a crear nuevos tests (o scripts de automatización) y menos a reparar los existentes.

Tutorial Robot Framework: Instalación y primeros pasos

Juan Martin Ruiz — Fri, 07 Mar 2025 20:07:20 +0000

Aclaración: Este tutorial fue originalmente creado para uso interno en la empresa mientras estudiaba el framework. Es del 2020, por lo que verán que instalé la herramienta en Windows 10; sin embargo, la instalación y la forma de trabajar no han cambiado mucho. Decidí compartirlo porque es una pena tenerlo perdido entre mis notas. Quizás lo actualice en el futuro.

Robot Framework es un marco de automatización de código abierto genérico. Se puede utilizar para la automatización de pruebas y la automatización de procesos robóticos (RPA).
Cuenta con un soporte activo, y muchas empresas líderes en la industria lo utilizan en su desarrollo de software.
Robot Framework es abierto y extensible y se puede integrar con prácticamente cualquier otra herramienta para crear soluciones de automatización potentes y flexibles. Ser de código abierto también significa que Robot Framework es de uso gratuito sin costos de licencia.
Tiene una sintaxis sencilla y utiliza palabras clave legibles por humanos. Sus capacidades se pueden ampliar mediante bibliotecas implementadas con Python o Java. El marco tiene un ecosistema rico a su alrededor, que consta de bibliotecas y herramientas que se desarrollan como proyectos separados.
El proyecto Robot Framework está alojado en GitHub, donde puede encontrar más documentación, código fuente y seguimiento de problemas. Las descargas se alojan en PyPI.
Robot Framework es independiente del sistema operativo y la aplicación. El marco principal se implementa con Python y también se ejecuta en Jython (JVM) e IronPython (.NET).
Robot Framework en sí es un software de código abierto publicado bajo Apache License 2.0 , y la mayoría de las bibliotecas y herramientas del ecosistema también son de código abierto. El marco se desarrolló inicialmente en Nokia Networks y fue de código abierto en 2008.
https://robotframework.org/

¿Qué es un framework para automatizar pruebas?

▸ Es un lenguaje donde se puede escribir las pruebas.
▸ Tiene rutinas de códigos.
▸ Se puede reusar estos códigos para diferentes secciones de una
pagina.
▸ Soporta librerías que llevan a cabo diferentes acciones (Probar
Interfaces Web, API, Bases de Datos, Móviles)
▸ Tiene una capa de abstracción que te permite escribir los
casos en lenguaje natural.
▸ Permite correr casos con el uso de Etiquetas.
▸ Te permite seleccionar los casos por Suites o configuraciones.
▸ Permite la integración para configurar los códigos de las
pruebas y correrlos en diferentes horarios.
▸ Realiza los reportes con los resultados, e incluye los pasos, las
horas, te permite buscar en los resultados e incluye
impresiones de pantalla cuando algo no funciona.

¿Por qué Robot Framework?

Permite una sintaxis tabular fácil de usar para crear casos de prueba de manera uniforme.
Proporciona la capacidad de crear palabras clave reutilizables de nivel superior a partir de las palabras clave existentes.
Proporciona informes de resultados y registros fáciles de leer en formato HTML.
Es independiente de la plataforma y la aplicación.
Proporciona una API de biblioteca simple para crear bibliotecas de prueba personalizadas que se pueden implementar de forma nativa con Python o Java.
Proporciona una interfaz de línea de comandos y archivos de salida basados en XML para la integración en la infraestructura de construcción existente (sistemas de integración continua).
Brinda soporte para Selenium para pruebas web, pruebas de GUI de Java, procesos en ejecución, Telnet, SSH, etc.
Admite la creación de casos de prueba basados en datos .
Tiene soporte incorporado para variables , práctico particularmente para pruebas en diferentes entornos.
Proporciona etiquetado para categorizar y seleccionar casos de prueba que se ejecutarán.
Permite una fácil integración con el control de código fuente: las suites de prueba son solo archivos y directorios que se pueden versionar con el código de producción.
Proporciona caso de prueba y la prueba de la suite de instalación y el desmontaje -level.
La arquitectura modular admite la creación de pruebas incluso para aplicaciones con varias interfaces diversas.

https://robotframework.org/robotframework/latest/RobotFrameworkUserGuide.html#id498

Origen e historia

2005:
‣ Desarrollado en Finlandia
‣ Básicamente nace como idea de tésis de maestria de Pekka Klärck y para Nokia.
2008:
‣ Se lanza la version 2.0 como versión de código abierto.
2020:
‣ Versión actual: 3.2.2

Funcionalidades y capacidades

‣ Multiplataforma, se puede usar tanto en Windows como Mac y Linux
‣ Es un lenguaje basado en Keywords y con capacidades de inserción de datos, según lo requerido
en la prueba.
‣ Lenguaje Natural de acuerdo al área de negocios
‣ Librerias:

Instalación en Windows 10

Ir a la pagina del lenguaje Python: https://www.python.org/
Seleccionar versión mayor a 3

Una vez descargado ejecutar el instalador

Dejar tildado el checkbox “Install launcher for all users” y también “Add Python 3.8 to PATH” esta opción permitirá ejecutar comando de python o del framework sin ser administrador.
Luego seleccionar “Install Now”

Hacer click en “Disable path length limit”

Luego de finalizada la instalación hacer click en botón “Close”

Verificar versión instalada de python

La instalación de python viene por defecto con el instalador de paquetes/librerías llamado “pip”, similar a npm de node y NuGet de .NET

Con “pip” instalar robot framework

pip install robotframework

Se ha instalado correctamente robotframework.
Luego de instalar correctamente puede aparecer este mensaje de warning, detectó que el “pip” instalado por defecto tiene una versión actualizada disponible, como dice en el warning actualizamos con el comando:

pip install --upgrade pip

Para saber los paquetes que instalamos:

pip list

Otra manera con el comando del framework:

robot --version

Instalar la librería Selenium:

pip install --upgrade robotframework-seleniumlibrary

Verificar la librería instalada en la lista de paquetes:

Configurar Drivers de navegadores:

Navegadores soportados

Chromedriver

Ir a https://chromedriver.chromium.org/:

Luego de haber descargado el archivo descomprimir el zip, luego cortar y pegar el .exe a la carpeta de PATH:
C:\Users\jruiz\AppData\Local\Programs\Python\Python38-32\Scripts

Firefox

Descargar el driver en: https://github.com/mozilla/geckodriver/releases

Luego mismo procedimiento de chrome, después de descomprimir el zip cortar y pegar el .exe a la carpeta de PATH:
C:\Users\jruiz\AppData\Local\Programs\Python\Python38-32\Scripts

Opera

Primero tener instalado la ultima versión del navegador Opera
Luego descargar driver en: https://github.com/operasoftware/operachromiumdriver/releases

Editores de código

https://robotframework.org/#tools

Visual Studio Code

Instalar plugins para Visual Studio Code

Robot Framework Intellisense

Ahora aparece resaltado la sintaxis

Robotframework Debugger

Crear nuevo proyecto

Luego de instalar los plugins no hace falta otra configuracion, para comenzar a escribir los casos de pruebas hay que crear una nueva carpeta y dentro crear por ejemplo el archivo primer-automatizacion.robot

Test Case

*** Settings ***
Documentation       Existe en un documento de texto los pasos manuales
...                 Esta es mi primera automatizacion
Library             SeleniumLibrary

*** Variables ***
${palabraABuscar}   clima hoy
${Navegador}    chrome
${URL}      https://www.google.com/

*** Keywords ***
Abrir Navegador y Esperar Logo
    #se tiene que separar por tabulacion (o tres veces barra espaciadora) cada nueva linea
    #tambien se tiene que separar con tabulacion en el comando y el parametro
    Open Browser    ${URL}     ${Navegador}
    Wait Until Element Is Visible   xpath=//*[@id="hplogo"]

*** Test Cases ***
Busqueda de palabras en google
    Abrir Navegador y Esperar Logo
    Input Text      xpath=//*[@id="tsf"]/div[2]/div[1]/div[1]/div/div[2]/input     ${palabraABuscar}
    Click Element       xpath=//*[@id="hplogo"]
    Click Element       xpath=//*[@id="tsf"]/div[2]/div[1]/div[3]/center/input[1]
    Title Should Be     ${palabraABuscar} - Buscar con Google
    Page Should Contain     ${palabraABuscar}
    Close Browser

Hacer click en el botón de búsqueda sin escribir palabras en Google
    Abrir Navegador y Esperar Logo
    Click Element       xpath=//*[@id="tsf"]/div[2]/div[1]/div[3]/center/input[1]
    Title Should Be     Google
    Close Browser

Para ejecutar este caso prueba desde la consola de windows:

robot primer-automatizacion.robot

Ejecutar un caso específico

robot -t "Verify that a valid user can login to the system" LoginTest.robot

Sintaxis

La sintaxis consta basicamente de 4 segmentos
Settings, Variables, Keywords y Test Cases

Settings

En ese segmento a sintaxis suele ir:
- Documentacion
- Importacion de Resources: Una página de recursos es un lugar en donde puedo buscar elementos comunes que tengo para todas las pruebas . Luego para llamar a esa pagina tengo que decir en donde esta ese archivo o librería para luego utilizarlo.
- Por ejemplo los elementos de setting son muy común o recurrentes porque en todos los lugares voy a usar la librería.
- Library: se importan las librerias, la mas conocida SeleniumLibrary.
*** Settings ***
Documentation       Existe en un documento de texto los pasos manuales
...                 Esta es mi primera automatizacion
Library             SeleniumLibrary
Resource            recursos.robot

Variables

Se definen las variables a utilizar dentro de un test y tambien keywords

*** Variables ***
${palabraABuscar}   clima hoy
${Navegador}    chrome
${URL}      https://www.google.com/

las variables no se reducen a tipo string, hay mas: https://robotframework.org/robotframework/latest/RobotFrameworkUserGuide.html#using-variables

Keywords (palabras clave)

Los keywords son las acciones como:
Open Browser

Wait Until Element Is Visible

Input Text

Click Element

Click Element

Title Should Be

Page Should Contain

Close Browser
Se pueden armar keywords para armar mis propios procesos

Ejemplo importando Resource (importacion de cualquier archivo)

Robot Framework y la libreria Selenium

Selenium Library es una librería externa de Robot Framework para probar
interfaces de aplicaciones web.
Se basa en Keywords que llevan a cabo diferentes funciones, según lo que
requieras en tu caso de prueba, entonces debes seleccionar cual KEYWORD
funciona mejor para las acciones que tengas en tu caso de prueba

Como funcionan los keywords

Hay una libreria que incluye todos los keywords que podes encontrar acá:
https://robotframework.org/SeleniumLibrary/SeleniumLibrary.html
Ahi encontrarás como usar cada keyword y cada valor del argumento debe estar
separado por dos o más espacios.

Locators (Localización de elementos)

Todas las palabras clave en SeleniumLibrary que necesitan interactuar con un elemento en una página web toman un argumento normalmente llamado locator que especifica cómo encontrar el elemento. La mayoría de las veces, el localizador se proporciona como una cadena utilizando la sintaxis del localizador que se describe a continuación.

Sintaxis del localizador

SeleniumLibrary admite la búsqueda de elementos en función de diferentes estrategias, como la identificación del elemento, las expresiones XPath o los selectores CSS. La estrategia puede especificarse explícitamente con un prefijo o puede ser implícita.
Estrategia de localizador predeterminada
De forma predeterminada, se considera que los localizadores utilizan la estrategia de localizador predeterminado específica de la palabra clave. Todas las palabras clave admiten la búsqueda de elementos basados en atributos id y name, pero algunas palabras clave admiten atributos adicionales u otros valores que tienen sentido en su contexto. Por ejemplo, Click Link admite el href atributo y el texto del enlace y la adición al normal id y name.
Ejemplos:

Click Element       xpath=/html/body/div[2]/div[2]/form/div[2]/div[1]/div[3]/center/input[1]

¿Como busco el elemento?

Se va a copiar este texto “#hplogo”
Luego lo podemos utilizar con el Keyword “Wait Until Element Is Visible”

Wait Until Element Is Visible   id=hplogo   #va sin el numeral

Si seleccionamos Copy XPath el texto es “//*[@id="hplogo"]”

Wait Until Element Is Visible   xpath=//*[@id="hplogo"]

Implicitamente tambien comprende que tipo de selector estoy agregando

Wait Until Element Is Visible   //*[@id="hplogo"]

Lista de diferentes tipos de selectores

BuiltIn

https://robotframework.org/robotframework/latest/libraries/BuiltIn.html
BuiltIn es la biblioteca estándar de Robot Framework que proporciona un conjunto de palabras clave genéricas que se necesitan con frecuencia. Se importa automáticamente y, por lo tanto, siempre está disponible. Las palabras clave proporcionadas se pueden utilizar, por ejemplo, para verificaciones (por ejemplo, Should Be Equal, Should Contain), conversiones (por ejemplo, Convert To Integer) y para varios otros propósitos (por ejemplo, Log, Sleep, Run Keyword If, Set Global Variable).
En el Shortcuts estan todos los elementos para poder encontrarlos rapidadamente.
https://robotframework.org/robotframework/latest/libraries/BuiltIn.html#Create%20List

Paginas que fui encontrando

Otra documentacion completa
https://baishanlu.gitbooks.io/robot-framework-cn-en-user-manual/content/robot_framework_user_guide/version_287.html

xpath

https://www.lambdatest.com/blog/complete-guide-for-using-xpath-in-selenium-with-examples/#testid2.8.5

https://www.mclibre.org/consultar/xml/lecciones/xml-xpath.html

trucos comando

https://dev.to/juperala/how-to-run-robot-framework-test-from-command-line-5aa

AstroJS 5.1: Integra contenido de Dev.to de manera sencilla

Juan Martin Ruiz — Fri, 27 Dec 2024 10:03:47 +0000

Esta bueno tener un blog personal, pero hay momentos en que necesitamos hacer una publicación en una red social por diferentes razones. Si no desea duplicar las publicaciones de su blog con una publicación de una red social, podemos traer el contenido de la publicación y usar nuestro sitio web como una fuente principal de contenido, donde incluso podemos unir las diferentes publicaciones en una sola colección de publicaciones para que podamos aplicar filtros más adelante. Además, si no queremos ocupar el proyecto con muchas imágenes en el sistema de archivos local o tenemos que pagar el alojamiento de imágenes, o simplemente no queremos escribir en texto "simple" con Markdown. O, simplemente, en el caso que tenga su homepage desarrollada con Astro y en la seccion de Blog solo quiere traer los post de Hashnode, Wordpress, Medium, etc.

En este caso, lo haremos con Devto.

Tabla de contenido

Requisitos previos

Conocimiento fundamental de Typescript y React
node.js ≥ 16.12.0
Un editor de código VScode (opcional)
Git (opcional)

1. ¿Por qué Astro?

Astro es el marco web para construir sitios web orientados al contenido, como blogs, marketing y comercio electrónico. Astro es conocido por ser pionero en una nueva arquitectura frontend llamada "Islas" para reducir la sobrecarga de JavaScript y la complejidad en comparación con otros marcos. Está optimizado por el rendimiento gracias a su estrategia de "cero JavaScript por defecto", solo se cargan los JS necesarios en las partes interactivas, lo que resulta en tiempos de carga rápidas y una excelente optimización de SEO. Es flexible con los marcos/bibliotecas de la interfaz de usuario; Es agnóstico, lo que significa que puede integrar componentes de React, Vue, Svelte, combinando lo mejor de cada uno. Y, por último, su facilidad de uso; Su sintaxis basada en HTML y su sistema de archivos simple hacen que la curva de aprendizaje sea muy suave, incluso si proviene de un fondo más tradicional.

2. Empezar un nuevo proyecto con el template blog

Esto es en caso de que no tenga un sitio creado, si lo hace, la implementación no variará mucho con un proyecto realizado con Astro.

Vamos a crear un blog con la plantilla ofrecida por la comunidad oficial.

npm create astro@latest -- --template blog

2.1 Levantamos la app

cd [nombre_proyecto] && npm run dev

A partir de Astro 5, se ha introducido la Content Layer API, una herramienta que permite cargar datos desde cualquier fuente durante la construcción de tu sitio y acceder a ellos mediante una API sencilla y con tipado seguro.

Esta API ofrece flexibilidad para manejar contenido de diversas fuentes, como archivos locales en Markdown, APIs remotas o sistemas de gestión de contenido (CMS). Al definir "colecciones" de contenido con esquemas específicos, puedes estructurar y validar tus datos de manera eficiente. Además, la Content Layer API mejora el rendimiento en sitios con gran cantidad de contenido, acelerando los tiempos de construcción y reduciendo el uso de memoria.

https://astro.build/blog/astro-5/

3. Content Layer API de Astro para integrar publicaciones de dev.to en tu sitio

Puedes utilizar la Content Layer API de Astro para integrar publicaciones de dev.to en tu sitio. Aunque no existe un cargador (loader) específico para dev.to, puedes crear uno personalizado que consuma su API y almacene las publicaciones en una colección de contenido en Astro.

Para lograr esto, sigue estos pasos:

3.1. Configura el acceso a la API de dev.to

Crear el archivo .env en el root del proyecto
.env

DEV_TO_API_URL=https://dev.to/api/
DEV_API_KEY=tu_clave_de_api

3.2. Define una colección en Astro

En src/content.config.ts, define una colección para las publicaciones de dev.to utilizando la Content Layer API:

Al crear el proyecto con el template de Astro, nos genera automaticamente la coleccion para el Blog

src\content.config.ts

import { glob } from 'astro/loaders';
import { defineCollection, z } from 'astro:content';

const blog = defineCollection({
    // Load Markdown and MDX files in the `src/content/blog/` directory.
    loader: glob({ base: './src/content/blog', pattern: '**/*.{md,mdx}' }),
    // Type-check frontmatter using a schema
    schema: z.object({
        title: z.string(),
        description: z.string(),
        // Transform string to Date object
        pubDate: z.coerce.date(),
        updatedDate: z.coerce.date().optional(),
        heroImage: z.string().optional(),
    }),
});

export const collections = { blog };

Ahora creamos la coleccion para lor articlos de Dev.to

const devTo = defineCollection({
    loader: async () => {
        const headers = new Headers({
            "api-key": DEV_API_KEY,
        });
        const posts = await fetch(`${DEV_TO_API_URL}articles/me/published`,   {
            headers: headers
        }).then(res => res.json());

        return posts.map((post: any) => ({
        id: post.slug,
            title: post.title,
            description: post.description,
            pubDate: new Date(post.published_at),
            updatedDate: post.edited_at ? new Date(post.edited_at) : null,
            heroImage: post.cover_image || post.social_image,
        url: post.url,
        }));
    },
    schema: z.object({
        title: z.string(),
        description: z.string(),
        pubDate: z.coerce.date(),
        updatedDate: z.coerce.date().optional(),
        heroImage: z.string().nullable(),
    url: z.string(),
    }),
  });

export const collections = { blog, devTo };

Asi queda el codigo completo de
src\content.config.ts

import { glob } from 'astro/loaders';
import { defineCollection, z } from 'astro:content';
const { DEV_API_KEY, DEV_TO_API_URL } = import.meta.env;

const blog = defineCollection({
    // Load Markdown and MDX files in the `src/content/blog/` directory.
    loader: glob({ base: './src/content/blog', pattern: '**/*.{md,mdx}' }),
    // Type-check frontmatter using a schema
    schema: z.object({
        title: z.string(),
        description: z.string(),
        // Transform string to Date object
        pubDate: z.coerce.date(),
        updatedDate: z.coerce.date().optional(),
        heroImage: z.string().optional(),
    }),
});

const devTo = defineCollection({
    loader: async () => {
        const headers = new Headers({
            "api-key": DEV_API_KEY,
        });
        const posts = await fetch(`${DEV_TO_API_URL}articles/me/published`, {
            headers: headers
        }).then(res => res.json());

        return posts.map((post: any) => ({
            id: post.slug,
            title: post.title,
            description: post.description,
            pubDate: new Date(post.published_at),
            updatedDate: post.edited_at ? new Date(post.edited_at) : null,
            heroImage: post.cover_image || post.social_image,
            url: post.url,
            body_markdown: post.content,
        }));
    },
    schema: z.object({
        title: z.string(),
        description: z.string(),
        pubDate: z.coerce.date(),
        updatedDate: z.coerce.date().optional(),
        heroImage: z.string().nullable(),
        url: z.string(),
        body_markdown: z.string().optional(),
    }),
  });

export const collections = { blog, devTo };

Fíjese el detalle en la definición de los campos en schema, los campos tienen que coincidir con la collection de blog del template de Astro y luego agregar los que son particulares de la collection de los posts de Dev.to. Tienen que tener el mismo nombre el tipo de dato, es para que podamos "fusionar" en la sección de Blog los posts markdown del template de Astro con los de Dev.to.

4. Utiliza las publicaciones en tus páginas:

Ahora puedes acceder a las publicaciones de dev.to en tus componentes o páginas de Astro utilizando getCollection:

Originalmente:

src\pages\blog\index.astro

---
import BaseHead from '../../components/BaseHead.astro';
import Header from '../../components/Header.astro';
import Footer from '../../components/Footer.astro';
import { SITE_TITLE, SITE_DESCRIPTION } from '../../consts';
import { getCollection } from 'astro:content';
import FormattedDate from '../../components/FormattedDate.astro';

const posts = (await getCollection('blog')).sort(
    (a, b) => b.data.pubDate.valueOf() - a.data.pubDate.valueOf(),
);
---
<!-- Iteracion los posts -->
<main>
            <section>
                <ul>
                    {
                        posts.map((post) => (
                            <li>
                                <a href={`/blog/${post.id}/`}>
                                    <img width={720} height={360} src={post.data.heroImage} alt="" />
                                    <h4 class="title">{post.data.title}</h4>
                                    <p class="date">
                                        <FormattedDate date={post.data.pubDate} />
                                    </p>
                                </a>
                            </li>
                        ))
                    }
                </ul>
            </section>
        </main>

Combinamos las colecciones blog de astro y blog de dev.to y volver a ordenar las publicaciones para garantizar que el orden cronológico sea correcto.

src\pages\blog\index.astro

---
import BaseHead from '../../components/BaseHead.astro';
import Header from '../../components/Header.astro';
import Footer from '../../components/Footer.astro';
import { SITE_TITLE, SITE_DESCRIPTION } from '../../consts';
import { getCollection } from 'astro:content';
import FormattedDate from '../../components/FormattedDate.astro';

const astroPosts = (await getCollection('blog')).sort(
    (a, b) => b.data.pubDate.valueOf() - a.data.pubDate.valueOf(),
);

const devtoPosts = (await getCollection("devTo")).sort(
    (a, b) => b.data.pubDate.valueOf() - a.data.pubDate.valueOf(),
);

const posts = [...astroPosts, ...devtoPosts]
  .sort((a, b) => b.data.pubDate.valueOf() - a.data.pubDate.valueOf());

---

Ahora la iteracion de los posts lo haremos con un condicional inline que en caso que sea devto rediriga a la url del articulo del sitio de https://dev.to/{username}/{slug-article}

                    {
                        posts.map((post) => (
                            <li>
                                <a href={post.collection === "devTo" ? post.data.url : `/blog/${post.id}/`}>
                                    <img width={720} height={360} src={post.data.heroImage} alt="" />
                                    <h4 class="title">{post.data.title}</h4>
                                    <p class="date">
                                        <FormattedDate date={post.data.pubDate} />
                                    </p>
                                </a>
                            </li>
                        ))
                    }

5. Use post de Devto en la página de Blog Slug (opcional)

En caso de que desee incluir el contenido de la publicación media dentro de Astro, debemos modificar src/content.config.ts, src/pages/blog/index.astro y src/paginas/blog/[... slug].astro


// src\content.config.ts

const devTo = defineCollection({
    loader: async () => {
        const headers = new Headers({
            "api-key": DEV_API_KEY,
        });
        const posts = await fetch(`${DEV_TO_API_URL}articles/me/published`, {
            headers: headers
        }).then(res => res.json());

        return posts.map((post: any) => ({
            id: post.slug,
            title: post.title,
            description: post.description,
            pubDate: new Date(post.published_at),
            updatedDate: post.edited_at,
            heroImage: post.cover_image || post.social_image,
            url: post.url,
            content: post.body_markdown,
        }));
    },
    schema: z.object({
        title: z.string(),
        description: z.string(),
        pubDate: z.coerce.date(),
        updatedDate: z.coerce.date().optional(),
        heroImage: z.string().optional(),
        url: z.string(),
        content: z.string(),
    }),
  });

5.1 Mostrar contenido del Post de Devto dentro de Astro

Necesitamos modificar el src\pages\blog\[…slug].astro para mostrar la publicación en particular.

Dado que nuestro sitio está en modo estático de forma predeterminada, utilizaremos getStaticPaths() para generar las rutas estáticamente en el momento de la compilación para mostrar la publicación en particular.

// src\pages\blog\[…slug].astro

export async function getStaticPaths() {
    const blogPosts = await getCollection('blog');
    const mediumPosts = await getCollection('devTo') || [];

    const posts = [...blogPosts, ...mediumPosts]; 

    return posts.map((post) => ({
        params: { slug: post.id },
        props: post,
    }));
}

Antes de usar los componentes propios de Astro para mostrar el post de Devto instalamos la libreria marked que nos va servir para parsear con contenido en formato markdown a HTML

# https://www.npmjs.com/package/marked
npm i marked

Astro viene con unas funciones y componentes que sirven para renderizar nuestro contenido markdown tanto locales como de una API externa.

Utilizamos la función Render() que viene con Astro para compilar las publicaciones de blog y <Content /> es como un componente de renderizado en sí, no habría necesidad de crear un componente especializado para representar todo el contenido de Markdown pero solo nos sirve para los markdown locales. En el caso de representar el contenido de publicaciones de Devto, utilizaremos el componente Fragment. <Fragment /> es un componente Astro incorporado que le permite evitar un elemento de envoltura innecesaria. Esto puede ser especialmente útil al obtener HTML de un CMS (por ejemplo, hashnode o WordPress). Como el contenido de Devto es de tipo markdown primero lo parseamos a HTML con la libreria marked

---
import { type CollectionEntry, getCollection } from 'astro:content';
import BlogPost from '../../layouts/BlogPost.astro';
import { render } from 'astro:content';
import { marked } from 'marked';

export async function getStaticPaths() {
    const blogPosts = await getCollection('blog');
    const mediumPosts = await getCollection('devTo') || [];
    const posts = [...blogPosts, ...mediumPosts]; 
    return posts.map((post) => ({
        params: { slug: post.id },
        props: post,
    }));
}

type Props = CollectionEntry<'blog'> | CollectionEntry<'devTo'>;

const post = Astro.props;

const isDevto = post.collection === "devTo";

const htmlContent = marked.parse(isDevto ? post.data.content : '');

const { Content } = await render(post);
---

<BlogPost {...post.data}>
    <!-- renders local Markdown content -->
    <Content />
    <!-- renders the Devto post content directly as HTML -->
    <Fragment set:html={htmlContent } />
    <!-- renders a link to the Devto post at the end of the content -->
    <a 
        href={isDevto ? post.data.url: ''} 
        target="_blank"
    >
        {isDevto && post.data.url}
    </a>
</BlogPost>

Ejecutamos el proyecto

npm run dev

6. Nota

Tener en cuenta que si crea un nuevo post desde Dev.to tiene que volver a compilar el proyecto con npm run build desde la plataforma deployada (Netlify, Vercel, Render, Cloudflare) ya que este proyecto web es totalmente estático, por defecto en Astro 5 es estatico (hibrido y estático). En caso que quiera que el sitio sea dinámico NO tiene que hacer el fetch() desde el archivo de content.config.ts, las partes que quiera que sean dinámicas tiene que usar prerender = false e instalar un adaptador para node o de la plataforma que precise. Pero la naturaleza estática de Content Layer es intencional y es parte de lo que hace que sea tan eficiente en términos de rendimiento, pero también es la razón por la que no es adecuado para datos que necesitan actualizarse frecuentemente o en tiempo real.
Otras alternivas es aplicar ISR (Incremental Static Regeneration), este artículo explica muy bien como hacerlo. Otra opción es automatizar el deploy del proyecto con GitHub Actions. Y por último, para no sacrificar el beneficio de un sitio estático, se puede aplicar Deploy Hooks en cualquier plataforma de Hosting.

Repositorio: https://github.com/jmr85/astro-devto