Las prácticas oficiales de Selenium: qué recomienda y qué desaconseja el proyecto

La documentación oficial de Selenium tiene una sección de test practices con una estructura única: no solo dice qué hacer (encouraged), sino qué no intentar (discouraged) — y la lista de desaconsejadas es oro puro, porque son exactamente las cosas que los equipos siguen pidiendo.

Las 10 prácticas recomendadas (encouraged)

1. Page Object Models — organizar el código con abstracciones por página/componente. La implementación completa está en nuestra lección de POM.
2. Lenguaje específico de dominio — que los tests se lean como casos de negocio (reservar("Corte", "15:30")), no como manipulación de DOM.
3. Generar el estado de la aplicación — preparar precondiciones por API o datos, no clickeando por la UI.
4. Simular servicios externos — mocks para las dependencias que no controlas.
5. Reportes mejorados — resultados que un humano pueda diagnosticar (screenshots, contexto).
6. No compartir estado entre tests.
7. Localizadores optimizados — estrategias robustas de ubicación (nuestra jerarquía de selectores baja esto a tierra).
8. Independencia total de las pruebas — cada una corre sola, en cualquier orden.
9. API fluida — interfaces encadenables en tus page objects.
10. Navegador fresco por prueba — sesión limpia, sin herencia de cookies o storage.

La documentación cierra con una advertencia sabia: "No one approach works for all situations" — son directrices, no dogma.

Las 8 prácticas desaconsejadas (la lista que deberías imprimir)

Esto es lo que el propio proyecto dice que no hagas con Selenium:

1. CAPTCHAs. Un CAPTCHA existe para frenar automatización — automatizarlo es pelear contra su definición. Oficial: desactívalo en entorno de test o salta ese paso con un bypass de prueba.
2. Descargas de archivos. Validar descargas por el navegador es frágil; verifica por API/sistema de archivos.
3. Códigos de respuesta HTTP. Selenium no es cliente HTTP — para status codes usa una herramienta de API testing (guía completa).
4. Logins de Gmail, Facebook y terceros. Igual que Cypress y Playwright: viola términos de servicio, te bloquean por bot, y no es tu software. Stub o cuentas de prueba del proveedor.
5. Dependencia entre tests. Tan importante que aparece en ambas listas.
6. Testing de rendimiento. Selenium mide su propia sobrecarga, no la performance real de tu app — usa herramientas de carga dedicadas.
7. Spidering de enlaces. Recorrer todos los links de un sitio no es un test, es un crawler lento — hay herramientas específicas.
8. Autenticación de dos factores (2FA). Automatizar OTPs reales es frágil e inseguro; la vía oficial: desactivar 2FA en el entorno de prueba o usar bypasses de test.

Nuestro veredicto

La lista discouraged debería ser lectura obligatoria en el onboarding de cualquier equipo QA: media hora leyéndola ahorra semanas de proyectos condenados ("automaticemos el flujo completo con el 2FA real..."). Y las 10 recomendadas son exactamente el temario de nuestro curso gratuito de Selenium + Python — ahora sabes que no es opinión nuestra: es el estándar oficial del proyecto.

Fuente: selenium.dev/documentation/test_practices (Selenium Project, documentación oficial).