04 abril 2007
Test unitarios en grupos de trabajo
No es la primera vez que en este blog se habla de test unitarios y seguramente esta no será la última, pero en este caso voy a dejar un poco al lado la teoría y hablaré de la práctica, del uso diario que se le puede dar a los test unitarios y que tratamos de aplicar en Unkasoft.
Una de los desarrollos actuales de Unkasoft es Unkasoft Platform, una herramienta para atajar el problema de la fragmentación en el mundo de los móviles y que permite, de una forma cómoda, crear todos los contenidos para desarrollar un juego en una amplia gama de móviles. Aunque estemos acostumbrados a ver multitud de herramientas gráficas para todo (grabar un CD con Nero, crear imágenes con photoshop), muchas veces es difícil darse cuenta de la complejidad que hay por debajo.
En el desarrollo de Unkasoft Platform trabajamos un grupo de personas, cada cual hace y deshace parte del código, corrige bugs, incluye nuevas características, pero es imposible que en un proyecto con cierta complejidad, como es UP, una sola persona esté al tanto de todos los posibles efectos colaterales del cambio de una clase o un método. Por ello la existencia de unos test unitarios impide (bueno, hace más difícil :) que un error cometido en una parte de código se propague a las demás. Si alguien hace un cambio que afecta al código de un miembro del equipo (que puede ser él mismo) ,cuando pase los test unitarios verá con facilidad que y donde la está liando.
La cosa no termina ahí. Las aplicaciones con un entorno gráfico suelen tener una curiosa inercia hacia el caos. Es habitual ver como el modelo vista controlador se convierte en un modelo de "controlo desde la vista", donde, por ejemplo, se ve como la gestión de los datos se implementa en un callback de un botón o similar. El uso de test unitarios te obliga a tener que separar lo más posible la parte controlador del resto ya que solo de esa forma es posible programarlos.
Como conclusión es fácil ver que "gastar" un poco de tiempo en realizar las pruebas unitarias te puede ahorrar horas de debug corrigiendo problemas que han incluído los demás o peor, tú mismo, o intentando refactorizar código distribuido por callbacks de botones.
Una de los desarrollos actuales de Unkasoft es Unkasoft Platform, una herramienta para atajar el problema de la fragmentación en el mundo de los móviles y que permite, de una forma cómoda, crear todos los contenidos para desarrollar un juego en una amplia gama de móviles. Aunque estemos acostumbrados a ver multitud de herramientas gráficas para todo (grabar un CD con Nero, crear imágenes con photoshop), muchas veces es difícil darse cuenta de la complejidad que hay por debajo.
En el desarrollo de Unkasoft Platform trabajamos un grupo de personas, cada cual hace y deshace parte del código, corrige bugs, incluye nuevas características, pero es imposible que en un proyecto con cierta complejidad, como es UP, una sola persona esté al tanto de todos los posibles efectos colaterales del cambio de una clase o un método. Por ello la existencia de unos test unitarios impide (bueno, hace más difícil :) que un error cometido en una parte de código se propague a las demás. Si alguien hace un cambio que afecta al código de un miembro del equipo (que puede ser él mismo) ,cuando pase los test unitarios verá con facilidad que y donde la está liando.
La cosa no termina ahí. Las aplicaciones con un entorno gráfico suelen tener una curiosa inercia hacia el caos. Es habitual ver como el modelo vista controlador se convierte en un modelo de "controlo desde la vista", donde, por ejemplo, se ve como la gestión de los datos se implementa en un callback de un botón o similar. El uso de test unitarios te obliga a tener que separar lo más posible la parte controlador del resto ya que solo de esa forma es posible programarlos.
Como conclusión es fácil ver que "gastar" un poco de tiempo en realizar las pruebas unitarias te puede ahorrar horas de debug corrigiendo problemas que han incluído los demás o peor, tú mismo, o intentando refactorizar código distribuido por callbacks de botones.
Etiquetas: agile, programación, TDD
