Tests primero. Código de producción, después

El pasado martes, Alejandro Pérez nos dio una charla sobre Estrategias de Refactorización en un cliente en el que coincidimos. Buscando un gran efecto, en lugar de utilizar slides buscó un ejemplo de código real del propio cliente y, sobre el mismo, comenzó a refactorizar. Evidentemente, para eso primero preparó una buena batería de tests que aguantaran la refactorización porque, aunque parezca mentira, aún quedan empresas con código de producción sin cobertura de testing automático. Oh, wait…

El caso es que, casi al final de la demostración sobre cómo afrontar una refactorización de código legado, Alejandro nos comentó una idea que leyó en un artículo de Robert C. Martin: los tests son más importantes que el código de producción.

Test First

En su artículo Test First (http://blog.8thlight.com/uncle-bob/2013/09/23/Test-first.html), Uncle Bob habla sobre la importancia de los tests en el sistema y la forma en que los articulamos. Una de las grandes ventajas de los tests es que podemos emplearlos como documentación ejecutable siempre y cuando los escribamos como especificaciones funcionales.

Tomando este camino de emplear los tests como especificaciones, establece diferencias entre distintas aproximaciones conceptuales de varios frameworks, como RSpec y JUnit. RSpec se basa en especificaciones, mientras que JUnit, intuitivamente, nos lleva a otros paradigmas. Sin embargo, si dejamos un poco a un lado la intuición, podremos descubrir un nuevo mundo de posibilidades con JUnit.

test-production

La asimetría

Más adelante, Uncle Bob habla del concepto de asimetría en la forma en que se relacionan los tests automáticos y el código de producción. ¿En qué sentido se produce esa asimetría? Uncle Bob aporta un punto de vista sobre los tests que es muy interesante. Nos dice que, si por la razón que fuera perdiéramos todo el código de producción, con unos buenos tests somos capaces de desarrollarlo de nuevo sin mayor problema, incluso algo mejor por ser la segunda vez que lo escribimos. Sin embargo, si lo que perdemos son los tests, reconstruirlos desde el código de producción presenta serios problemas: es mucho más complejo y no aseguramos que la aplicación haga totalmente lo que de ella se espera.

Por tanto, se evidencia esa asimetría como un camino de recorrido en un único sentido. Desde los tests automatizados somos capaces de desarrollar el código de producción que valide esas especificaciones, pero no al contrario. Te recomiendo que leas el artículo completo de Uncle Bob para descubrir todas las ideas que allí expone, no tienen desperdicio.

Refactoring-1Refactoring-2

Anuncios

Acerca de juanmagomez

Acerca de mí tengo un teléfono, mi portátil, el ipad y esas cosas.

Publicado el octubre 16, 2013 en Agile, Desarrollo de Software, Testing. Añade a favoritos el enlace permanente. 1 comentario.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: