Iniciar sesión Seguir el proceso
Por Cesar Beas Suarez en Selenium —

Sesión 2 de mi lab de Selenium + Java: Por qué borré todo y volví al día 1

Tenía un framework completo armado con IA. Lo borré. No entendía qué hacía cada pieza. Preferí volver al test simple y construir desde ahí.

Temas: Selenium Java
IntelliJ IDEA mostrando PrimerTest.java con código simple de Selenium en Java, 27 líneas

Lo que tenía

Después del día 1, seguí trabajando con Claude y ChatGPT.
Les pedí que me ayudaran a armar "un framework profesional".

Y lo hicieron.

En unos minutos tenía esto:

selenium-java/
├── src/
│   ├── main/java/com/cesar/qa/
│   │   ├── base/
│   │   │   └── BasePage.java         ← Wrapper de Selenium
│   │   ├── config/
│   │   │   ├── ConfigReader.java     ← Lee config.properties
│   │   │   └── DriverManager.java    ← Gestiona WebDriver
│   │   ├── pages/
│   │   │   ├── LoginPage.java        ← Page Object del login
│   │   │   └── DashboardPage.java    ← Page Object del dashboard
│   │   └── utils/
│   │       └── TestLogger.java       ← Logging de acciones
│   └── test/
│       ├── java/com/cesar/qa/tests/
│       │   └── LoginTests.java       ← Tests de login
│       └── resources/
│           ├── config.properties     ← URLs, credenciales
│           ├── testng.xml            ← Configuración de ejecución
│           └── logback.xml           ← Logging
└── pom.xml

Estructura de carpetas del framework complejo: BasePage, ConfigReader, DriverManager, LoginPage, DashboardPage, TestLogger y archivos de configuración

IntelliJ IDEA mostrando BasePage.java con más de 100 líneas de código, estructura de carpetas expandida con múltiples clases y archivos de configuración
BasePage.java — código que no escribí, que no entendía, que no necesitaba todavía.

POM desde cero.
BasePage con wrappers.
DriverManager con ThreadLocal.
Config.properties.
Logging tipo TestComplete (es la herramienta que uso en mi trabajo actual)
Estructura de carpetas preciosa.
Clases por todos lados.

Cada archivo tenía entre 50 y 150 líneas de código.
Todo "profesional".
Todo "bien estructurado".

El problema: no entendía la mitad de lo que había ahí.

Maté el framework “pro”

Miraba el código y me aparecían preguntas:

  • ¿Por qué ConfigReader lee un .properties si solo tengo una URL?
  • ¿Qué hace exactamente BasePage que no pueda hacer directamente?
  • ¿Por qué necesito DriverManager separado si WebDriverManager ya existe?
  • ¿Qué es logback.xml y por qué lo necesito ahora?

Podía leer las explicaciones de la IA.
Podía copiar y pegar.
Podía intentar hacer que "funcione", porque las primeras veces que ejecuté debí de arreglar varias cosas.

Pero no podía decir que lo entendía.

Era demasiado. Demasiado pronto.
Mucho copiar/pegar. Mucha explicación.
Poco Run. Poco Debug. Poco entender.

Y lo peor: me estaba dando una excusa perfecta para procrastinar.
Porque cuando algo se siente gigante, mi cerebro hace esto: “mañana lo hago”.
Y mañana se convierte en semanas.

Eso no es construir.

Así que hoy tomé una decisión simple:

Reset. Volver al Día 1.

No estoy construyendo un framework para impresionar.
Estoy construyendo uno para aprender y usar.

Y eso exige otra cosa:

Prefiero ejecutar 10 veces algo simple, que copiar 1 vez algo complejo que no entiendo.

No es que la arquitectura sea mala

Esa estructura con BasePage, ConfigReader, DriverManager no es incorrecta.

Es lo que usan frameworks profesionales. Es hacia donde voy a llegar.

Pero es prematura para el día 2.

Es como querer aprender a manejar y empezar con un auto de Fórmula 1. Técnicamente es un auto. Pero no es por donde se empieza.

Probablemente use lo que la IA me recomiende, pero quiero hacerlo estando más seguro de lo que implemento y cómo hacerlo.

Reinicio

Guardé ese framework en una branch aparte del repo.

SourceTree mostrando historial de Git con branch main y experiments/ai-framework, commits de revert y estructura de proyecto
El framework 'pro' quedó en su branch. Main volvió al inicio.

Reinicio para ir paso a paso.

Podré llegar a ese framework profesional pero avanzando script por script.

Volví al PrimerTest.java del día 1:

IntelliJ IDEA mostrando PrimerTest.java con 27 líneas de código simple, estructura de carpetas mínima con solo test y resources
27 líneas. Sin arquitectura. Sin patrones. Pero cada línea la entiendo.

27 líneas. Sin arquitectura. Sin patrones.

Pero cada línea la entiendo.

Selenium no me emociona (todavía)

Hay algo más.

Me cuesta concentrarme en esto. Procrastino bastante. Estas semanas "perdí" más tiempo del que me gustaría admitir.

Y si soy honesto: Selenium no me emociona. No es que lo odie, pero no es algo que me haga saltar de la cama.

Lo empecé porque lo necesito. Porque es lo que pide el mercado. Porque quiero ganar más, tener más opciones, crecer profesionalmente.

No es pasión. Es decisión.

Y está bien. No todo lo que vale la pena aprender tiene que emocionarte antes de empezar.

Capaz cuando lo domine me cope. Capaz sienta orgullo de saber usar esta tecnología con criterio. Capaz no.

Pero eso no cambia que hay que hacerlo.

Qué me quedo por ahora

De todo lo “pro”, hoy me quedo con lo mínimo que me deja avanzar:

Un pom.xml que compile, ejecute y me deje correr tests sin excusas.
Nada más.

Ese es el “suelo” sobre el que voy a construir.

La explicación del por qué de este pom la dejo para el Día 3.

Sesión 3: Codear, no copiar/pegar

Mañana el objetivo es:

  1. POM simple y que entienda
  2. BasePage simple y que entienda
  3. Algún test simple y que entienda
La estructura vendrá sola.
Cuando me duela no tenerla.

🔗 Todo el código de esta serie está en: github.com/cesarbeassuarez/qa-automation-lab
📂 selenium-java

—

Tema conectado:

Dia 1 de este lab de Selenium con java.