Chemaclass - testing

bashunit

2024-10-30T00:00:00+00:00

bashunit es un framework de testing ligero y fácil de usar para Bash. Características como testing paralelo y de snapshots, dobles de test, data providers y toneladas de assertions incorporadas.

Respaldado por documentación clara y una comunidad activa, se ha convertido en un favorito para testing confiable en Bash. Lo que comenzó como una simple frustración de desarrollo ha crecido hasta convertirse en una herramienta open-source que hace que el testing en Bash sea mucho más fácil y divertido.

La historia detrás de bashunit
¿Por qué crear otra librería de testing?
¿Cómo está hoy en día?
Características principales
Lightning tech talk

La historia detrás de bashunit #

El viaje para crear bashunit comenzó con una simple frustración: trabajaba con un equipo donde cada commit tenía que empezar con el nombre del ticket. Como me gusta trabajar en pequeños pasos con commits rápidos e iterativos, añadir la clave y número del ticket a cada commit se convirtió en un gran obstáculo, ralentizando mi flujo de desarrollo con fricción innecesaria.

Después de unos días así, decidí automatizarlo. Git tiene un hook útil, prepare-commit-msg, que te permite alterar los mensajes de commit antes de que se finalicen. Creé un (script) en Bash que automáticamente obtiene la clave y número del ticket del nombre de la rama y lo inserta en el mensaje del commit, haciendo mi proceso más fluido y eficiente.

Como alguien que valora la mejora continua, comencé a añadir más características a este script. Sin embargo, se hizo evidente que mantener y probar estos cambios manualmente llevaba demasiado tiempo y era propenso a errores. Para hacer el desarrollo más seguro y eficiente, creé una función assert(enlace), permitiendo tests automatizados que verificaban el comportamiento esperado basado en la salida del script.

La función assert me permitió definir múltiples assertions en un archivo separado, facilitando la validación de que cualquier refactorización del hook original mantuviera el comportamiento esperado. Si un cambio rompía inadvertidamente la funcionalidad existente, lo señalaría instantáneamente, haciéndome saber de inmediato que algo necesitaba arreglarse. Esta configuración proporcionaba retroalimentación inmediata y ayudaba a asegurar que cualquier actualización al script no interrumpiera su lógica prevista. Por ejemplo:

En el ejemplo anterior, notarás que ejecuto el “SCRIPT” real como el segundo argumento en la función assert, comparando su salida con el valor esperado proporcionado como primer argumento. Aquí, tenemos dos casos de test, cada uno exportando TEST_BRANCH para simular cómo el mensaje del commit variaría según el nombre de la rama. Esta configuración emula el comportamiento real, permitiéndonos probar cómo diferentes nombres de rama afectan el formato del mensaje del commit. Más ejemplos aquí.

Decidí separar la función assert de los casos de test, como se muestra aquí, para mantener las cosas modulares y reutilizables. Luego, creé un runner para ejecutar cada caso de test independientemente, reduciendo la interferencia entre tests y mejorando la confiabilidad. Puedes ver esa configuración aquí. Esta estructura hizo el testing automatizado más fácil y la refactorización más segura.

Esta fue una gran mejora porque facilitó separar los casos de test de la lógica del runner de tests en sí. Esta estructura clara ha simplificado tanto la creación como la gestión de tests.

Ahora los tests estaban organizados y tuve una idea:

## Idea de seguimiento
Separar la lógica de testing en otro repositorio,
para que pueda ser reutilizada en cualquier lugar.

Y así comenzó. En ese momento, no sabía mucho sobre Bash o las mejores formas de usar un proyecto Bash como dependencia. Pero sabía que podía empezar usando un submódulo de Git, aunque no soy muy fan de ellos.

El 4 de septiembre de 2023, lancé la versión 0.1, que presentaba un runner funcional y una única función de assertion: assertEquals. Más tarde, se lanzó la versión 0.2, permitiendo que ./bashunit fuera un ejecutable independiente, ejecutable desde cualquier carpeta. Así es como se veía entonces:

Compartí el proyecto con algunos amigos que rápidamente se unieron para ayudar con la documentación, el sitio web, assertions adicionales, testing de snapshots y decisiones clave. Para enfatizar su espíritu open-source y propiedad comunitaria, lo moví a una organización que creamos específicamente para compartir proyectos OSS, convirtiéndolo en un proyecto verdaderamente colaborativo en lugar de uno individual.

¿Por qué crear otra librería de testing? #

Ahora sé que existen otras librerías de testing para Bash. Pero cuando empecé con bashunit, no las conocía, y francamente, todavía no soy un experto en Bash. Para cuando me enteré de estas alternativas, ya era demasiado tarde, bashunit había ganado suficiente impulso y entusiasmo para seguir adelante.

Mientras que esas otras librerías pueden servir casos de uso específicos, usar Bash moderno, o ser desarrolladas por desarrolladores de Bash más experimentados, bashunit aspira a diferenciarse ofreciendo una gran experiencia de desarrollador, moldeada por años de trabajo con varios frameworks de testing.

Me preguntaron sobre las diferencias el 7 de septiembre de 2023, y aquí está mi respuesta: Pregunta: Diferencia con pgrange/bash_unit.

¿Cómo está hoy en día? #

Hoy, puedes instalar bashunit via curl, Homebrew, MacPorts, descargando el último release de GitHub, o incluso compilándolo tú mismo desde el código fuente. Completamente open-source.

El proyecto está escrito en Bash 3.2 (de 2007) ya que esa es la versión por defecto en macOS, incluso ahora, en 2024. Esta compatibilidad significa que bashunit funciona sin problemas en esa versión, y planeo mantener el soporte para ella.

Para asegurar la calidad, probamos cada característica con tests unitarios, funcionales y de aceptación, haciendo que bashunit sea su propio “primer usuario” de cada nueva característica. También tenemos varios workflows de CI usando GitHub actions que ejecutan tests en diferentes plataformas para verificar compatibilidad y confirmar que todo funciona como se promete.

En junio de 2024, bashunit fue integrado en PHPStan para sus tests end-to-end, permitiendo el uso de las assertions de bashunit independientemente de su runner. Esta flexibilidad resultó ser muy útil.

El verano pasado, fui invitado a hablar sobre bashunit en la International PHP Conference en Berlín, junto con Manu, otro contribuidor. Este proyecto ha abierto puertas y ha llevado a mucha gratitud de usuarios que aprecian el trabajo que hemos puesto en él.

Características principales #

bashunit incluye funciones clásicas del ciclo de vida como set_up, tear_down, set_up_before_script y tear_down_after_script.

También soporta una amplia gama de parámetros de línea de comandos y valores de configuración. Algunos de mis favoritos incluyen:

--parallel
--filter
--stop-on-failure
--verbose

También proporcionamos data providers para ejecutar los mismos casos de test con diferentes inputs.

Para dobles de test, bashunit ofrece mocks y spies. Estos funcionan dentro del mismo proceso que el test, pero actualmente no funcionan entre procesos, un área para mejorar.

Incluye potente testing de snapshots, facilitando la verificación de salidas de comandos o scripts a lo largo del tiempo.

bashunit ofrece un amplio conjunto de assertions nativas para casos de test, incluyendo:

assert_same
assert_equals
assert_contains
assert_matches
assert_string_starts_with
assert_array_contains
assert_successful_code
assert_general_error
assert_file_exists
assert_file_contains
assert_match_snapshot

Incluso puedes crear tus propias assertions personalizadas para extender las capacidades de bashunit.

Con más de 25 contribuidores y más de 325 estrellas en GitHub en solo un año de desarrollo en tiempo libre, estoy genuinamente orgulloso de lo que este proyecto se ha convertido.

Lightning tech talk #

Recientemente, presenté una lightning tech talk en un meetup de hackers, haciendo una demo de bashunit a una audiencia de más de 100 personas. ¡Fue una experiencia increíble compartir esta herramienta con una audiencia tan comprometida!

Logo original de bashunit diseñado por Antonio.

¿Cómo Testear Métodos Privados?

2023-10-20T00:00:00+00:00

Esta pregunta me la han hecho muchas veces a lo largo de los años. Aquí recopilo mis ideas al respecto.

Respuesta corta #

Nunca.

Respuesta larga #

Nunca jamás.

¿Y si…? #

Si realmente quieres testear un método privado, considera extraer esa lógica del método privado en una clase separada, y escribe un test unitario para el comportamiento de esa clase.

Para este, me inspiré en el post original de Fran Iglesias.

¿Equipos de QA Dedicados en Software?

2023-05-17T00:00:00+00:00

Esto será controvertido, pero hablemos de la posición de QA. La verdad oculta detrás de la falta de calidad del software y por qué esto debería preocuparte si escribes software.

QA es un rol, no una posición #

Como desarrollador de software, cuando escribes software, eres responsable de la calidad de lo que sea que estés escribiendo. Una tercera persona actuando como QA podría encontrar que tu solución no funciona como se esperaba, pero ¿cómo es posible? Podrías argumentar que podrían encontrar casos límite, pero ¿cómo podría ser posible si el software ya fue testeado previamente?

El objetivo final de un equipo de software es hacer la posición de QA inútil porque no deberían encontrar nada más que software bien funcionando. Pero ¿cómo llegas a ese punto? ¿Cómo podemos asegurar que el software que escribimos funciona como se espera y no hay necesidad de una persona QA en nuestro equipo?

La verdad oculta detrás de la falta de calidad del software #

Desafortunadamente, en nuestra industria del software, la demanda de proyectos “rápidos, rápidos y sucios” terminó en MVPs pobremente desarrollados simplemente aplicando parches y código sobre código con solo testing manual comprobando caminos felices, a veces incluso ignorando casos límite.

“La fecha límite es en una semana, ¡así que mejor termínalo a tiempo!”

No aprendemos la importancia de lo que el testing automatizado puede aportar a nuestro trabajo diario, así que no lo tomamos en serio, y por lo tanto, no lo practicamos lo suficiente. Y, por esa misma razón, porque no lo practicamos, no sabemos cómo realizarlo correctamente. ¡Sí, estoy hablando de escribir tests automatizados que prueban el comportamiento de tu software!

Nuestra incapacidad para escribir código testeable resulta en software que es difícil de testear, y por lo tanto delegamos el testing a terceros trasladando la responsabilidad de la calidad final general del producto o servicio que escribimos.

La práctica hace al maestro #

Debes aprender y aplicar técnicas de testing apropiadas cuando tengan sentido. ¿Cómo y cuándo usar efectivamente dobles de test, preparar tests solitarios o sociables, qué compromisos y razones respaldan tu mente al elegir uno u otro camino hacia tus estrategias de testing?

Eres la última y principal persona responsable de tu conocimiento, así que mejor invierte en ti mismo porque nadie más lo hará por ti.

Mira todo lo que haces como una oportunidad de aprendizaje. Practica y mejora por defecto en todo lo que haces.

Si no sabes cómo empezar, aquí está mi consejo favorito: siempre puedes practicar y mejorar tus habilidades de testing usando katas de código. Lee más sobre este tema aquí.

Buena teoría, pero… ¿para qué molestarse? #

El testing manual es, por supuesto, necesario. Es otra estrategia de testing que no estoy culpando o atacando. Aún podríamos necesitar una persona dedicada a cargo de descubrir qué nuevas funcionalidades queremos construir para satisfacer a nuestros clientes. Pero este post no es sobre esa posición.

Se trata de acortar el bucle de retroalimentación. Si puedes escribir software para que funcione de maneras específicas, ¿no puedes escribir tests automatizados para probar que el software que escribiste se comporta de la manera que esperas?

Si has cubierto con tests automatizados el comportamiento de tu software a cualquier nivel que tenga sentido, ¿qué queda para una persona QA dedicada?

La próxima vez que pienses “Necesitamos una persona QA para testear esto”, intenta el ejercicio de pensar en cambio, “¿Cómo puedo escribir un test automatizado que verifique lo que esperaría si una persona QA estuviera comprobando esto?”

Y así es como cambias la “posición de QA a tiempo completo” en una “mentalidad de rol para todos los que escriben software.”

El código nunca miente y nunca olvida; una vez que está escrito y automatizado en tu pipeline, puedes ejecutarlo en cualquier momento sin coste.

Artesanía Limpia

2022-07-11T00:00:00+00:00

El libro tiene tres partes: disciplinas, estándares y ética.

La primera es la más técnica. Te guía con ejemplos de TDD y muestra cómo el testing te ayuda a diseñar tu código.

La segunda trata sobre productividad, calidad y coraje.

La tercera explica cómo hemos llegado hasta aquí como profesionales del software y nuestra responsabilidad ética: no hacer daño, integridad y trabajo en equipo.

Una de mis partes favoritas del libro:

Nuestra industria es dinámica y cambia constantemente. Hay que aprender de forma continua y agresiva.

¿Cómo y cuándo aprendes? Si tu empresa te da tiempo para ello, aprovéchalo al máximo. Si no, tendrás que hacerlo por tu cuenta.

Prepárate para dedicar varias horas al mes. Reserva ese tiempo.

Sí, ya sé: familia, facturas, viajes, la vida. Pero también tienes una profesión. Y las profesiones requieren cuidado y mantenimiento. Aprendamos de forma continua y agresiva.

