Comentando el libro “Sentimientos, pensamientos y realidades” de Koldo Saratxaga

Introducción

Estuve viendo los vídeos de la Conferencia Agile Spain del 2013 y me gustaron muchas charlas pero la que más me impactó fue la de Koldo Saratxaga.

Su charla fue especial porque aunque todo lo que decía tenía que ver con el mundo Agile él viene de sectores no relacionados con el desarrollo de software.
Así que empecé a buscar información sobre él hasta que llegué a K2K emocionando y a sus libros:

http://loslibrosdek2k.com/

Así que me descargué uno de ellos, empecé a leerlo y me ha encantado.

Sentimientos, pensamientos y realidades

El título del libro son los estados por los que pasa una persona que se mueve por la vida con pasión:

Primero siente (desde las tripas), luego piensa y finalmente actúa.

Cada capítulos del libro se divide en estos tres conceptos junto con realizaciones.
Así primero se explica una idea (sentimientos), luego se desarrolla (pensamientos), posteriormente las acciones (realidades) y finalmente un caso práctico (realizaciones).

Alguna ideas

Las principales ideas que he leído del libro y que para mí eran nuevos son:

  • Todas las personas son diferentes => Campana de Gauss
  • Las empresas tienen que pensar a largo plazo y para ello necesitan la innovación => Cultura de futuro
  • Las personas son innovadoras ya que son las que tienen las ideas. Así que el mayor activo de una empresa son las personas que trabajan en ella
  • Los números tienen un valor instrumental
  • Todas las personas han de conocer la cuenta de resultados, los conceptos económicos y comprender lo que significan. Ejemplo del partido de baloncesto
  • Hacer partícipes a las persona de la empresa: reparto de beneficios, reparto de pérdidas, toma de decisiones importantes en junta, rangos salariales planos (no mucha diferencia de sueldos entre jefes y empleados) y equipos auto organizados
  • Traducir la cuenta de resultados y el balance contable a un lenguaje comprensible para todas las personas y enseñar a todos lo básico de Economía
  • Confianza en el líder: requiere comunicación y transparencia
  • Hablar de sentimientos en las reuniones de gestión del cambio

A continuación voy a explicar algunas de las ideas, principalmente las que más me han gustado.

Campana de Gauss

Aunque la campana de Gauss es una función matemática el autor la utiliza como analogía para decir que en la empresa se trata a todas las personas de la misma manera aunque todas son diferentes.

Si todas las personas son diferentes e incluso cada día somos de una forma, según nos sintamos felices, tristes, cansados o con otro ánimo ¿por qué tratar a las persona de la misma manera?

Una de las frases que más se repite en el libro es que todas las personas son diferentes y creo que es parte fundamental del cambio de mentalidad que se propone en el libro.

El mayor activo de una empresa son las personas

Esto es algo que se suele decir en todas las empresas pero que no suele ser verdad.
Lo bueno en el libro es que explican el por qué y el cómo conseguir lo mejor de cada persona.

No se puede competir con otras empresas reduciendo costes, ya que los países emergentes tienen las mejores tecnologías y procesos ya que otros países los han introducido ahí para abaratar coste.
Así que la única manera de competir es a través de la innovación, y la innovación viene de ideas y las ideas las tienen la personas.

Por lo que necesitamos las personas para competir ya que son las que pueden innovar.

Según el autor: “sólo las personas libres de pensamientos y llenas de ilusiones pueden lograr las ansiadas innovaciones”

¿Y cómo se consiguen personas libres de pensamientos y llenas de ilusiones?
Creo que aquí no hay una única respuesta ya que como comenté al principio todas las personas somos diferentes por lo que cada persona puede ilusionarse por cosas diferentes y sentirse libre debido a hechos diferentes.

Personalmente todas las acciones que llevan a hacer partícipes a las personas de la empresa son las que me han conseguido ilusionar cuando las he leído. ¿A tí que te ilusionaría o ilusiona para darlo todo en tu empresa?

Todos deben conocer el estado actual de la empresa

Todos deben de conocer el estado de la empresa porque, como comentaré en la historia del equipo de baloncesto, necesitamos saber la relación entre el trabajo realizado y el resultado obtenido.

Y para que todos conozcan el estado de la empresa enseñan Economía a toda la gente de la empresa y traducen la cuenta de resultados.

