Automatización de pruebas con Selenium

Selenium es, desde hace más de dos décadas, una de las herramientas más usadas para automatización de pruebas de aplicaciones web. Controla el navegador como un usuario real, lo que permite validar flujos completos de punta a punta. Con Selenium 4, la herramienta ganó un protocolo estandarizado, gestión automática de drivers y nuevos recursos que hacen la escritura de pruebas más simple y estable.

Esta guía es práctica y técnica. Iremos del entorno a la primera prueba con JUnit 5, pasando por esperas, localizadores, la arquitectura Page Object Model (POM), integración con Cucumber y una mirada al futuro con Vibium. Los ejemplos usan Selenium 4 y Java.

¿Qué es Selenium?

Selenium no es una herramienta única, sino un conjunto. Sus tres componentes principales son WebDriver, que controla el navegador mediante código; Selenium IDE, una extensión para grabar y reproducir pruebas de forma rápida; y Selenium Grid, que distribuye la ejecución en paralelo entre varias máquinas y navegadores. En la automatización seria, WebDriver es el protagonista.

Qué cambió en Selenium 4

Si aprendiste Selenium hace años, vale la pena conocer qué cambió, porque parte del contenido antiguo en internet quedó obsoleto:

• Protocolo W3C WebDriver: la comunicación con el navegador ahora sigue el estándar W3C, lo que hizo las pruebas más estables entre navegadores.
• Selenium Manager: Selenium descarga y configura el driver del navegador automáticamente. Ya no es necesario descargar chromedriver manualmente ni usar bibliotecas externas para ello.
• Relative locators: nuevos localizadores que encuentran elementos por su posición relativa a otros (arriba, abajo, a la izquierda, a la derecha o cerca).
• Nueva API de ventanas y pestañas: abrir una pestaña o ventana se volvió directo, con driver.switchTo().newWindow().
• WebDriver BiDi: un protocolo bidireccional que abre camino para interceptar la red, capturar logs de la consola y escenarios más avanzados.

Preparando el entorno

Aquí va la primera buena noticia: no necesitas descargar un IDE específico ni el driver del navegador manualmente. Cualquier editor moderno sirve, y Selenium Manager se encarga del driver. En un proyecto Java con Maven, basta con agregar las dependencias de Selenium y de JUnit 5:

<!-- pom.xml -->
<dependencies>
  <dependency>
    <groupId>org.seleniumhq.selenium</groupId>
    <artifactId>selenium-java</artifactId>
    <version>4.27.0</version>
  </dependency>
  <dependency>
    <groupId>org.junit.jupiter</groupId>
    <artifactId>junit-jupiter</artifactId>
    <version>5.11.3</version>
    <scope>test</scope>
  </dependency>
</dependencies>

Usa siempre la versión más reciente disponible. Con eso, el entorno ya está listo para la primera prueba.

Primera prueba con Selenium 4 y JUnit 5

El ejemplo a continuación automatiza un login y valida el redireccionamiento. Nota el uso de @BeforeEach y @AfterEach para abrir y cerrar el navegador en cada prueba, manteniendo el aislamiento:

import org.junit.jupiter.api.*;
import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;
import static org.junit.jupiter.api.Assertions.assertTrue;

class LoginTest {

    WebDriver driver;

    @BeforeEach
    void setUp() {
        // Selenium Manager descarga y configura el driver automáticamente
        driver = new ChromeDriver();
        driver.manage().window().maximize();
    }

    @Test
    void debeAutenticarConCredencialesValidas() {
        driver.get("https://ejemplo.com/login");
        driver.findElement(By.id("email")).sendKeys("usuario@ejemplo.com");
        driver.findElement(By.id("password")).sendKeys("password123");
        driver.findElement(By.cssSelector("button[type=submit]")).click();

        assertTrue(driver.getCurrentUrl().contains("/dashboard"));
    }

    @AfterEach
    void tearDown() {
        driver.quit();
    }
}

Esperas: el secreto contra las pruebas inestables

La mayor causa de pruebas inestables (flaky) es interactuar con un elemento antes de que esté listo. Evita Thread.sleep con tiempo fijo y prefiere esperas explícitas, que aguardan por una condición específica:

import java.time.Duration;
import org.openqa.selenium.support.ui.WebDriverWait;
import org.openqa.selenium.support.ui.ExpectedConditions;

WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(10));
wait.until(ExpectedConditions.elementToBeClickable(By.id("entrar"))).click();

Localizadores y los nuevos relative locators

Además de los localizadores clásicos (By.id, By.cssSelector, By.xpath), Selenium 4 trae los relative locators, que encuentran elementos por su posición en relación con otros. Son útiles cuando la estructura del HTML es inestable, pero la disposición visual es previsible:

import static org.openqa.selenium.support.locators.RelativeLocator.with;

// Encuentra el campo de contraseña ubicado justo debajo del campo de correo
WebElement contrasena = driver.findElement(
    with(By.tagName("input")).below(By.id("email")));

Organizando las pruebas con Page Object Model (POM)