Capítulo 11. Coraje - Aprendizaje Agresivo Continuo

Índice #

Parte I: Las Disciplinas #

Capítulo 1. Artesanía #

Extreme Programming
Test-Driven Development
Refactoring
Diseño Simple
Programación Colaborativa
Tests de Aceptación

Capítulo 2. Test-Driven Development #

Visión General
Lo Básico

Capítulo 3. TDD Avanzado #

Quedarse Atascado
Arrange, Act, Assert
Test Doubles
Arquitectura

Capítulo 4. Diseño de Tests #

Testeando Bases de Datos
Testeando GUIs
Patrones de Test
Subclase Específica de Test
Humble Object
Diseño de Tests
Rompiendo la Correspondencia

Capítulo 5. Refactoring #

¿Qué es Refactoring?
El Kit Básico de Herramientas
Extract Method
Las Disciplinas

Capítulo 6. Diseño Simple #

YAGNI
Cubierto por Tests
Cobertura
¿Diseño?
Maximizar Expresión
La Abstracción Subyacente
Minimizar Duplicación
Minimizar Tamaño

Capítulo 7. Programación Colaborativa #

Capítulo 8. Tests de Aceptación #

La Disciplina
El Build Continuo

Parte II: Los Estándares #

Capítulo 9. Productividad #

Nunca Enviaremos M***da
Adaptabilidad Económica
Siempre Estaremos Listos
Productividad Estable

Capítulo 10. Calidad #

Mejora Continua
Competencia Sin Miedo
Calidad Extrema
No Volcaremos en QA
QA No Encontrará Nada
Automatización de Tests
Testing Automatizado e Interfaces de Usuario
Testeando la Interfaz de Usuario

Capítulo 11. Coraje #

Nos Cubrimos Mutuamente
Estimaciones Honestas
Debes Decir NO
Aprendizaje Agresivo Continuo
Mentoría

Parte III: La Ética #

El Primer Programador
Setenta y Cinco Años
Nerds y Salvadores
Modelos a Seguir y Villanos
Gobernamos el Mundo
Catástrofes
El Juramento

Capítulo 12. Daño #

Primero, No Hacer Daño
Mejor Trabajo
Prueba Repetible

Capítulo 13. Integridad #

Ciclos Pequeños
Mejora Implacable
Mantener Alta Productividad

Capítulo 14. Trabajo en Equipo #

Trabajar como Equipo
Estimar Honesta y Justamente
Respeto
Nunca Dejes de Aprender

Charla de Uncle Bob donde cubre la mayoría de los temas del libro.

Escucha sobre:
* Cita e Intro - [00:00:00]
* Trayectoria Profesional - [00:07:29]
* Clean Craftsmanship - [00:10:53]
* Programador como Profesión - [00:15:31]
* Artesanía - [00:18:45]
* Disciplinas - [00:22:45]
* Disciplinas: Test-Driven Development - [00:28:49]
* Disciplinas: Refactoring - [00:34:31]
* Cobertura de Código - [00:39:02]
* Estándar: Nunca Enviar M***da - [00:42:35]
* Estándar: Siempre Estar Listo - [00:47:15]
* Ética: No Hacer Daño - [00:50:00]
* Ética: Estimar Honestamente - [00:53:56]
* 2 Sabiduría de Tech Lead - [00:57:50]

Ingeniería de Software Moderna

2022-06-29T00:00:00+00:00

El libro presenta el desarrollo de software como una práctica de ingeniería real. Para dominarlo hay que ser experto en aprender y gestionar la complejidad.

Optimizar para aprender #

El libro presenta cinco comportamientos clave para aprender mejor:

Trabajar de forma iterativa
Buscar feedback
Incrementalismo
Empirismo
Ser experimental

La idea central: trabajar en pasos pequeños, recoger feedback y ajustar.

Optimizar para gestionar la complejidad #

Cinco ideas para manejar la complejidad:

Modularidad
Cohesión
Separación de responsabilidades
Ocultación de información y abstracción
Gestión del acoplamiento

Gestionar la complejidad de nuestros sistemas es fundamental.

Herramientas para apoyar la ingeniería #

El libro profundiza en ideas como:

Testeabilidad
Desplegabilidad
Control de variables
Entrega continua

Un vídeo donde el autor explica las ideas principales del libro:

London vs Chicago

2021-11-20T00:00:00+00:00

Hay dos escuelas conocidas en TDD: la escuela mockista (también conocida como Outside-in) y la escuela clasicista (también conocida como Inside-out).

¿Por qué London y Chicago? #

Dos empresas, una de Londres y otra de Chicago, afirmaban hacer TDD pero con enfoques diferentes. La de Londres construía software de afuera hacia adentro; la de Chicago, de adentro hacia afuera. Veamos cada una.

Outside-in: Escuela de Londres #

Un enfoque guiado por comportamiento para TDD. Empiezas desde el exterior de la aplicación y vas hacia adentro, bajando a capas inferiores. Por ejemplo, desde la API/Controladores hacia las capas de aplicación o dominio.

PROS #

Enfocado en Comportamiento: requiere muchos dobles de test porque testeas abstracciones que aún no existen (creas lógica de alto nivel primero). No escribirás código muerto, pero es fácil crear tests muy acoplados a la lógica, lo que dificulta el refactoring.
Separación Comando-Consulta: es una disciplina para gestionar efectos secundarios. O realizas una acción (comando) o pides un valor (consulta).

CONTRAS #

Tests Frágiles: tiende a crear tests que se rompen fácilmente porque suelen estar muy acoplados al código de producción.
Refactoring Difícil: por la misma razón, tener tests acoplados hace que el refactoring continuo sea lento y complicado.

Inside-out: Escuela de Chicago #

Un enfoque informal, exploratorio, basado en estado. Empiezas desde el interior de la aplicación (normalmente el dominio) y vas hacia afuera, hacia las APIs.

PROS #

Red de Seguridad Fuerte: produce tests desacoplados de la implementación. Puedes cambiar el software sin miedo a romperlo, ideal para el refactoring continuo.
Alta Cohesión: a medida que los tests se vuelven más generales, el código de producción se vuelve más específico. Alta cohesión lleva a bajo acoplamiento, lo que mejora extensibilidad, mantenibilidad y testeabilidad.
Minimiza Dobles de Test: construir de adentro hacia afuera requiere menos dobles porque construyes sobre tests previamente escritos. Esto ayuda a tener tests menos frágiles.

CONTRAS #

YAGNI: a menudo sobre-diseña soluciones, con código que realmente no se necesita (¡o ni siquiera se usa!) al final.

Londres y Chicago funcionan mejor juntas #