Traducen la cuenta de resultados a un lenguaje simple para que cada persona pueda ver en que afecta su trabajo a la cuenta de resultados.

Equipo de Baloncesto

El equipo de baloncesto se utiliza como ejemplo de porque todos tienen que conocer la cuenta de resultados de la empresa y que esta tiene que estar visible durante el año.
El texto donde se explica es el siguiente:

“Imaginaos un partido de baloncesto en el que los equipos juegan todo el tiempo sin marcador y que sólo al final de partido se supiera el resultado.

Jugar en estas condiciones sería complicado y seguramente se resentiría la efectividad y la motivación de los jugadores, pues no sería posible encontrar la relación directa el juego realizado y el resultado obtenido.
Algo parecido pasa en las empresas tradicionales: el resultado del partido (la cuenta de resultados) sólo se conoce después de meses de finalizar el año”
 

Mis conclusiones

Si me tengo que quedar con una idea en el libro es: todas las personas son diferentes.
Otra idea que me ha encantado es que el mayor activo de una empresa son las personas porque son las que pueden innovar.

Todas las ideas y acciones que se comentan en el libro son buenas pero lo que las hace fantásticas es que salen de la experiencia ya que se han utilizado en muchas compañías, en diferentes sectores y en diferentes países.

Una cosa extraña que me ha pasado leyendo el libro es que me ha empezado a interesar la economía porque todo lo que se comenta sobre la cuenta de resultados. Si alguien tiene alguna recomendación de algún libro, curso o  recurso que me permita entender lo básico de economía soy todo oídos.

Injección de dependencias en Java para dummies

Introducción

Cuando se habla de test unitarios siempre se acaba hablando de inyección de dependencias pero qué es y porque es tan importante cuando queremos probar nuestro código.

Qué es

Como comenté en el artículo sobre mis primeros pasos con test unitarios, la inyección de dependencias consiste en pasar a un objeto sus objetos colaboradores, es decir, los objetos que utiliza.

 

Diagrama 1: Código de producción

 

En la diagrama anterior podemos ver una clase UserService que permite validar que un usuario puede logearse utilizando el método signIn.
Para obtener la información del usuario a partir de su email necesita utilizar la clase UserDAOOracle.

 

Diagrama 2: Código de prueba

 

En este segundo diagrama podemos ver la clase UserService que hace lo mismo que en el diagrama anterior pero que para obtener la información del usuario utiliza FakeUserDAO.
Esta clase FakeUserDAO la hemos creado nosotros para controlar el resultado que devuelve y así no tener que depender de la base de datos.

Para poder pasar del primer diagrama al segundo tenemos que hacer algo para que la clase UserService pueda utilizar la clase FakeUserDAO en vez de UserDAOOracle, y ese algo es la inyección de dependencias.

Porqué

La inyección de dependencias nos permite que nuestro código sea más flexible ya que hace que una clase pueda cambiar sus colaboradores sin necesidad de cambiar su código.

En relación a los test unitarios, la inyección de dependencias permite que nuestros test unitarios sean repetibles (puedes ver las propiedades de un buen test unitario aquí).

Un test es repetible cuando el resultado es siempre el mismo: pasa (verde) o no pasa (rojo).
Si el test no fuera repetible no confiaríamos en su resultado y no nos sería de utilidad.

La inyección de dependencias hace que nuestros test sean repetible ya que nos permite controlar los colaboradores.

Así, usamos los objetos reales cuando estamos en el código de producción y objetos que podemos manipular (dobles de test) cuando estamos con los test unitarios.

Cómo

Para que FakeUserDAO pueda sustituir a UserDAOOracle debe de tener la misma API, una serie de métodos públicos idénticos.
La forma habitual de hacer eso es crear una interfaz con los métodos que tengan que implementar ambas.
Así, en este caso podíamos crear una interfaz UserDAO e inyectar UserDAO a UserService:

 

Hay cuatro formas principalmente de inyectar dependencias:

  1. En el propio método: Añadir la dependencia en el método que la utiliza. Así, en nuestro ejemplo  añadiríamos la dependencia en el método signIn.
  2. Constructor: como su nombre indica añadimos las dependencias en el constructor
  3. Método o Setter: Se puede crear un método por cada dependencia o uno para todas.
  4. Campos públicos: Las dependencias son campos públicos que son declarados en el constructor por lo que podemos cambiarlos.