Escribir localizadores dispersos por las pruebas se vuelve una pesadilla de mantenimiento. El Page Object Model resuelve esto al representar cada página como una clase que concentra sus elementos y acciones. Cuando la interfaz cambia, el ajuste ocurre en un único lugar. Es una de las prácticas más importantes para una suite sostenible, tema que profundizamos en el artículo sobre frameworks de automatización.

Primero, la página de login como un Page Object:

public class LoginPage {

    private final WebDriver driver;
    private final By email = By.id("email");
    private final By contrasena = By.id("password");
    private final By entrar = By.cssSelector("button[type=submit]");

    public LoginPage(WebDriver driver) {
        this.driver = driver;
    }

    public DashboardPage autenticar(String usuario, String password) {
        driver.findElement(email).sendKeys(usuario);
        driver.findElement(contrasena).sendKeys(password);
        driver.findElement(entrar).click();
        return new DashboardPage(driver);
    }
}

Ahora la prueba queda limpia, legible y enfocada en el comportamiento, sin detalles de localizadores:

@Test
void loginValidoLlevaAlDashboard() {
    driver.get("https://ejemplo.com/login");

    DashboardPage dashboard = new LoginPage(driver)
        .autenticar("usuario@ejemplo.com", "password123");

    assertTrue(dashboard.estaVisible());
}

Selenium con Cucumber (BDD)

Un punto fuerte de Selenium es la flexibilidad: encaja tanto con frameworks de prueba como JUnit 5 como con enfoques de BDD como Cucumber. En BDD, el escenario se describe en un lenguaje cercano al natural, en el formato Dado-Cuando-Entonces, acercando al equipo técnico y al negocio. Mira el mismo login descrito en un archivo de funcionalidad:

# login.feature
Característica: Login
  Escenario: Login con credenciales válidas
    Dado que estoy en la página de login
    Cuando ingreso un usuario y contraseña válidos
    Entonces debo ser redirigido al dashboard

Los pasos (steps) enlazan cada frase con el código Selenium. Observa que el mismo Page Object se reutiliza, mostrando cómo POM, Selenium y Cucumber conviven bien:

import io.cucumber.java.es.*;
import static org.junit.jupiter.api.Assertions.assertTrue;

public class LoginSteps {

    WebDriver driver = new ChromeDriver();
    LoginPage login = new LoginPage(driver);

    @Dado("que estoy en la página de login")
    public void abrirLogin() {
        driver.get("https://ejemplo.com/login");
    }

    @Cuando("ingreso un usuario y contraseña válidos")
    public void ingresarCredenciales() {
        login.autenticar("usuario@ejemplo.com", "password123");
    }

    @Entonces("debo ser redirigido al dashboard")
    public void validarDashboard() {
        assertTrue(driver.getCurrentUrl().contains("/dashboard"));
    }
}

Buenas prácticas con Selenium

• Adopta el Page Object Model desde el inicio para aislar la interfaz de la lógica de las pruebas.
• Usa esperas explícitas y evita tiempos fijos de espera.
• Mantén los datos de prueba aislados y prioriza escenarios por riesgo, como en las pruebas de regresión.
• Integra la suite al pipeline de CI/CD para ejecutarla en cada entrega.
• Escala la ejecución en paralelo con Selenium Grid cuando la suite crezca.
• Presta atención a las prácticas que sabotean los resultados, como detallamos en las buenas prácticas de automatización.

El futuro: de Selenium a Vibium

Vale la pena estar atento a lo que viene. Jason Huggins, creador de Selenium, está desarrollando Vibium, presentado como un sucesor pensado para la era de la IA. La propuesta nace de una pregunta directa: si fuéramos a rehacer Selenium para que dejara de ser inestable, ¿qué cambiaríamos? La respuesta pasa por comunicación vía WebSocket y WebDriver BiDi, además de recursos como la descripción de pruebas en lenguaje natural y el self-healing de selectores rotos.

Vibium todavía está en una etapa inicial, pero señala hacia dónde avanza la automatización. Conocer bien Selenium hoy es la mejor base para acompañar esa evolución sin sobresaltos.

Conclusión

Selenium 4 es más simple y estable que las versiones que popularizaron la herramienta. Con Selenium Manager, relative locators y el protocolo W3C, escribir pruebas se volvió más directo y, combinado con buenas prácticas como el Page Object Model, JUnit 5 y Cucumber, atiende desde equipos técnicos hasta escenarios de BDD. Para elegir la herramienta correcta para tu contexto, vale la pena comparar las opciones en nuestra guía de frameworks de automatización de pruebas.

Vale destacar que Proton, la plataforma de automatización de Atomic, ofrece soporte para Selenium. Esto permite integrar y orquestar las automatizaciones construidas con esta tecnología en un único lugar, sumando el poder de Selenium a la gestión centralizada de la plataforma.

¿Quieres implementar automatización de pruebas con la seguridad de quien tiene 10 años en el mercado y expertise en Quality Assurance? Habla con Atomic Solutions y acelera tus entregas sin renunciar a la calidad.