La masa, el ladrillo, la bota, el bocadillo...

Pero que pasa cuando no tienes clara la arquitectura a utilizar ?, recientemento he empezado a trabajar con pruebas unitarias y uno de los problemas con los que me encuentro es el de tener que reacerlas constatemente, cuando no tienes claro el diseño de una aplicación normalmente vas aproximandote hacia esta, en varios pasos, y esto te obliga a tener que rehacer de forma constante tu código y de la misma forma las pruebas unitarias, y el tiempo que se pierde, buff..., no se si al final compensara..., estoy convencido de que de es gran ayuda tener una bateria de pruebas unitarias, pero cuando los desarrollos van ha sufrir muchos cambios a lo largo del proceso, quizas la solución este en escribirlas al final. Aunque recuerdo alguien que me dijo "en ese caso, seguro que no realizaras las pruebas, una vez hayas terminado la aplicación". Creo que todavian deben mejorar los sistemas para soportar pruebas unitarias, es mas estoy convencido que en poco tiempo muchas de las pruebas que realizamos podran generarse de forma automática por el sistema, pero tambien creo que debemos avanzar en este sentido para mejorar la calidad del software aunque todavia tengo muchas dudas, quien debe desarrollar las pruebas ?? los programadores, expertos en testing... además, la parte de los mock objects, todavía deja mucho que desear es muy costosa y muchas veces te obliga cambiar el desarrollo para poder testearlo.

Aunque entiendo a Juan perfectamente, creo el problema de no entender la necesidad de las pruebas unitarias es debido principalmente a un “erróneo” enfoque de lo que son las iteraciones. Debemos empezar a pensar que iteración es algo así como requisitos+código+test+loquieranustedes.  

Entiendo que en cada iteración debería entrar la codificación de requerimientos, la creación de las pruebas unitarias (si es antes o después de codificar los requerimientos no me meto), y un chequeo del cliente/responsable/lo que sea. Una vez concluido el  plazo se entra en la siguiente iteración donde:

-Podemos cambiarlo todo porque no es lo que se pedía: Es una evolución donde tendremos que reescribir algunos métodos y por supuesto sus test.

-Añadimos nueva funcionalidad: tendremos que escribir nuevas “cosas” y adaptar los anteriores clases para que encajen lo nuevo. Una vez más hay que adaptar las pruebas unitarias.

Al final de cada iteración podemos lanzar los test unitarios y ver que el código generado/adaptado en esa iteración y en todas las otras iteraciones posteriores es correcto. Es la única forma de asegurarse que estamos haciendo las cosas con pruebas demostrables. Dejarlos todos para el final es una autentica locura porque ¿a quién se le ocurriría, por ejemplo, escribir más de 1000 test de una tirada? Es un trabajo tan tedioso que yo no conozco a nadie  que tenga tanta paciencia para hacerlo con calidad (sin dejarse nada de lado). Y ya que hablamos de calidad, lo test unitarios son una prueba (necesaria) de que hemos hecho un software de calidad, ¿no? Aunque evidentemente para hacer un software de calidad tenemos que tener en cuenta muchas más cosas…

Saludos

Bueno, el crear los test unitarios antes que las funcionalidades  obliga a los programadores a que piensen antes de programar, pero que piensen en resultados (que es lo que se pide) y en las formas.

Muchos desarrolladores (incluidos los míos) se ponen a programar con la idea de lo que tienen que hacer. Muchas veces esta idea es a nivel de Interfaz de usuario o de resultados concretos, sin haber pensado antes qué patrones de diseño deben aplicar, qué clases, qué interfaces, etc.. Al obligar a realizarse antes los test unitarios obligamos a que piensen en la implementación que tienen que hacer: Resultados + Forma de lograrlo.

Además sirve para autoestimarse en tiempo. Un desarrollador debe tener el buen hábito de, a primera hora de la jornada, ponerse una meta de un x por ciento de los test para el fin de la jornada. Usar esta métrica le ayudará a demostrar y justificar su trabajo.

Evidentemente hay programadores que necesiten que se le inculquen este tipo de reglas y otros que son lo suficientemente disciplinados para no necesitarlos porque piensan como deben de pensar y saben cuánto tiempo les lleva cada cosa.  Pero todos fallamos alguna vez (y muchas) y para eso están los métodos, aunque siempre hay que buscar el equilibrio entre la opresión del método y la libertad artística del programador.

Estoy deacuerdo con todos vosotros, pero pienso en el tiempo invertido, en mi caso mi equipo de desarrollo es muy pequeño y tengo que variar mucho el diseño, pues hay que hacer todo el trabajo, incluido el analisis, el problema radica en que muchas veces el cliente no tiene clara las necesidades, y vas implementado nueva funcionalidad a medida que ven funcionando la aplicación, pues es en ese momento y solo entonces cuando se dan cuenta de que falta esto o lo otro, se que este es un error muy común a la hora de diseñar aplicaciones, pero seamos serios, es mi realidad y la de muchos desarrolladores, enfrentarse a proyectos con poca gente, muy largos en los que las especificaciones cambian acompañadas al desarrollo, esto me obliga a perder mucho tiempo con las pruebas unitarias, por ejemplo cuando incluyo un campo nuevo en un procedimiento almacenado o simplemente cuando inserto un campo nuevo en una tabla.