Para no hacer el artículo muy largo vamos a ver un ejemplo del método que suelo utilizar habitualmente, que es el constructor.
Suelo utilizarlo porque creo que es el más simple ya que si no creamos el constructor por defecto (sin parámetros) al crear una instancia el compilador nos obliga a utilizar el constructor con las dependencias, por lo que no necesitamos recordar como inyectar las dependencias.A continuación podemos ver el código de la clase UserService y como sería el código en producción y el de test:

Podemos ver que en el código de producción utilizamos UserDAOOracle y que en el código de prueba utilizamos FakeUserDAO debido a que ambas implementan la interfaz UserDAO.
El método UserService.signIn solo lanza una excepción cuando no se ha encontrado el usuario utilizando el email de este.Quería haber simplificado al máximo el código pero no me gusta nada devolver null en ningún método y por eso lo que he hecho es devolver un objeto NoUser, que hereda de User y que sobrescribe el método isEmpty devolviendo siempre true:

 

Tips

Algunos pequeños consejos que me hubieran gustado escuchar cuando empecé:

  • Si no sueles inyectar dependencias empieza a hacerlo ahora mismo, aunque no creas sus test unitarios. Sin inyectar dependencias es mucho más complicado probar tu código.
  • No utilices static, ni clases que implementen el patrón Singleton porque te va a resultar más complicado el inyectar las dependencias y crear test unitarios. Hay algunas excepciones pero son muy pocas.
  • Si tienes que inyectar más de dos dependencias en una clase puede ser un problema de diseño. Comprueba si la clase no está haciendo más de una cosa a la vez y está incumpliendo el principio de única responsabilidad.
  • Cuando quieras crear test unitarios de clases existentes y que no tengan inyectadas las dependencias sin romper nada creo que el siguiente enlace que contiene un video de Sandro Mancuso te puede ayudar:

http://craftedsw.blogspot.nl/2012/12/screencast-testing-and-refactoring.html

¿Conoces algún consejo más sobre la inyección de dependencias?

Modificado 17-05-2014: Después de leer este artículo de Carlos Ble he decido cambiar el nombre del método UserDAO.findUserByEmail a UserDAO.findUserBy porque es cierto que es redundante al pasar como parámetro un objeto de tipo Email.

Test unitarios con fechas en Java

Introducción

En el artículo anterior hablé de forma general de como comencé a crear test unitarios en Java.
En este quiero hablar en específico de crear test unitarios cuando el código a testear utiliza fechas.

Manejar fechas en Java es complicado (al menos hasta la versión 7) pero es incluso peor el tema cuando intentas crear test unitarios para tu código.

El problema principal de manejar fechas en Java es debido a que la clase Date, que es la que se suele utilizar habitualmente, es mutable. Es decir, que se puede modificar su valor interno después de haber sido inicializada.
El otro problema es el como crear test unitario con fechas si utiliza como referencia la fecha actual del sistema.

Contexto

Como en el artículo anterior he utilizado en el código las librerias Junit v4 y harmcrest. Podéis encontrarlas en:

http://junit.org/
http://hamcrest.org/JavaHamcrest/

Mutable?¿

Te preguntarás cual es el problema que los objectos de tipo Date sean mutables.
El tema es que podemos modificar el campo fecha de un objeto sin que este pueda hacer nada.

Vamos a verlo en un ejemplo. Tenemos un clase User con un campo con la fecha de nacimiento de tipo Date:

En el siguiente código podemos ver en un test unitario cómo puede afectar la mutabilidad a la clase User:

Hemos cambiado el año de la fecha de nacimiento del usuario de 1990 a 2014 sin que el objeto user lo sepa.

Formas de probar código con fechas

Hay principalmente tres formas de crear métodos testeables que contengan fechas:

  • 1. Pasar la fecha actual como parámetro. De esta forma resulta muy fácil el cambiar la fecha actual del sistema y así probar todos los posible casos que queramos.
  • 2. Obtener la fecha actual por un método que podamos cambiar. Dentro del método que queremos probar, obtenemos la fecha actual del sistema por un método (en la misma clase) con el scope protected para que en el test unitario podamos sobrescribir el método utilizando una clase que extienda ese método.
  • 3. Utilizar nuestra propia clase como fecha del sistema. Dentro del método que queremos probar, utilizamos una clase propia para obtener una instancia de la fecha actual del sistema.