No se trata de elegir uno u otro. Se trata de entender tu contexto y optimizar las cualidades que lo necesitan. London y Chicago tienen sus pros y contras. El mejor enfoque para TDD es integrar ambas escuelas.

Referencias #

TDD vs BDD

2021-09-25T00:00:00+00:00

Estas son dos técnicas diferentes. La clave de cada una está en la mentalidad y el contexto de lo que quieres lograr.

BDD es una “funcionalidad guiada por tests” #

Básicamente, es un desarrollo test-first, donde el enfoque principal es asegurar el comportamiento final esperado, y por lo tanto el resultado de la lógica de software que quieres tener al final.

En BDD el enfoque principal es el comportamiento de tu lógica de dominio que aún no existe. Es, desde un punto de vista abstracto, sobre toda la funcionalidad y los requisitos del dominio.

TDD es sobre el ritmo #

Especifica lo que quieres.
Hazlo funcionar.
Hazlo mejor.

TDD no es solo la ya conocida mentalidad “red-green-refactor”, sino principalmente sobre el flujo de trabajo que te ayuda a entender las constantes decisiones de diseño que haces cada vez para cada lógica que estás diseñando.

TDD es sobre retroalimentación constante de tus decisiones.

En el contexto de OOP (para hacer los ejemplos más claros), siempre hay toneladas de formas diferentes de diseñar tu clase:

¿Cuál es el nombre de la clase de este método?
¿Cuáles son las dependencias o colaboradores de esta clase?
¿Cómo se comportará esta clase cuando use esta otra clase dentro de ella?
¿Cuál es el resultado esperado de este método cuando le doy estos argumentos?
etc, etc…

Hacemos estas preguntas (y muchas más) cada vez, y también les damos una respuesta, pero normalmente sin ningún pensamiento racional o reflexión sobre ello. Simplemente hacemos lo que creemos que es “lo mejor” en ese momento particular enfocándonos en hacer que algo funcione, pero ¿es suficiente hacerlo funcionar?

El bucle de retroalimentación constante #

El testing no es solo una gran herramienta porque te da una red de seguridad para refactorizar con confianza, sino también porque ayuda a diseñar mejor el sistema. ¿Cómo es eso? Porque antes de implementar cualquier solución, te obliga a pensar en las decisiones que necesitas tomar. Te desafías a ti mismo para entender los argumentos de tus decisiones, y por qué A y no B es mejor solución en un contexto particular.

BDD y TDD no son mutuamente excluyentes, de hecho, pueden y deben coexistir. Depende principalmente del contexto de lo que quieres construir y testear.

BDD es sobre desarrollo de funcionalidades Test-First. El objetivo no es el cómo sino el qué. El bucle de retroalimentación es largo porque obtendrás el “verde” una vez que la funcionalidad esté implementada y funcionando como se esperaba.

TDD también es otro desarrollo guiado por Test-First pero, a diferencia de BDD, se trata de un bucle de retroalimentación más corto y rápido.

Primero, especificas lo que quieres. Piensas sobre el diseño de tu clase o método. Su nombre o firma. Sus dependencias. Pero todo esto con pequeños pasos, uno a la vez.
Segundo, haces que esa pequeña cosa funcione de la manera más simple posible.
Finalmente, lo haces mejor. Porque el software es lo suficientemente difícil y complicado como para hacerlo bien al primer intento, así que el refactoring es imprescindible para mantener un sistema saludable. En este punto, con un “test verde ejecutándose”, puedes refactorizar y mejorar tu lógica de forma segura.

Lo anterior es básicamente TDD, cierto, pero… ¿qué tiene de especial? El bucle de retroalimentación constante y las decisiones de diseño que necesitas tomar antes de escribir realmente la solución. Este es el poder de TDD.

¿Por qué pasos tan pequeños en TDD? #

Teóricamente “debes” escribir pequeños pasos para cada iteración, pero ¿por qué? Se trata del bucle de retroalimentación. Esto depende de ti, tus expectativas y tu experiencia con testing.

Recursos #

Test-Driven (Development)

2021-08-01T00:00:00+00:00

La complejidad aquí no está en escribir tests en sí, sino en los hábitos que tenemos que cambiar para crear software que sea fácil de testear.

La raíz del problema #

Sin experiencia sólida en testing, los desarrolladores lo pasan mal al intentar aplicar tests en su trabajo diario. No es solo por la complejidad del tema, sino porque están acostumbrados a escribir código difícil de testear.

Escribir tests para software que ya funciona (sobre todo cuando se hizo sin pensar en testing) se siente aburrido y casi inútil. Viene acompañado de falta de motivación, culpando al sujeto equivocado: “los tests me hacen ir más lento”.

En un contexto de dominio, si una pieza de lógica de software es difícil de testear, el problema no es el test, sino el código que no estaba bien escrito.

Ya hay cientos de tutoriales, libros y documentación sobre testing. Aquí comparto mi experiencia y cómo aplico esta filosofía en mi trabajo diario.

Test-Driven se basa en esta simple regla #

En lugar de: diseñar código -> desarrollar código -> escribir tests.

Se trata de: escribir test automatizado que falla -> ejecutar test que falla -> desarrollar código para hacer pasar el test -> ejecutar test -> repetir.

La idea de guiar tu código con tests depende del nivel de abstracción de lo que estés escribiendo. No quieres acoplar mal los tests con el código testeado. Quieres testear el comportamiento de tu lógica.

TDD se basa en un bucle de pequeños pasos que te ayuda a encontrar patrones y guiar tu diseño de software con refactorizaciones constantes. Es la mejor opción si quieres asegurar el comportamiento esperado de todos los caminos posibles de tu lógica.

Lo bonito es que no necesitas conocer el algoritmo completo desde el principio. Vas descubriendo cómo debería ser tu lógica expresando la implementación deseada, paso a paso, en tests automatizados.

Escribir tests al mismo tiempo que escribes el código te obliga a escribir mejor software. Porque quieres que sea fácil de testear, y eso lleva a mayor calidad.

Ya escribí otro post sobre la relación entre calidad y testing del software: El Arte del Testing: donde el diseño se encuentra con la calidad.

Mejora tus habilidades de Test-Driven #

La mejor manera de aprender Test-Driven es haciendo katas de software. Pruébalas solo y con otros. Ambas son igualmente importantes.

Solo: para desafiar tu yo interior sin ninguna distracción excepto tú mismo.
Con otros: el pair-programming es esencial en nuestro trabajo. Las katas son las mejores herramientas para entrenar nuestras habilidades de comunicación y aprender juntos unos de otros.

¿Qué es una Code Kata? #

Los desarrolladores no practicamos lo suficiente. La mayor parte de nuestro aprendizaje ocurre en el trabajo, y ahí es donde cometemos la mayoría de nuestros errores.