Entiendo que al final lograremos un código de mas calidad, pero a veces hay que balancear para conseguir un buen rendimiento. Ademas si realizo las pruebas unitarias una vez he trazado la linea básica del proyecto, pierdo una de las premisas de Agile, que te aconseja realizar la pruebas unitarias antes del código.

Otro de los problemas con los que me he encontrado es que algunas veces las pruebas unitarias tienden a alterar mi codigo, por ejemplo en el caso de los mock, no puedo utilizar pruebas unitarias con clases estaticas ya que tengo que implementar un interface, asi que las pruebas estan condicionando mi código.

Pero sigo creyendo que son un primer paso para mejorar la calidad del código, aunque pienso todavia tienen que evolucionar bastante y son dificiles de adaptar en entornos de desarrollo similares al mio.

PingBack desde  Algo m??s sobre desarrollo ??gil y TDD » Innova Desarrollos informáticos

Una duda que me plantean habitualmente cuando hablo de testeo unitario en una charla o cuando trato de

La idea de hacer test unitarios es muy buena, de echo me sirvio mucho utilizar pequeños test unitarios al principio de un proyecto porque me da la fiabilidad de que las clases que estoy utilizando funcionan correctamente y ademas me proporcionan la posibilidad de capturar el error si es que este llegara a existir y desplegarlo, sin duda es una gran herramienta pero algo dificil de implementar, deberia existir herramientas mas sencillas de manejar y un poco mas eficientes.

quisiera un buen test para autoestimarme

No estoy de acuerdo con Miguel Angel Ramos en lo siguiente

"

-Podemos cambiarlo todo porque no es lo que se pedía: Es una evolución donde tendremos que reescribir algunos métodos y por supuesto sus test.

-Añadimos nueva funcionalidad: tendremos que escribir nuevas “cosas” y adaptar los anteriores clases para que encajen lo nuevo. Una vez más hay que adaptar las pruebas unitarias.

"

Basicamente estas diciendo que al agregar/modificar alguna funcionalidad habra que modificar/adaptar las pruebas, en mi opinion eso proviene de un concepto erroneo, porque una prueba lo unico que hace es testear una funcionalidad en un momento del desarrollo del software. Y una vez agregada y testeada esa funcionalidad no hay razon para eliminarla del sistema (ya sea simplemente quitandola o modificandola), por lo tanto en un desarrollo nunca se quitara una funcionalidad... y no habria motivos para modificar un test

Ej, si se le agrega un campo a un stored procedure, o un argumento nuevo a un metodo... es cierto que hay que escribir los tests para la nueva funcionalidad, pero los tests preexistentes de ese metodo se mantienen identicos (sin la mas minima modificacion) ya que la funcionalidad que tenia hasta entonces no se eliminara.

Si fuera el caso de tener que cambiar el comportamiento de alguna clase o metodo, tambien seria incompatible con esa logica, y se deberia definir otra clase u otro metodo distinto y mantener los originales como estaban.

Repito, esto que digo gira en torno a que el desarrollo siempre crezca funcionalmente, es decir, que nunca se elimine o deshabilite una funcionalidad a drede. No estoy diciendo que por el hecho de usar TDD esto tenga que ser asi..., mas bien es el TDD el que esta avisando de que esto conviene que sea asi

Todo lo demas que dijiste me parecio muy acertado, sobre todo la idea de no escribir las 1000 pruebas al final, sino hacerlo en cada momento para cada funcionalidad

No estoy de acuerdo con Miguel Angel Ramos en lo siguiente

"

-Podemos cambiarlo todo porque no es lo que se pedía: Es una evolución donde tendremos que reescribir algunos métodos y por supuesto sus test.

-Añadimos nueva funcionalidad: tendremos que escribir nuevas “cosas” y adaptar los anteriores clases para que encajen lo nuevo. Una vez más hay que adaptar las pruebas unitarias.

"

Basicamente estas diciendo que al agregar/modificar alguna funcionalidad habra que modificar/adaptar las pruebas, en mi opinion eso proviene de un concepto erroneo, porque una prueba lo unico que hace es testear una funcionalidad en un momento del desarrollo del software. Y una vez agregada y testeada esa funcionalidad no hay razon para eliminarla del sistema (ya sea simplemente quitandola o modificandola), por lo tanto en un desarrollo nunca se quitara una funcionalidad... y no habria motivos para modificar un test

Ej, si se le agrega un campo a un stored procedure, o un argumento nuevo a un metodo... es cierto que hay que escribir los tests para la nueva funcionalidad, pero los tests preexistentes de ese metodo se mantienen identicos (sin la mas minima modificacion) ya que la funcionalidad que tenia hasta entonces no se eliminara.

Si fuera el caso de tener que cambiar el comportamiento de alguna clase o metodo, tambien seria incompatible con esa logica, y se deberia definir otra clase u otro metodo distinto y mantener los originales como estaban.

Repito, esto que digo gira en torno a que el desarrollo siempre crezca funcionalmente, es decir, que nunca se elimine o deshabilite una funcionalidad a drede. No estoy diciendo que por el hecho de usar TDD esto tenga que ser asi..., mas bien es el TDD el que esta avisando de que esto conviene que sea asi

Todo lo demas que dijiste me parecio muy acertado, sobre todo la idea de no escribir las 1000 pruebas al final, sino hacerlo en cada momento para cada funcionalidad

No deja de sorprenderme cuanta gente le da una importancia excesiva al valor de la cobertura. Entiéndaseme