Como testear código legado: primer paso

Estoy empezando a leer “Working effectively with Legacy code” de Michael Feather:

Este libro explica muchas técnicas de cómo trabajar con código legado. Si estas teniendo problemas al respecto te recomiendo que lo compres.

Uno de los primeros pasos para poder testear tu código legado sería el romper la dependencia de nuestra código para que podemos añadir test. Porque uno de los mayores problemas con el código legado es que no podemos añadir test.

Ten en cuenta que la definición que tiene el autor de código legado es código sin test.

Uno de los métodos principales para romper la dependencia que tiene el código se llama crear una subclase y sobrescribir  (subclass and override method)

Este método hace que podamos añadir test en código que no es posible. Convierte código en testable.

 

Vamos a verlo con un ejemplo. Tenemos el siguiente código:

Queremos testear el método getUser de la clase UserService pero si creamos un test unitario como el siguiente:

va a fallar porque lanzará una excepción de tipo RuntimeException.

Ten en cuanto que he añadido esta excepción para simplificar el código. Imaginad que en vez de ser esta excepción accede a una base datos que no podemos acceder desde nuestro ordenador o a internet o al sistema de fichero.

 

Si vemos atentamente el código el origen del problema es que tenemos una dependencia con UserConfigurationService que en vez de estar inyectada (ser parte de los atributos de UserService) se crea por una clase que se llama Factory.

Lo que vamos a hacer es crear un método que contenga la instanciación de UserConfigurationService que tendrá el “scope” protected para que las subclases puedan sobreescribirla.

y en el test vamos a crear una instancia hija de UserService que sobreescriba ese método y que devuelva un mock:

Al poder inyectar el mock podemos hacer que el código cambie su comportamiento sin que toquemos su código. Es lo que Michael Feather llama seam. Lo que estamos haciendo con este método es añadir un seam a nuestro código.

Como has podido ver este método es simple pero muy potente porque en muchas casos vamos a poder utilizarlo para poder añadir dobles de test.

No siempre es bueno o posible el poder utilizar este método de romper las dependencias de tu código pero mi experiencia me dice que en la mayoría de los casos es la mejor opción.

Book review: “Workout: Games, Tools & Practices to Engage People, Improve Work, and Delight Clients”

Book cover

Introduction

The book “Workout: Games, Tools & Practices to Engage People, Improve Work, and Delight Clients” is Jurgen Appelo‘s third book. It’s like the second part of Management 3.0 which gives a different approach to management.
It focuses on management practices whereas Management 3.0 is more theoretical.

Although these kind of books aren’t my favorite, I decided to read it because his blog posts are very good and I frequently read them.

Good practices

In the author’s opinion, a good practice should:

  • engage people and their interactions.
  • enable people to improve the system.
  • help to delight all clients.

This is a good pattern to know when a manager is following a good practice or not. When you have doubts about whether a practice is good or bad these three points should help you.

The top 3, for me, were kudo box (www.management30.com/kudo-box), merit money (www.management30.com/merit-money) and delegation boards (www.management30.com/delegation-boards).

I’m going to write just about kudo box and other different subject (the law of requisite variety) because I don’t want to write a long blog post but If you want to know more about these practices, in the links next to them you will find a lot of information.

Law of Requisite Variety

This law says “if a system is to be stable, the number of states of its control mechanism must be greater than or equal to the number of states in the system being controlled”.
This means that anything that controls a system must be at least as complex as the system being controlled.
Organizations are complex adaptative systems. Then, for example, a manager of a team in an organization should be as complex as the team who is managed. As you can image that’s a ridiculous statement. In simple terms, a manager can’t manage a group of people.

Kudo box

This practice consists of writing a letter to a colleague when she did something good for the team. All the letters are put in the kudo box and, for example, once a month the box is opened and all the letters are read aloud.
Each letter should focus on individual effort instead of outcome because a great outcome requires many individuals’ effort.

Recap

Despite the amount of pages, this book is easy to read. What I’m more impressed about is that it gave me a different point of view on management.

I’m not a big fan of managers or management but now I know that is because of all the bad practices that I’ve suffered in my career.
It also shows me that it’s possible to create an environment where people really want to work when we focus on the real important things (see good practices).

In short, if you have money buy this book as soon as possible or if you don’t have any money the book is free when you sign up here:

https://management30.com/product/workouts/

Comentando el libro “the art of agile development”

XP
Imagen de http://www.extremeprogramming.org/

Introducción

El libro the art of agile development trata de TODAS las etapas de un desarrollo utilizando XP. He escrito todas en mayúsculas porque el libro es muy completo y habla de cada etapa con mucho detalle.
Los autores del libro son James Shore y Shane Warden. James Shore lo conocía de antes porque tiene una página sobre TDD en Javascript que tiene muy buena pinta:

http://www.letscodejavascript.com/