Otras profesiones creativas sí practican: los músicos tocan piezas técnicas, los poetas reescriben obras constantemente. En karate, un estudiante dedica la mayor parte del tiempo a aprender y perfeccionar movimientos básicos. Esas son las katas.

¿Cuál es el objetivo de una kata? ¿Qué deberíamos tener al final? #

Las katas existen para que los desarrolladores obtengamos los mismos beneficios que practicar en otras profesiones. Son ejercicios simples y artificiales que permiten experimentar y aprender sin la presión de producción.

No hay respuestas correctas o incorrectas en ninguna kata de software: el beneficio viene del proceso, no del resultado.

Consejos #

Cuando resuelvas una kata, vuelve a intentarla en unas semanas o meses.
Explora nuevas soluciones. Sé creativo y no te apresures.
En grupo, no es una competición para ver quién logra más.
El foco debe estar en el proceso, nunca en el resultado.
El verdadero valor de cualquier kata son los aprendizajes que obtendréis después de hablar y compartir experiencias.

Puedes encontrar muchas katas en Internet. Por ejemplo:

TDD es más un flujo de trabajo que un diseño #

“TDD es una herramienta de diseño.” Eso es lo que Sandro dijo durante años. Pero ya no. Tras trabajar con diferentes equipos y organizaciones, y observar cómo trabaja él mismo, Sandro cambió de opinión sobre el rol de TDD en el diseño de software.

TDD en pocas palabras; se trata del ritmo.

Especifica lo que quieres.
Hazlo funcionar.
Hazlo mejor.

Kent Beck #

1. Change the code as usual
2. Write a test that only passes after the change
3. Revert to before 1
4. Type the test again (copy/paste is cheating & invalidates the warranty of the exercise)
5. Make it compile by changing the code
6. See it fail
7. Change the code to make it pass
— Kent Beck 🌻 (@KentBeck) July 30, 2021

Imágenes originales de Emmanuel Valverde Ramos.

Mockear o No Mockear

2021-01-11T00:00:00+00:00

Mockear es útil, pero “qué mockear” suele resultar más complicado de lo esperado si no tratas esto con cuidado.

Cómo escapar del infierno del mocking #

¿Qué pasa realmente cuando creamos un mock? ¿Qué tipos hay? ¿Es bueno o malo mockear? Como siempre, depende del contexto. Aquí veremos las situaciones principales: cuándo mockear, cuándo no hacerlo, y sobre todo por qué.

¿Qué pasa cuando mockeas algo? #

Primero, deberíamos definir qué es un mock:

En un test unitario, los objetos mock pueden simular el comportamiento de objetos reales complejos y por lo tanto son útiles cuando es impracticable o imposible incorporar un objeto real en un test unitario.

Mockear tiene sentido en testing unitario. Un test de integración pasa por la implementación real, verificando cómo interactúan varias unidades. Estos tests sí pueden hablar con la BD o el sistema de archivos. Partimos de esta base: un test unitario es rápido, determinista, no depende de recursos externos y no requiere contexto especial para ejecutarse.

Los mocks cumplen el contrato de la interfaz. Nos permiten testear funcionalidad sin invocar clases colaboradoras complejas.

Un mock es un doble de test que sustituye la implementación real. Además, puede verificar cómo el código bajo test lo utilizó durante la ejecución.

Recomiendo encarecidamente que leas este post si quieres entrar en los detalles de por qué Mockear es un code smell (Temas como estos: ¿Qué es un mock? ¿Qué es un test unitario? ¿Qué es la cobertura de tests? ¿Qué es el acoplamiento fuerte? ¿Qué causa el acoplamiento fuerte? ¿Qué tiene que ver la composición con el mocking? ¿Cómo eliminamos el acoplamiento? ¡y más!)

El problema con mockear #

Cuando mockeas, anulas la lógica de la clase mockeada. La lógica real queda oculta, y ahí es donde los bugs se esconden. Ten en cuenta que:

El mock puede tener atributos, métodos o argumentos que el objeto real no tiene.
Los valores de retorno del mock pueden diferir de los reales. Por ejemplo, puede devolver un tipo distinto con atributos diferentes.
Los efectos secundarios y comportamiento del mock pueden diferir del objeto real. Quizás el mock no lanza una excepción que el objeto real sí lanzaría.

Alternativas a mockear #

“¿Estás diciendo que mockear es malo y no deberíamos mockear?” No.

Depende de lo que estés “anulando”.

¿Es tu lógica de dominio de negocio lo que estás mockeando? Entonces está mal.
¿Es la conexión a la BD lo que estás mockeando? Entonces está bien.

Depende del contexto de la lógica y dónde pertenece esa lógica.

¿Es parte de tu lógica de dominio de negocio? Entonces no deberías mockearla sino instanciarla.

¿Es una dependencia de infraestructura como conexión a BD, sistema de archivos, red, o cualquier servicio externo que no tiene que ver con tu dominio de negocio? Entonces mockéala usando abstracciones/interfaces.

La interfaz es el contrato entre tu lógica de dominio y sus dependencias de infraestructura. Imagina lo fácil que es testear tu dominio instanciándolo y llamando a sus métodos con diferentes argumentos, todo bajo tu control total.

Algunos trucos #

Cuando estés escribiendo un test unitario:

Intenta instanciar tus clases primero.
Evita mockear clases concretas. Escribí un artículo exclusivamente sobre esto: fomentando clases finales e interfaces.

Mockea interfaces. Instancia clases concretas.

“El uso excesivo de mocks lleva a código legacy.” - Philippe Boargau

¿Cómo podemos evitar el mocking excesivo? #

Favorece el estado inmutable sobre el estado mutable.
Haz las dependencias explícitas.
Programa hacia una interfaz, no hacia una implementación.

Referencias #

Mocking is a code smell - Eric Elliott
When to mock & Test Definitions - Uncle Bob
Final classes by default - Matthias Noback
The problem with mocks - Sean Hammond
A Set of Unit Testing Rules - Michael Feathers

Testeando Código Legacy de Forma Efectiva

2020-08-17T00:00:00+00:00

Estos tests también se conocen como tests de caracterización.

Un test de caracterización describe el comportamiento real de una pieza de software existente, y por lo tanto protege el comportamiento existente del código legacy contra cambios no intencionados mediante testing automatizado. Este término fue acuñado por Michael Feathers.

Permiten y proporcionan una red de seguridad para extender y refactorizar código que no tiene tests adecuados. Se puede escribir un test que afirme que la salida del código legacy coincide con el resultado observado para las entradas dadas.

¿Cómo empezar? #

Estos son mis aprendizajes un año después de leer Working Effectively with Legacy Code y aplicarlo a los diferentes proyectos en los que he trabajado desde entonces.

1. ¿Qué quieres testear? #

Averigua las aserciones. Crea un archivo de test para tu clase, y un método de test para la función que quieres testear. Pista:

Si tienes el siguiente método applySomeLogic(): ReturnType,
el test que podrías escribir es test_apply_some_logic(): void.

final class MyBusinessLogic
{
 private DependencyInterface dependencyInterface;
 private ConcreteDependency concrete;

 public function __construct(
 DependencyInterface dependencyInterface,
 ConcreteDependency concrete
 ) {
 this.dependencyInterface = dependencyInterface;
 this.concrete = concrete;
 }

 public function applySomeLogic(Input input): ReturnType
 {
 // caja negra responsable de crear un ReturnType
 // basado en el Input dado
 return returnType;
 }
}

final class MyBusinessLogicTest extends TestCase
{
 public function test_apply_some_logic(): void
 {
 // Quiero afirmar que "aplicando alguna lógica"
 // de MyBusinessLogic con el Input dado
 // recibiré un ReturnType concreto con un
 // cierto valor como su propiedad. Algo como:

 returnType = myBusinessLogic.applySomeLogic(input);
 assertEquals('expected', returnType.getProperty());
 }
}

2. Instancia la clase concreta/final que quieres testear. #

No mockees tus clases concretas. Especialmente tu dominio de negocio. Mockea solo interfaces. De lo contrario, puedes estar ocultando bugs sin querer (¡con tests verdes/pasando!). Trata tus clases de dominio de negocio como finales.

O mockea la interfaz o instancia una clase anónima si quieres crear un Stub:

Los Stubs proporcionan respuestas a llamadas hechas durante el test, normalmente sin responder a nada fuera de lo programado para el test.

final class MyBusinessLogicTest extends TestCase
{
 public function test_apply_some_logic(): void
 {
 myBusinessLogic = new MyBusinessLogic(
 this.createMock(DependencyInterface.class),
 new ConcreteDependency(/* ... */)
 );
 // O
 myBusinessLogic = new MyBusinessLogic(
 new FakeDependency(),
 new ConcreteDependency(/* ... */)
 );
 // ...
 }
}

Donde FakeDependency es una implementación concreta de DependencyInterface con “datos/implementación falsos” ya preparados que solo es útil para propósitos de testing.

3. Llama al método de esa clase proporcionando la entrada deseada. #

La salida será determinada por el estado inicial de la clase de lógica de negocio que queremos testear MÁS los argumentos de entrada que estamos usando.

input = new Input(/* ... */);
returnType = myBusinessLogic.applySomeLogic(input);

4. Afirma la salida con el valor esperado. #

Del paso 1 necesitas saber qué quieres. Aplica la(s) aserción(es) ahora.

final class MyBusinessLogicTest extends TestCase
{
 public function test_apply_some_logic(): void
 {
 myBusinessLogic = new MyBusinessLogic(
 this.createMock(DependencyInterface::class),
 new ConcreteDependency(/* ... */)
 );

 input = new Input(/* ... */);
 returnType = myBusinessLogic.applySomeLogic(input);
 assertEquals('expected', returnType.getProperty());
 }
}

5. Puede que quieras afirmar diferentes valores esperados. #

Puedes proporcionar fácilmente diferentes argumentos a tu lógica de negocio ya sea a través de la construcción de la lógica o diferentes argumentos dados. Para hacerlo, usa la anotación @dataProvider. El método “dataProvider” debe ser público y devolver cualquier iterable.

final class MyBusinessLogicTest extends TestCase
{
 /** @dataProvider providerApplySomeLogic */
 public function test_apply_some_logic(
 array concreteMapping,
 string argInput,
 string expectedValue
 ): void {
 myBusinessLogic = new MyBusinessLogic(
 this.createMock(DependencyInterface.class),
 new ConcreteDependency(concreteMapping),
 /* ... */
 );

 input = new Input(argInput, /* ... */);

 actual = myBusinessLogic.applySomeLogic(input);
 assertEquals($expectedValue, actual.getProperty());
 }

 public function providerApplySomeLogic(): Generator
 {
 yield [
 'concreteMapping' => ['key' => 'value'],
 'argInput' => 'something',
 'expectedValue' => 'expected-value-A',
 ];

 yield [
 'concreteMapping' => ['key2' => 'value2'],
 'argInput' => 'something-else',
 'expectedValue' => 'expected-value-B',
 ];
 }
}

Por último: limpia lo que hiciste. #

Sí, limpia los tests. Merecen estar tan limpios como tu código de producción. De lo contrario, se pudrirán con el tiempo y ¡permanecerán sucios para tus compañeros y tu yo futuro!

Por ejemplo, puedes aplicar el refactoring extract method para mover los detalles de implementación (de la creación de los diferentes objetos) y mantener el mismo nivel de abstracción mientras lees el código del test.

myBusinessLogic = this.createBusinessLogic(concreteMapping);
input = this.createInput(argInput);
actual = myBusinessLogic.applySomeLogic(input);
assertEquals(expectedValue, actual.getProperty());

Por supuesto, todo depende del contexto. ¿Realmente tiene sentido extraer a un método privado createBusinessLogic() o incluso createInput()? Bueno, eso depende de ti. Depende del número de líneas y, lo más importante, del nivel de abstracción que pertenece a ese contexto.

Solo recuerda: mantén tus métodos pequeños.

Ahora puedes refactorizar el código de producción que cubriste con tests sin ese miedo a romperlo.

Todo junto #

El código legacy es código sin tests #

Por supuesto, hay mucho más que aprender sobre testing y trabajo con código legacy. De hecho, especialmente cuando tratamos con código legacy, encontrarás situaciones donde el código está acoplado de alguna manera que podrías querer mockear tus clases concretas porque no hay interfaz (todavía) para ello.

Este libro te presenta muchas técnicas sobre cuándo, por qué, dónde y cómo puedes aplicar estos cambios.

Cuando trabajas con código necesitas retroalimentación. La retroalimentación automatizada es la mejor. Por lo tanto, esto es lo primero que necesitas hacer: escribir los tests.

Primero, añade tests, luego haz tus cambios. #

Cambia la menor cantidad de código posible para poner los tests en su lugar con la receta: #

Identifica “puntos de cambio” para romper las dependencias de tu código.
Rompe las dependencias.
Escribe los tests.
Haz tus cambios.
Refactoriza.

El Arte del Refactoring

2020-06-28T00:00:00+00:00

Si ves algo, en el ámbito de tu tarea actual, que puede mejorarse fácilmente, mejóralo. Y si tienes alguna pregunta al respecto, pregunta.