Creo que la mejor forma de ver como funcionan estas tres formas de probar código con fechas es utilizando el mismo problema y ver como es el código en las tres aproximaciones.

El problema: ¿es mi cumpleaños hoy?

Tenemos la misma clase User que utilizamos al principio del artículo:

y queremos probar el método isBirthday (no está implementado en el código anterior porque es diferente según la aproximación). Esté método comprueba si el usuario cumple años hoy y devuelve un boolean con el resultado.

Si para obtener la fecha actual del sistema utilizamos:

new Date()

El código no sería testable porque no podríamos cambiarla.
Nota: Esto es solo un ejemplo de como probar código con fechas. Personalmente no suelo probar cada método de forma individual sino que pruebo el comportamiento del sistema.

Primera aproximación: pasar la fecha actual como parámetro

Primeramente veremos la estructura del método a probar y posteriormente el código de los test unitarios. Así el método isBirthday sería como aparece a continuación:

La fecha actual (now) se ha pasado como parámetro, luego se comprueba los dias y meses de los objetos now y dayOfBirthday de tipo Date (se ha omitido esa parte por innecesaria en el ejemplo) y posteriormente se devolverá true o false según estas comprobaciones.

A continuación dos test unitarios que comprueban los dos casos básicos del método, que el usuario cumple años hoy y que no cumple años hoy:

Las variables five_july_2000, six_july_2010 y five_july_2010 son constantes de tipo Date que como no aportan nada al ejemplo he eliminado su definición.

 

Segunda aproximación: obtener la fecha actual con un método que podamos cambiar

Seguimos con el mismo problema pero como obtenemos la fecha actual de un método no necesitamos pasarlo como parámetro. Así, el código del código de producción es:

Los mismos dos test unitarios de la aproximación anterior son implementados en el siguiente código con el nuevo método:

Lo que estamos haciendo en ambos test unitarios es crear una clase anónima que extiende de la clase User, donde está sobrescrito el método getDate con la fecha actual que deseamos.

 

Tercera y última aproximación: Nuestra propia clase fecha del sistema

Esta tercera forma de probar código con fechas la leí en el libro Test Driven de Lasse Koskela y es la que suelo utilizar habitualmente.
Podéis encontrar el código fuente de esta junto con todo el código fuente del libro en la siguiente dirección:

http://www.manning.com/koskela/

El código de producción sería:

La clase SystemTime que hemos utilizado para obtener la fecha actual, es parte de esta tercera aproximación, y consiste en una clase que genera la fecha actual a partir del valor en milisegundo de una instancia hija de la interfaz TimeSource:

que por defecto tiene el valor System.currentTimeMillis() pero que puede ser modificada si le pasamos a SystemTime otra instance hija que implemente la interfaz TimeSource.

El código que nos interesa de la clase SystemTime es:

Así los dos test unitarios quedarían de la siguiente forma:

Como puedes comprobar aunque los test quedan bastante simples, pueden afectar al comportamiento de otros test unitarios que utilicen la clase SistemTime para obtener la fecha actual ya que no será la real.

Para solucionarlo tenemos que asignar a SystemTime su valor por defecto. Para ello, en el método que se ejecutar después de cada test unitario lo añadimos:

 

Ejemplo de donde utilizar estos métodos

Hay un caso en particular que me está viniendo muy bien el poder cambiar la fecha del sistema, y es cuando pruebo procesos en segundo plano.

En general los procesos en segundo plano siempre tienen un campo de tipo Date que la forma de probar que funciona es manualmente: esperar hasta cierto día/hora en concreto para comprobar que ha funcionado como debía.
Si podemos crear test unitarios cambiando la fecha del sistema tendremos más seguridad que nuestro proceso funciona.
Esto no quita que se pueda probar manualmente que el proceso funciona.

 

Conclusiones

Aunque personalmente la aproximación que más me gusta es la última creo que mientras el código sea testeable cualquiera vale.

Modificado 08-01-2017: Cambiado formateo del código a GitHub