Dentro de cada capítulo hay un apartado con posibles preguntas que nos podemos hacer, problemas que podemos tener y posibles alternativas a ciertas prácticas.
Al ser un libro muy completo y con muchos detalles, es muy fácil el encontrar una pequeña joya en forma de consejo en muchas de sus hojas.

Hay, a continuación, un apartado sobre XP y luego una serie de conceptos que aparecen en el libro y que me han gustado especialmente. Estos conceptos son root cause analysis, informative workspace, pair programming y theory of constrains.

XP

Extreme programming (XP) es una metodología que a diferencia de otras metodologías Agile se centra mucho en prácticas para los programadores.
Así, dentro de las prácticas de XP tenemos pair programming, TDD, simple design y refactoring.
Todas estas prácticas permiten que el equipo se centre en llegar a la excelencia técnica, que es uno de los principios detrás del manifiesto Agile.
Creo que tener estas prácticas es algo que la diferencia de otras metodologías y que puede hacerla que tenga mayor número de éxitos, pero que a su vez resulta complicado de implantar al tener más prácticas que, por ejemplo, Scrum.
Si quieres saber más sobre XP, en la siguiente página hay mucha información sobre esta:
http://www.extremeprogramming.org

Root cause analysis

Root cause analysis es un método que nos permite llegar a la raíz de un problema. En nuestro caso, lo podemos utilizar cuando nos encontremos con un error en nuestro código de producción.
Cuando nos encontremos con un problema en nuestro código debemos de preguntarnos 5 veces el porqué se ha producido.
Una cosa importante sobre este tema y que comentan en el libro es que resulta fácil el culpar a una persona del problema, pero que detrás de la persona tenemos nuestro proceso de desarrollo, por lo que si tenemos que culpar a alguien hay que culpar a nuestro proceso y, luego, intentar mejorarlo.

Informative Workspace

La idea es muy simple, añadir información relevante relativa al proyecto en la zona de trabajo.
Tener una zona de trabajo con información del proyecto permite a todo el equipo y a la gente fuera del equipo el ver el progreso de este, simplemente caminando alrededor.
El objetivo principal de esta práctica es la información. Difundir información entre todas las personas involucradas en el proyecto.
Los gráficos deben de estar en este espacio porque permiten de una forma simple, eficaz y sin malentendidos el informar. Hay principalmente dos gráficos en XP y son: iteration plan y release plan.
También comentan que es mejor utilizar un bolígrafo y un papel en vez de pantallas, debido a que nos da más flexibilidad y en que de un solo vistazo se puede ver todo.
Creo que otra de las cosas en las que ayuda estas prácticas es en aumentar la confianza de los stakeholders en el equipo ya que pueden ver en todo momento el estado del proyecto.

Pair programming

Lo primero que llama la atención sobre pair programming en el libro, es que esta en la sección de pensar (thinking). Lo que nos da una idea para que lo utilizan los autores.

Esta práctica mejora, según los autores, el poder mental (brainpower) mientras estamos programando. Así, mientras el que esta programando (driver) solo esta pendiente de desarrollar, la otra persona (navigator) tiene como tarea la de pensar.
Cuando practicamos pair programming no es que dos personas este realizando el trabajo de dos, sino que se divide el trabajo, uno programa y el otro piensa. No es que el que programa no esté pensando sino que la pareja tiene mas tiempo para hacerlo.

He practicando pair programming en los coderetreat y todas las veces acabé muy cansando porque al estar con una pareja estas todo el tiempo concentrado al 100%. Otra gran cosa es que se aprende muchísimo y creo que en general todo el mundo tiene la misma sensación.

Theory of constraints

La teoría de las limitación dice que en todo sistema hay una y solo una limitación y que esta es la que provoca que se ralentice el sistema.

XP considera que la limitación en software development es el desarrollador. Eso es algo que se dice muchas pero que muchas veces en el libro.
Después de leerlo tantas veces estaba algo mosqueado porque aunque es cierto que los programadores podemos mejorar para que el sistema vaya mejor creo que hay otras posibles opciones. Como puede ser los managers que en muchos cosas ralentizán el trabajo de los programadores con sus decisiones, o la poca integración de la gente de negocio en el proceso de desarrollo.
Escribí un tweet y tuve la suerte de que jb me respondió.

Is the developers the constraint in software developer? why? @jbrains @ronjeffries
— Enrique Martín (@kikers25) January 21, 2015

 

Resumen

Aunque tiene unos años es un libro muy recomendable. Me ha ayudado a entender XP y todos las prácticas relacionados con XP.
Tiene muchos consejos sobre cómo implantar XP en una organización y creo que son muy útiles.

Personalmente, me encantaría practicar XP porque aunque sé que las primeras semanas o meses voy a estar muy cansado, debido principalmente a pair programming, voy a poder aprender muchísimo y creo que el resultado final va a ser un gran producto.

*Modificado 25-03-2015: añadido enlaces al libro e información de los autores