¿Qué es el refactoring? #

Refactoring significa mejorar tu código. Puede ser renombrar una variable, extraer líneas en un método privado, o separar responsabilidades de una clase en varias.

El refactoring demuestra que te importa lo que haces como profesional. Es un tema controvertido desde hace tiempo. Pero eso no debería frenarnos de mejorar la calidad del sistema.

¿Cuándo y cómo refactorizar? #

Siempre. Dentro del ámbito de tu tarea actual, a menos que sea una tarea planificada específicamente para refactoring de arquitectura.

El refactoring debería ser parte del trabajo diario, no una tarea separada.

No necesitamos pedir permiso para refactorizar. ¿Acaso pedimos permiso para hacer nuestro mejor trabajo?

Para refactorizar bien, la intención debe estar clara. ¿Qué queremos lograr y cómo? El pair programming (o incluso el “pair thinking”) ayuda porque sincroniza dos cerebros y fomenta mejor comprensión mutua.

Refactorizar de forma colaborativa es fundamental en equipo. No debería ser tabú. Al contrario: ayuda a unificar objetivos y dirección de calidad del código.

Algunos consejos sobre el “cómo” #

Buscamos mejora continua, pero…

Si tus cambios generan más ruido que ayuda, para. Piensa si valen la pena en el estado actual del sistema. Quizás no es el momento. Quizás estás contaminando el diff con cambios fuera del ámbito. O quizás es demasiado grande para tu tarea actual. En ese caso, mejor crear una tarea de seguimiento.
Si el refactoring es necesario antes de empezar tu tarea, hazlo primero.

Refactorizamos para aumentar productividad: código más legible es código más fácil de entender.

Testing #

Necesitas un buen conjunto de tests cubriendo la lógica que vas a cambiar. Sin tests, refactorizar es arriesgado. Por lo general, cuanto más fácil es testear algo, más fácil es reemplazarlo o eliminarlo.

Puedes leer más sobre cómo el testing está relacionado con la calidad aquí.

¿Por qué hacerlo? #

¿No querrías un sistema mejor con el tiempo?

El software no es como el vino: no mejora solo. Si quieres un sistema mejor, tienes que trabajar para conseguirlo.

Clases Final en PHP | Java | Cualquiera

2020-06-06T00:00:00+00:00

Contratos claros, efectos secundarios aislados, testeabilidad, baja complejidad y carga cognitiva, fluidez del código y confianza en ti mismo.

Motivación #

Reduce la visibilidad al mínimo #

Cuando una clase es final, no puede ser extendida. Esto la hace más legible y te asegura que la lógica está limitada a esa clase.

Fomenta “composición sobre herencia” #

El Principio Abierto-Cerrado dice: abierto para extensión, cerrado para modificación.

Si decides crear una herencia (por una buena razón, de la que deberías ser consciente), simplemente quita final y listo.

Cuando por defecto no puedes extender una clase, te fuerzas a pensar en composición en lugar de herencia.

¿Por qué esta clase no es final? #

Si preferimos composición sobre herencia, deberíamos evitar la herencia tanto como sea posible. La herencia se usa mal a menudo en POO.

Un concepto mal entendido #

Cuando nos enseñaron POO, normalmente empezamos con el ejemplo clásico de herencia.

Pero cuando Alan Kay creó Smalltalk, la herencia no era el concepto principal. Lo principal era el paso de mensajes: enviar mensajes a objetos que encapsulan datos y lógica, cambiando comportamiento mediante diferentes objetos. Eso es composición. La herencia se hizo tan popular que terminó eclipsando a la composición.

Beneficios #

Contratos claros. Usar interfaces te obliga a pensar en comunicación entre objetos.
Código aislado, sin efectos secundarios. Inyectar solo interfaces elimina efectos secundarios molestos.
Testeabilidad. Mockear interfaces es muy fácil.
Complejidad manejable. Todo aislado significa menos cambios en cascada.
Baja carga cognitiva. Menos complejidad, más foco en lo importante.
Flexibilidad. Sin acoplamiento innecesario, mover código es más fácil.
Confianza. Testear código aislado te da seguridad para cambiarlo.

Composición sobre herencia #

Si necesitas reconfigurar un objeto, cambiar partes de un algoritmo o reescribir parte de la implementación, considera crear una nueva clase en lugar de sobreescribir una existente.

¿Necesitas representar una jerarquía donde las subclases sustituyen a las clases padre? Esta sería la situación clásica donde podrías usar herencia. Aun así, el resultado suele ser mejor si heredas de interfaces abstractas, no de clases concretas.

Qué hacer en su lugar #

Usa interfaces para definir contratos entre clases.
Usa clases finales para implementar esas interfaces.
Usa composición (inyección de dependencias por constructor) para unir las piezas.

Interfaces -> Clases finales -> Composición

El Arte del Testing: Donde el Diseño se Encuentra con la Calidad

2020-04-07T00:00:00+00:00

¿Por qué considerar el testing parte de tu desarrollo diario? Porque está directamente vinculado a la calidad del software.

No voy a explicar las diferentes técnicas de testing ni las diferencias entre tests unitarios, de integración, funcionales o end-to-end.

Me sigue sorprendiendo la falta de experiencia con testing en el mundo del software. Hay una ignorancia generalizada sobre buenas prácticas. Si has trabajado en varios proyectos y equipos, seguro que lo has visto.

Testing de software #

Algunos patrones horribles que he visto (y hecho):

Testear por testear: testear cada archivo individual, confundiéndolo con una “unidad”.
Mockear cada clase, anulando la implementación real y creando comportamiento falso. Esto da una falsa sensación de cobertura.
Acoplar código de producción con tests por todas partes. Imposible cambiar nada sin romper tests, aunque la funcionalidad siga funcionando.
No testear nada porque “ya funciona, ¿para qué perder más tiempo?”

Una razón principal del testing es verificar el comportamiento esperado del software. Pero el testing puede (y debería) ser mucho más que eso.

Diseño de software #

El diseño de software abarca desde algoritmos hasta arquitectura. Aunque estos dos niveles tienen necesidades distintas, comparten patrones comunes. Por ejemplo, el testing:

Si es fácil de testear, probablemente será debido a un buen diseño.

Calidad del software #

Medir la calidad es difícil. Hay muchas métricas a considerar. Aun así, seguro que podemos estar de acuerdo en esto:

Si aspiras a la calidad en tu software, mejor busca un buen diseño.

Testear significa “probar”. ¿Cuántas veces hemos abandonado tests por la complejidad de probar cierta lógica?

El arte del testing consiste en usar los tests para contribuir al resultado final. Si usamos el testing a nuestro favor, según el contexto, mejoraremos la calidad del producto.

Por tanto, el testing no solo verifica comportamiento. También guía el software hacia un mejor diseño.

¿Deberíamos testear todo? Depende del contexto. Habrá situaciones donde los tests no aporten beneficio. Aun así, escribe código como si fuera a ser testeado.

El código testeable tiende a un mejor diseño y, por lo tanto, a mejor calidad.

Trabajando con código legado

2019-07-01T00:00:00+00:00

¿Qué es código legacy? #

El código legacy es simplemente código sin tests.

Beneficios de los tests #

El comportamiento es clave para entender los beneficios del testing:

El comportamiento es lo más importante del software. Los usuarios dependen de él. Les gusta que añadamos funcionalidad (si es lo que querían), pero si cambiamos o rompemos comportamiento del que dependen, pierden la confianza.

Cómo implementar tests en bases de código legacy #

Para cambiar código necesitas tests. Pero para añadir tests muchas veces tienes que cambiar código.

El enfoque sugerido:

Identificar puntos de cambio.
Encontrar puntos de test.
Romper dependencias.
Escribir tests.
Hacer cambios y refactorizar.

Un término útil es “costura” (seam): un lugar donde puedes cambiar el comportamiento sin editar ese código directamente. Como la costura en la ropa, donde dos partes se unen. En software, estos lugares suelen tener interfaces bien definidas. Puedes aprovecharlos para cambiar implementaciones con inyección de dependencias o mocking en tests.

Código Limpio

2016-05-01T00:00:00+00:00

El código malo puede funcionar, pero si no está limpio, puede hundir a una empresa. Cada año se pierden horas y recursos por culpa de código mal escrito. No tiene por qué ser así.

Resumen #

Capítulo 1: ¿Qué es el código limpio? #

El código se puede medir como “bueno” o “malo” en una revisión, o por cuánto tiempo tardas en explicarlo.
El código limpio es elegante, eficiente, legible, simple, sin duplicaciones y bien escrito.
Tu código debe añadir valor al negocio.
Al abrir un archivo fuente, el código limpio transmite calidad y se entiende fácilmente.
Haz tu código limpio y legible para que cualquiera pueda entenderlo rápido. No hagas perder tiempo a otros.

Capítulo 2: Nombres significativos #

Los nombres de las clases, variables y métodos deben ser significativos e indicar claramente lo que hace un método o lo que es un atributo.
Crea nombres pronunciables para facilitar la comunicación.
Evita acrónimos y nombres confusos, que pueden llevar a conclusiones erróneas a cualquiera que lea el código.
Usa nombres que reflejen el dominio del sistema, el contexto y los problemas que deben resolverse.

Capítulo 3: Funciones #

Los métodos deben ser fáciles de leer y entender.
Deben transmitir su intención.
Deben ser pequeños: hasta 20 líneas.
Deben hacer solo una cosa.
Usa nombres que digan claramente qué hace el método.
El número ideal de parámetros es cero, luego uno, luego dos.
Evita tres parámetros; si los usas, justifícalo.
Un Boolean como parámetro indica que el método hace más de una cosa.
Evita la duplicación.

Capítulo 4: Comentarios #

Cuando necesitas comentarios suele ser porque el código es malo.
Si piensas escribir un comentario, mejor refactoriza el código.
Los comentarios no salvan el código malo.
El código debe explicarse por sí mismo.
A veces los comentarios son útiles en ciertos lugares específicos.
No expliques el código con comentarios. Usa nombres descriptivos de variables y métodos.
Los comentarios pueden destacar la importancia de ciertos puntos.
No escribas comentarios redundantes, inútiles o falsos.
Para saber quién cambió qué y por qué, usa control de versiones.
No comentes código sin usar. Elimínalo.

Capítulo 5: Formato #

El formato es una forma de comunicación entre desarrolladores.
El código desordenado es difícil de leer.
La legibilidad afecta a todos los cambios futuros.
Las clases pequeñas son más fáciles de entender.
Pon un límite de caracteres por línea (por ejemplo, 120).
Mantén los conceptos relacionados cerca verticalmente para crear un flujo natural.
Usa espacios entre operadores, parámetros y comas.

Capítulo 6: Objetos y estructuras de datos #

Sigue la Ley de Demeter:
- Cada unidad debe tener solo conocimiento limitado sobre otras unidades: solo unidades “estrechamente” relacionadas con la unidad actual.
- Cada unidad solo debe hablar con sus amigos; no hables con extraños.
- Solo habla con tus amigos inmediatos.
No hagas objetos tontos.
Los objetos ocultan la abstracción de datos y exponen métodos que operan los datos.
Las estructuras de datos exponen sus datos y no tienen métodos significativos.

Capítulo 7: Manejo de errores #

Planifica el manejo de errores con cuidado.
Cuando algo falla, hay que hacer que el sistema responda correctamente.
Lanza excepciones en lugar de ocultarlas.
Crea mensajes de error informativos: qué falló, dónde y, si es posible, por qué.
Separa las reglas de negocio del manejo de errores.
Evita devolver NULL; devuelve un objeto vacío.
Evita pasar NULL a los métodos; puede causar NullPointerExceptions.

Capítulo 8: Límites #

Al usar código de terceros, encapsula las APIs para no exponer objetos externos.
Haz tests de las APIs de terceros.
Estudia la documentación y prueba la API antes de usarla.
Conoce bien las características que vas a usar.

Capítulo 9: Tests unitarios #

Asegúrate de que cada pieza de código hace lo que esperas.
Sigue las leyes de TDD:
- No escribas código sin tener primero un test que falle.
- No escribas más tests de los necesarios para fallar.
- No escribas más código del necesario para pasar el test.
Mantén tus tests limpios.
Los tests evolucionan junto con el código.
Código sucio = tests difíciles de mantener.
Usa la regla F.I.R.S.T:
- Fast: ejecución rápida.
- Independent: independientes entre sí.
- Repeatable: repetibles en cualquier entorno.
- Self-validating: auto-validantes.
- Timely: escritos a tiempo.
Los tests son tan importantes como el código de producción.

Capítulo 10: Clases #

Organiza las clases así:
- Constantes públicas estáticas.
- Variables privadas estáticas.
- Variables de instancia privadas.
- Luego los métodos.
El nombre de la clase debe reflejar su responsabilidad.
Cada clase debe tener una sola responsabilidad: una razón para cambiar.
Intenta describir la clase en una frase breve.
Los métodos deben ser pequeños y con una sola responsabilidad.

Esta entrevista se basa en el libro de Uncle Bob “Código Limpio”. Repasan algunas guías que te ayudarán a ser mejor programador y exploran cómo los libros y tendencias actuales están moldeando el mundo del software.