Ese código está rancio!

Sienten eso? Huele feito! Y viene de ESE código que tenemos en el repositorio de Automation. Así es! Hoy vamos a hablar de los Code Smells! Porque no solo afectan a desarrollo, sino a testing. Aunque bueno, Automation ES desarrollo...bueno, ustedes entienden!

Basura apilada
Código oloroso en tus automatizaciones?

Qué son los Code Smells?


Lo primero que necesitamos entender es qué es un Code Smell. Podríamos definirlo como un código que no está MAL en si, pero si que podría ser un problema en el futuro. Ya sea porque cuando queramos escalar lo que hace va a ser complejo, porque es difícil de seguir debido a sobre complejizaciones y otras causas.


Si hicieron el curso de Programación para Testers que tengo en Udemy, sabrán que existen paradigmas, mejores prácticas, pilares y principios en la programación. Generalmente lo que se desvía de ellos termina oliendo feo.


En definitiva, está mal pero no tan mal.


Los tipos de Code Smell según Angie Jones.


Angie es una ídola y tiene un sitio web que DEBERÍAS tener en tus favoritos ahora mismo. No lo tenés? Hacelo ahora! Ella escribió sobre los Code Smells que ella considera en Automation y sobre eso voy a agregar mis notas personales y, quizás, sumar alguno.


La Clase eterna.


Puente eterno
Clases LARGAS

Una clase debería tener una sola responsabilidad. Si tiene un millón de métodos y hay que hurgar entre líneas y líneas de código, posiblemente esté mal. Los que hicieron el curso sabrán responder qué principio SOLID está violando este code smell!


Mantengan sus clases concisas y haciendo lo que se supone que tienen que hacer: Una cosa. Si ven que se está extendiendo mucho, quizás sea momento de considerar cómo dividir en otras clases esa funcionalidad.


El Método eterno.

Un montón de código
Métodos que se extieeeeeenden

Es el hermanito menor de la Clase eterna. Similar problema y similares consecuencias. Me ha tocado ver métodos de 80 líneas de código (no es broma!)

En estos casos el método hace de todo. Originalmente tenía una función quizás, pero al tipito que estaba codeando se le ocurrió hacerlo super dinámico y meter if/else y switch cases por todos lados para que haga una u otra cosa según la ocasión.


Capaz hasta te prepare el café si te descuidás...


Código duplicado.


Orejitas cloradas
Doppelgängers de código

A veces nos olvidamos que la programación va sobre hacer lo más posible con la menor cantidad de líneas de código que podamos. Se copypastean bloques para hacer "lo mismo", se repite código por no fijarse si alguien ya había hecho eso y muchas causas más...


El problema es obvio: El día que tengamos que actualizar las implementaciones vamos a tener que hacerlo en mil lugares a la vez, cuando podría haber sido en un solo lugar...


Estrategia para encontrar WebElements frágil...

Un hilo enredado
Enredadísimo

Ahh...este es un code smell que aterroriza a los novatos siempre. Los locators no están bien hechos, le meten XPath absolutos a todo y bueno... después esos tests de UI Automation fallan.


Este es particularmente molesto porque muchas veces se piensa que el locator está bien. Ejecutamos la automatización en ese momento, todo anda joya... pero al día siguiente, EL HORROR!


Este es quizás uno de los Code Smells más frecuentes, uno de los GRANDES problemas de UI Automation (y casi el principal motivo por el que se aconseja enfocarse en API Automation mayormente) y uno de los más complicados de arreglar. Por qué? Porque hay que saber construir buenos locators. Y a veces, la testability de un sistema no ayuda...


Exposición indecente de métodos y variables.

Persona cubriéndose de la foto
No me mires!

Existe la encapsulación amigos. Es más, es uno de los pilares de la Programación Orientada a Objetos. Y hay muy buenos motivos para que esto sea así... úsenla!


A veces pasa que no dan ganas de pensar qué métodos o variables deberían ser de uso interno en una clase y cuál va a ser heredada o instanciada en otras. Se le manda a todo público y listo.


Después, el pobre de tu compañero escribe un punto tras la instancia de la clase y le saltan 3 millones de métodos y variables que NO necesita ver.


Dejen solo público lo que están construyendo para ser usado en otro lado. Lo que es de uso interno en la clase privado o protegido.


Esperando la carroza.