Ejemplo mejorado de doble de test

El artículo anterior trataba de un ejemplo de doble de test de tipo stub.
El stub se llama StubUserDAO e implementa el método findUserBy, devolviendo siempre el mismo objeto.

Si quisiéramos que findUserBy devolviera otro User tendríamos que crear otra clase como StubUserDAO que devolviera ese User, ya que StubUserDAO siempre devuelve el mismo User.

Como puedes imaginarte, no es una solución flexible, ya que casi con cada nueva prueba tenemos que crear una clase parecida a StubUserDAO.

Para solucionar este problema, en este artículo te quiero presentar la versión de un doble de tipo de tipo stub:



La principal diferente, de este doble de test en relación con el anterior es que podemos cambiar el User que va a devolver el método findUserBy.
Podemos cambiar el usuario que devuelve el método utilizando el método.
En el código, el test should_throw_exception_when_passwords_are_different_version1 hace que que StubUserDAOv2 devuelva un usuario con contraseña "other_password", y el test should_throw_exception_when_passwords_are_different_version2 hace que devuelva un usuario con contraseña "another_contraseña".

Como he comentado al principio, la principal ventaja de este tipo de stub es flexible ya que permite devolver diferentes tipos de valores sin tener que crear una nueva clase.
Otra ventaja de este tipo de stub es que la configuración del stub para que devuelve el usuario es el propio stub. Al tener la configuración en el stub queda claro lo que estamos probando, porque podemos ver la contraseña del usuario y la contraseña que utilizamos en el signin al mismo tiempo ya que están al lado.
Esto simplifica mucho el comprobar que es lo que fue mal cuando el test falla.

Un par de comentarios sobre el ejemplo:

• Recuerda inicializar siempre stub. Así nos evitamos desagradables efectos secundarios como que si ejecutas todos los test no todos pasan, pero si ejecutas uno en concreto pasa (también puede ser el efecto contrario). Esto es debido a que un test comparte usuario con otro test a través del stub.
• Hay que utilizar como atributo en la clase de test el objeto StubUserDAOv2, y no UserDAO. Parece una tontería pero la primera vez que creé el stub, me quede un buen rato atascado porque Eclipse me decía que no podía utilizar el método setUserFoundByEmail y era porque utilicé UserDAO:

Refactorizar y test unitarios

Imagen de http://blog.arnaud-lefebvre.fr/

El proceso que sigo cuando estoy desarrollando una nueva funcionalidad es:

1. desarrollo la nueva funcionalidad de la forma más rápida posible para que simplemente funcione.
2. refactorizo el código para que sea más fácil de entender y para que sea más fácil de mantener.

Refactorizar es cambiar el código sin cambiar su comportamiento. El código debe de funcionar de la misma manera antes y después de cambiarlo.
Refactorizar consiste en muchos cambios pequeños en el código que hacen que nuestro código y diseño mejoren.

Cada vez que cambiamos nuestro código hay que comprobar que funciona. Los test unitarios son la forma más rápida que conozco de comprobar que el código funciona.
Si no tengo test unitarios tengo que ejecutar la aplicación y comprobar manualmente que el código que he cambiado funciona. El refactorizar se hace muchas veces por lo que hacer esta comprobación consumirá mucho de nuestro tiempo.

Resumen

Refactorizar es muy importante en mi proceso de desarrollo porque hace que mi código sea fácil de entender y de mantener.
Escribo test unitarios ya que es la forma más rápida que conozco de comprobar que mi código sigue funcionando después de refactorizar.
Si refactorizar es también importante para ti, test unitarios también deberían de ser importante debido a que la otra opción, que es comprobar de forma manual, te va a tomar mucho mas tiempo.

My first project with Scrum

Image from http://www.3news.co.nz

Introduction

I've been working on a new project for the last few months. I worked with two external developers on this project. One of them has experience as Scrum master so the team decided to use Scrum as the methodology in the project.
I'd read a lot about Scrum and I'd applied some practices in the past but I'd never used Scrum by the book.

In this blog I've written a summary about my experience using Scrum in a project that was built from scratch.

I´m not going to talk about the practices of Scrum, so if you want to know more, a good place is:

http://www.scrumguides.org/

you can find there the official guide of Scrum in many languages.

Pros

• Retrospectives really work. Every retro helped us to discover the problems in the sprint and to solve them. For example, part of the team didn't work at the office and that caused communication problems. The communication improved thanks to the retros and the actions that we took in each one.
• Team building. We spoke a lot, and because of all the meetings we knew each other and came together as a team. I was new in the company and I didn't know my colleagues nor the external developers. I believe we made a good team in few months due to the scrum practices.
• The product's design is understood for each member of the team. In this case, sprint meetings allowed us to understand the whole design of the application. That could also improved the design because many decisions were taken together.

Cons

• Scrum can be used as a tool for micromanaging the team. That could happen when dailies and retros are done in the wrong way. Dailies would just be about the status of each story and retros would just be about checking estimations in detail. It didn't happen but I realized how a person could transform scrum into something ineffective.
• Feedback in the last part of the project. We did an acceptance test after the development had finished where most of the company participated and we received a lot of feedback. I see this like a negative thing because we couldn't transform the feedback into new features. Our sprints were two weeks long and the last day of each sprint we did a demo where all the people involved in the product attended, including the people who gave us feedback in the acceptance test.

I'd like to add that we could apply the use of Scrum better because, for example, we had to write documents and other tasks after the development had finished and they should have been included in the project.
Furthermore, our main problem was that we didn't have a product owner and a colleague had to play that role. I believe the highest benefit of Scrum and other Agile methodologies is that the value is maximize and due to the fact that we didn't have a proper product owner that benefits were decreased.

The next blog explains the meaning of value very well:

http://ronjeffries.com/xprog/articles/value-is-what-you-like/

The same writer has just released a book with the title "the nature of software development" and is amazing. It has a little more than 100 pages that explains in the most clear way possible what software development is about. I've read it recently and it´s a really nice book.

Recap

I'm happy with the end result of the project although we could do it better . I love how Scrum practices allow us to improve the team performance and the development process.

Scrum doesn't have development practices and I miss them because developing an incremental and iterative product without them is very hard. For example, TDD and continuous integration.
So, in regards to development practices XP is better than Scrum because it includes many practices for us, programmers.

* 22-06-2015 Solved grammar error