Erlang en la #kataplaya
Erlang en la #kataplaya
Hoy decidimos desafiar a los #katayunos haciendo una #kataplaya. Una kata a 50 metros del mar, en un bonito pub playero. 
Aprovechamos el profundo conocimiento de Joel Reymont (@wagerlabs) del lenguaje Erlang y nos pusimos con el String Calculator en este lenguaje. Aquí se ve el código de la primera iteración, hecha con el mejor TDD que pudimos y un segundo snapshot de código demostrando potencia de Erlang pero dejando a un lado TDD.
Erlang es un lenguaje funcional, que NO está basado en el paradigma de la orientación a objetos. Debo confesar que me ha gustado mucho. Yeray Darias y yo hemos disfrutando viendo nuestras primeras lineas de Erlang 
Me ha gustado más que Lisp y Prolog, aunque ya hace años que no uso ninguno de los dos, pero este parece más limpio (no hay miles de paréntesis juntos). Trabajando con un experto al lado como Joel, hemos podido ver rápidamente por qué Erlang tiene muy buena pinta para escalar. Por un lado, se maneja bastante a bajo nivel, lo que da sensación de ahorrar muchos recursos. Por otro, el estado no se guarda, se procesa. Y al menos en lo que hemos visto hoy, la gestión de la memoria es sencilla, no es como C. Por otro lado, la posibilidad de diseñar una funcion en distintos bloques dependiendo del patterng matching de los argumentos de entrada, evita bastantes bloques condicionales y pareciera que nos ayuda a escribir código más limpio.No te fies de este post como una review seria de Erlang, son sólo mis impresiones despues de dos horas de code kata, en una kata que además es trivial.
A ver para cuándo la siguiente #kataplaya
The stubbing spy
The stubbing spy
Do you really need a stub or do you better use a spy? Or is it a spy object with some stubbed specifications? Let's see some examples using pyDoubles:
You can choose a stub object to prepare the scenario and then, assert on the returned value of the system under test.
def test_using_a_stub(self):
USERID = 20
collaborator = stub(Collaborator())
when(collaborator.one_arg_method).with_args(
USERID).then_return(SUCCESS)
sut = SystemUnderTests(collaborator)
result = sut.exercise_method()
assert_that(result, equal_to(OK))
The test above says: "I don't really care what the SUT does internally as long as the returned value is the expected, but it might need help from a collaborator, so I set it up, just in case."
Note the "might" part of the sentence. It is not necessary to specify the possible arguments in the call to the collaborator. This tests is more robust and still serves the same:
def test_stub_simplification(self):
collaborator = stub(Collaborator())
when(collaborator.one_arg_method).then_return(SUCCESS)
sut = SystemUnderTests(collaborator)
result = sut.exercise_method()
assert_that(result, equal_to(OK))
Now, let's replace the stub with a spy object, assuming we don't need to specify any stub behavior:
def test_if_arguments_are_important_check_them_out(self):
USERID = 20
collaborator = spy(Collaborator())
sut = SystemUnderTests(collaborator)
result = sut.exercise_method()
assert_that_method(collaborator.one_arg_method
).was_called().with_args(USERID)
assert_that(result, equal_to(OK))
The test above means: "The SUT needs to call its collaborator at least once in order to complete the operation. I want to make sure that happens apart from getting the expected value."
Depending on the problem, we can have just one test with the 2 asserts, or maybe 2 tests, with one assert each.
We didn't need to define any stub method, but what if we need it?:
def test_if_arguments_are_important_check_them_out(self):
USERID = 20
collaborator = spy(Collaborator())
when(collaborator.one_arg_method).then_return(SUCCESS)
sut = SystemUnderTests(collaborator)
result = sut.exercise_method()
assert_that_method(collaborator.one_arg_method
).was_called().with_args(USERID)
assert_that(result, equal_to(OK))
We don't tell the stub what arguments is going to receive. That is not important. The stub part is intended to prepare the scenario. The easier the scenario setup is, the better. We do assert on the arguments at the end of the execution.
Conclusion:
If calling the collaborator is a critical part of the action, use a spy and make sure arguments are passed in as they should. If you need to stub out a method in the spy object, do not specify the arguments in the stub definition. In the stub definition, just tell the framework the returned value and later on, assert on the arguments once the system under test execution has finished
Reason: If you specify arguments in the stub definition and also don't assert at the end, you need to debug the failing test to find out that maybe some argument wasn't passed in.
It is more efficient to let the doubles framework tell you what was wrong
Cartel de lujo en la #XPweek
Cartel de lujo en la #XPweek
Del 20 al 23 de septiembre de 2011, tendrá lugar la #XPweek en Madrid. Se trata de los dos cursos abiertos de iExpertos, sobre iniciación a TDD y TDD avanzado, donde además veremos otras cuestiones de XP como la programación en pareja y el ciclo de desarrollo de los proyectos. En esta ocasión contaremos con la actuación estelar de algunos de los profesionales más importantes del país:
Alfredo Casado: Estará con nosotros en el curso de introducción (20 y 21) hablandonos sobre legibilidad de los tests. Cómo escribir tests para humanos con la ayuda de herramientas como Hamcrest. Alfredo es uno de los desarrolladores con más experiencia en eXtreme Programming en España. Además es un excelente docente, de hecho, ha impartido clases en varias universidades.
Enrique Amodeo: Estará también el en curso de introducción hablándonos del Principio de única responsabilidad (SRP) y de refactoring de manera práctica. Enrique lleva años practicando XP y liderando equipos de desarrollo. Sin duda una de las figuras más destacadas del país en cuanto a desarrollo ágil y arquitectura del software.
Xavi Gost: En el curso de TDD avanzado, Xavi nos hablará de BDD con Javascript, Jasmine y de arquitectura Javascript. Nos presentará su framework Javascript y tendremos la oportunidad de aprender sobre arquitectura SPI. Xavi Gost es probablemente el más veterano de todos nosotros en prácticas de ingeniería ágiles. Actualmente al frente de BeCodeMyFriend, la incubadora punk.
Alberto Vilches: Alberto es referente nacional en tecnología Grails. Como el framework base para nuestro curso de TDD avanzado será Django, Alberto nos ayudará a entender cómo los conceptos explicados se pueden aplicar en Grails. Nos dará trucos y consejos para sacarle el máximo partido a todo lo que vemos en el curso.
Yo seré docente en ambos cursos y estaré encargado de coordinar la participación de estos grandes profesionales en las distintas etapas por las que vayamos pasando.
Aún quedan plazas libres, escríbenos a info@iexpertos.com para reservar la tuya
TDD: resultados empíricos
TDD: resultados empíricos
Hace poco en una code kata alguien me dijo, ... "y qué ventajas tiene esto de hacer TDD?". Le dije... en nuestro proyecto, actualmente con casi 25.000 lineas de código Python (multiplica x4 si piensas en Java), no hemos necesitado nunca bugtracker. Cuando ha aparecido algun bug, se ha corregido enseguida y vuelto a subir a producción. Podemos hacer una release a producción cada dos días y sólo con una persona de QA, que dedica 10 minutos antes de cada release. No llegamos al continuos deployment por falta de recursos pero estamos muy cerca.
Cuando tenemos que hacer un cambio, lo hacemos en cuestión de horas o minutos y podemos subir a producción con total garantía (98%) de no haber roto nada.
Cualquiera del equipo le puede meter mano a cualquier parte del proyecto.
Lógicamente no obtenemos estos resultados por la practica de TDD en exclusiva, sino por todas las practicas y valores de eXtreme Programming (recuerda que TDD/BDD es una parte de XP).
Y todavía podía seguir enumerando ventajas. Sin embargo, el código de nuestro proyecto no es open source, así que la gente tiene que creernos. Ahora, con pyDoubles, puedes ver los resultados tu mism@:
Resultados empíricos basados en pyDoubles:
En la última release del framework, la 1.2, hemos conseguido compatibilidad total con Hamcrest, el framework más conocido de matchers, para mejorar la legibilidad de los tests. Estratégicamente esto hace que pyDoubles pueda convertirse en un framework de referencia, ya que Hamcrest es muy popular y ahora ambos frameworks encajan perfectamente. Es un gran logro a nivel de negocio, teniendo en cuenta que queremos que pyDoubles sea usado.
¿Sabes cuanto nos ha costado a nivel de desarrollo? 3 horas de trabajo. Puedes ver los commits que se han hecho de la version 1.1 a la 1.2 si quieres mas datos objetivos. Nunca habiamos visto el código de Hamcrest ni habíamos desarrollado pyDoubles pensando en Hamcrest, sin embargo, hemos desarrollo siguiendo SOLID, dejando todo abierto a extensión y cerrado a modificación. El resultado es contundente. Apenas un poquito de esfuerzo para alcanzar un gran resultado.
¿Cuánto nos podía haber costado esto sin hacer bien TDD? Probablemente semanas de trabajo. Probablemente haber tirado medio framework y haberlo tenido que reescribir, con el riesgo de cargarnos por el camino las funcionalidades existentes.
En esta release 1.2 no solo hemos tardado poco, sino que estamos seguros de que no se ha roto ninguna funcionalidad.
¿Cuál es el orden de beneficio de esta forma de trabajar? Dificil de cuantificar pero la sensación es de ser 10 veces más productivos. Entonces ahora ¿es más caro o es más barato hacer un buen TDD/BDD?
No necesitamos convencer a nadie, los datos empíricos van demostrando las ventajas por su propio peso
Olvídate de convencer a tu entorno sobre las ventajas de XP, practica con el ejemplo.
Próximo dojo: el reto XP
Próximo dojo: el reto XP
El próximo martes 12 de julio, facilitaré un coding dojo en las instalaciones de DECiDE, que llevará por título, El reto XP.
Este evento es totalmente gratuito y las plazas son limitadas. Para inscribirse, está la siguiente url: http://decide.stagehq.com/events/916
El dojo no estará basado en una kata sino que tendrá un formato eliminatoria. Se planteará un reto a los participantes que les ayude a medir su nivel de interiorización de las prácticas y valores de eXtreme Programming. A lo largo de la jornada, algunas parejas irán siendo eliminadas aunque tendrán posibilidad de volver al juego en alguna ocasión.
Como siempre, hay que venir al dojo con el portátil y el entorno de desarrollo favorito instalado. Empezaremos a las 17h y la duración máxima será de 3 horas. Se programará en pareja pero no es preciso venir en pareja.
De nuevo, otro evento gratuito de la mano de iExpertos , con la inestimable colaboración de Decide.