Test driven development, take 2
Hará cosa de un par de años estaba tirado en Madrid y buscando curro desesperadamente. Me presenté a una búsqueda de empleo para DL y empezaron los escarceos por email. Mándame esto, respóndeme unas preguntas, etc. Por motivos que no vienen al caso mudarme no me apetecía y, al final, el asunto no fructificó.
Sin embargo aquella prueba tuvo algo muy interesante: mi primer contacto con las metodologías ágiles de trabajo; en realidad es la primera empresa que conozco que preguntan algo de ese estilo en sus contactos de reclutamiento. Me sorprendió positivamente ya que la experiencia general en otras empresas es que la implantación de metodologías modernas siempre es para el siguiente proyecto.
Tanto me gustó el asunto que no he dejado de pensar en ello desde hace un par de años y siempre que puedo le doy algunas vueltas. Aquí van las primeras webs donde tuve oportunidad de aprender algo de desarrollo al test y videojuegos:
A partir de esas dos webs aprendí muchísimo. Realmente power of two resulta mucho más simpática, por aquello de que son pequeñitos y eso siempre es tierno. Pero vamos, ambas webs valen sus kb en oro.
Después de aquello llegaría un período de un año con J2ME y algunos escarceos con TDD orientado a teléfonos móviles, el asunto funciona bien, pero no era mi momento para empezar con aquello.
Así que aquí llegamos: python. Algo bastante asombroso de este lenguaje es que ya viene preparado para trabajar TDD, hay dos paquetes precocinados dentro de las APIs base, podéis leer acerca de ello en:
manual de herramientas de desarrollo para python
Y, por supuesto, aquí tenéis algunos análisis comparativos de las opciones que hay, incluyendo ejemplos, test y opiniones varias:
Llevo unos días dándole vueltas al auténtico problema con respecto al desarrollo: la integración con Maya. Todas las plataformas de test asumen que el entorno de ejecución del test es limpio. Una consola un ejecutable, un proceso automatizado mediante ant, make, scons, o lo que sea. Sin embargo, ¿qué hacer cuando el entorno de desarrollo está embebido en otro software [1]?
De momento he estado trabajando en pruebas en cascada: testSuites que llaman consecutivamente a otros tests, etc. La idea es permitir a los desarrolladores trabajar separados siempre que quieran y, a la vez, automatizar en medida de lo posible el paso de estos scripts.
He hecho un par de casos idiotas: tddSample no sé si alguien bajará estos ficheros, sobra decir que son propiedad de la comunidad, totalmente libres.
En este momento mi intención es tratar de automatizar el pase de Tests a través de maya y que los resultados sean más sencillos de filtrar, el test runner por defecto está bien, aunque es algo molesto cuando los tests se multiplican.
Y de momento es todo. Estas semanas han sido algo liadas, hemos estado en Mundos digitales y hemos visto a viejos camaradas gallegos. Es bonito reencontrarse, tomar pulpo y beber licor café.
–
1. Me viene a la mente Epic y el tipo de pruebas de test de que disponen para testar su Unreal script.