Test Driven Development: Pruebas de Software a priori

En Abril del 2007 di una platica en la UACJ que llevó el mismo título de este post.

Dicha plática se dio dentro de las actividades de la Sociedad de Estudios en Computacion, sociedad que liderea el profesor Saúl González.

Desempolvé este tema porque veo útil mostrar lo que es TDD (Desarrollo Orientado a Pruebas) y cómo TDD ayuda al desarrollo y al mantenimiento de un sistema. Tradicionalmente las pruebas de una aplicación  representan una tarea monótona y talachera  (entiéndase manual, repetitiva y sujeta al error humano).

Pones a un equipo de monos a ejecutar Test Cases y que Dios nos agarre confesados!!, la idea es que hagan pedazos la aplicación, la idea es que encuentren cual Sherlock Holmes todos los bugs habidos y por haber. Lo cual en la práctica, no es una tarea sencilla, depende de la pericia del tester, depende de que tan bien estén diseñadas las pruebas, depende de muchos factores.

En sistemas complejos, lo que más quieres es controlar esos factores, con TDD puedes controlar que las Pruebas Unitarias se cumplan, las cuales son un factor crucial en los sistemas diseñados bajo el Paradigma de Orientados a Objetos.

Que es TDD?

Es una metodología de desarrollo de Software que consiste en implementar las pruebas unitarias antes de comenzar a escribir el código de un modulo

Las pruebas unitarias consisten en comprobaciones (manuales o automatizadas) que se realizan para verificar que el código correspondiente  a un modulo concreto de un sistema funciona de acuerdo con los requisitos del sistema.

Ø  Tradicionalmente las pruebas se realizan a posteriori, es decir, después de codificar la funcionalidad

Ø  En TDD, las pruebas se preparan antes de comenzar a escribir el código

Primero se escriben los casos de prueba y después se implementa el código necesario para que la prueba pase con éxito

Por lo general las pruebas son métodos que ejecutan una acción específica, por ejemplo:

•         CrearUsuario()

•         CalcularArea()

•         BloquearPassword()

•         BorrarFactura()

•         SacarLaBasuraPorLasMañanasAntesDeQuePaseElCamionRecolector()

Tipos de pruebas

Hay muchas pruebas que se le pueden (deben) hacer al software antes de liberarlo. De otra forma la calidad no va a estar garantizada. Hoy en día nadie se pondría una vacuna que no paso por años de pruebas, sin embargo en la industria de software aun hay Cromañones que no les cae el veinte con esto de las pruebas.

Existen varios tipos d pruebas, por citar algunos:

•         Pruebas de usuario

•         Pruebas cruzadas

•         Pruebas Unitarias

•         Pruebas de regresión

Que son las pruebas Unitarias en TDD?

En TDD una prueba unitaria no es otra cosa que código que permite probar los módulos mediante condiciones de prueba.

Las pruebas son diseñadas por el desarrollador y por los expertos del negocio. Estas pruebas se pueden automatizar usando una herramienta como NUnit. Una ventaja de automatizarlas es la posibilidad de lanzar las pruebas tantas veces como sean necesario. En caso de haber cambios en la funcionalidad al correr la prueba se puede verificar si se siguen cumpliendo las reglas de negocio de los objetos.

Ventajas de usar TDD

•         Al escribir primero los casos de prueba, definimos de manera formal los requisitos que esperamos que cumpla nuestra aplicación. 

•         Al escribir una prueba unitaria, pensamos en la forma correcta de utilizar un módulo que aún no existe.

•         Se puede automatizar la ejecución de los casos de prueba (por ejemplo, con ayuda de algún framework de pruebas como NUnit)

•         Los casos de prueba nos permiten perder el miedo a realizar modificaciones en el código.

•         Los casos de prueba definen claramente cuándo termina nuestro trabajo (cuando pasan con éxito todos los casos de prueba)

•         Se puede obtener un avance real de la fase de contruccion, basándonos en el code coverage 

•         Esta práctica es compatible con el Desarrollo Agil (Agile Development).

•         TDD permite fácilmente la refactorización.

•         TDD fomenta la disciplina del equipo de programación

Proceso de desarrollo con TDD

•         Escribir solo el código necesario, que cumpla con la funcionalidad requerida.

•         Pasos de este proceso:

–        Diseñar las pruebas unitarias

–        Escribir el esqueleto de los modulos (o clases) necesarios para la prueba

–        Escribir las pruebas unitarias

–        Ejecutar las pruebas unitarias

–        Codificar los mínimo requerido para que pase cada prueba unitaria asociada a un modulo.

–        Ejecutar la prueba y verificar que pase correctamente.

–        Iterar

Herramientas para hacer pruebas automáticas

•         Existen un número considerable de herramientas que nos pueden ayudar para automatizar las pruebas unitarias.

•         Usualmente son frameworks que permiten rápidamente escribir “código que prueba código”.

•         La elección de la herramienta dependerá de la naturaleza del proyecto.

•         Algunos de los más conocidos son:

–        Microsoft Team System

–        NUnit

–        MbUnit

–        JUnit

–        csUnit

–        TBrun

–        XTest

–        y muchos mas

Limitaciones de TDD

Hay que tener precaución al decidir cuándo usar TDD. No es recomendable usar TDD cuando:

• Por la naturaleza de la aplicación  no sea factible automatizar las pruebas
• No se tenga un conocimiento solido de la Programación Orientada a Objetos (no es suficiente usar lenguajes orientados a objetos, hay que pensar en objetos)
• El equipo esté formado por desarrolladores poco experimentados. Se requieren fuertes habilidades técnicas y de análisis para producir buenas pruebas.
• Los requerimientos no estén definidos en forma clara.
• No se cuente con expertos en el negocio dentro del equipo
• Exista mucha rotación de personal en el equipo

Si aplicas mal o a medias TDD puedes encontrarte los siguiente problemas:

•         Generar pruebas mal diseñadas que no te sirvan para determinar si tus objetos tienen el comportamiento esperado.  La calidad de la prueba depende del conocimiento del desarrollador.

•         Se puede invertir mucho tiempo en hacer pruebas y dejar corta la fase de construcción.

•         Diseñar pruebas poco representativas, que no cumplan con un code coverage que en algún momento dejen de usarse

•         Invertir mucho tiempo en hacer las pruebas y no darles mantenimiento, lo cual representa un gasto inútil de tiempo.

Google Chrome OS

La Union Europea esta enfrascada en una demanda contra Microsoft por integrar Internet Explorer a su Sistema Operativo, lo cual va en contra de la libre competencia.

Y me pregunto, le lloverán demandas a Google por integrar su Sistema Operativo a su Navegador??

Por lo pronto, si me gustaria que mi computadora inicie en 7 segundos

Disparar y avanzar

Acabo de leer un post de Joel Spolsky, un cuate que tiene una pequeña compañía de software en New York y que tiene mucha razón en lo que escribe.Su post es muy recomendable porque refleja cosas tan cotidianas que siempre nos preguntamos los desarrolladores:

• Porque en veces no me concentro para programar?
• Porque me concentro cuando ya es la hora de salida?, jaja, típico
• La programación requiere mas inspiración que transpiración?
• Es posible trabajar 40 horas a la semana sin comprometer el rendimiento y los entregables?
• Ganará algún partido los Indios de Juarez esta temporada?

Y también habla de cosas tan profundas como las estrategias comerciales, que pueden llevar a una empresa a la quiebra o al crecimiento. Incluso estrategias que van fijando el rumbo de la tecnología misma.

Me gusta la analogía que hace entre las estrategias militares y la industria del software, el mundo del software esta íntimamente ligado con estas estrategias. Seguramente han escuchado el principio de Divide et vinces (Divide y vencerás), frase que le atribuyen al emperador Julio Cesar, algunos manejan que Maquiavelo la adopto en su libro El Príncipe.

Esta máxima se usa en algoritmos de recursividad, que consiste en dividir un problema en partes mas chicas, las cuales son mas manejables y fáciles de resolver. Como se dice vulgarmente “Si el marrano esta muy grande, hay que hacerlo carnitas”

Regresando al post de Spolsky, plantea que en la industria del software hay que “Disparar y avanzar”, para no perecer en el camino.

Les ha pasado que quieren implementar muchas mejoras en su proyecto, las cuales les facilitarían la vida enormemente y que no las implementan porque se la pasan resolviendo problemas cotidianos, amoldándose a nuevos estándares, ajustándose a nuevas tecnologías, etc.?

Lo anterior es síntoma de que estas recibiendo mucho “fuego enemigo”, te la pasas cubriéndote de las balas, y se te va el tiempo en atender lo que la competencia te dicta.

Cuando no se esta a la vanguardia y se trabaja siempre en la retaguardia, se corre el riesgo de que el “enemigo” (la competencia), dispare y avance sin encontrar ninguna resistencia. No les digo mas, vale la pena leerlo:

Versión original en Ingles

Versión traducida al Español

No me gusta el código comentado

Esta entrada trata sobre una mala practica de programación que afortunadamente esta quedando en desuso, al menos por los buenos programadores.

Me refiero al famoso código comentado, que no es lo mismo que documentar código, en términos prácticos el código comentado es basura, son líneas que a nadie benefician y que si perjudican mucho al momento de dar mantenimiento a un sistema.

Imaginemos que un escritor esta escribiendo (valida la rebuznancia) un nuevo libro, para llegar a la versión final tiene que pasar por numerables etapas, muchos ensayos, muchos borradores; tiene que pasar por la revisión de mucha gente antes de ser publicado. En este proceso creativo el escritor va a transformar su idea, escribir y reescribir una y otra vez líneas y líneas que se irán quedando en papeles hechos bola en la papelera.

Te gustaría comprar un libro y que traiga 3000 hojas, de las cuales solo la mitad sea contenido?, y que las otras 1500 sean anotaciones, versiones preliminares, apuntes, borradores, calis de ese libro que tanto esperas leer??

En lo personal no me gusta leer escritos que contengan mas basura que contenido, para ejemplo un boton.

El código comentado es así, son vagas ideas de un monstruo llamado código, que espera ser completado. Haciendo a un lado la poesía técnica, el código comentado es la punta del iceberg, si hay código comentado, significa que hay un problema de fondo mas grave.

Para algunos quitar el código comentado es mera estética, para otros(principalmente para quien no hizo el código) es una tarea necesaria antes de cada entrega (release), ya que es difícil trabajar con código basura.

Por lo general el desarrollador deja sus migajas en los programas por varias causas:
• Pereza
• Falta de profesionalismo
• Carencia de procesos de calidad
• Tiempos de entrega apretados
• Desconocimiento
• Y en algunos casos soberbia (El clásico “Yo si entiendo mi código”)

Como programador es tu responsabilidad generar buen código, recuerda que tal vez mañana (Sonó a canción) tus líneas, las va a leer Apu en Bangalore y al verlo dira: यह क्या है?

Me gusta el código comentado /* Y que */

//SIG=11dsqp54d\/*-//http:\/\/video.search.yahoo.com\/search\/video"},"shopping":{"button":"Shopping //Search","action":"http:

Esta entrada trata sobre una mala practica de programación que afortunadamente esta quedando en desuso, al menos por los buenos programadores.

/* Esto no es codigo, es solo un recordatorio de que hice algo mal y deje evidencia

Tambien es la evidencia de mi trabajo, es como la papelera de un genio que siempre

esta llena antes de que llegue a la conclusión de una gran idea. Solo que yo, acompaño la idea con la papelera.

Ademas debo dejar mis cambios anteriores y como no conozco herramienta para versionar el codigo, prefiero dejarlo comentado, por si se ofrece después

Incluso puedo poner la lista del mandado, mis conversaciones del Messenger, letras de canciones */

//Un limon, medio limon, 2 limon, medio limon,….

//

// Puedo dejar lineas en blanco comentadas, todas las que quiera

//

//

//Al cabo no importa, el compilador no las lee, las ignora cuando hace su trabajo

Me refiero al famoso código comentado, que no es lo mismo que documentar código, en términos prácticos el código comentado es basura, son líneas /*Incluso puede estar en cualquier lugar */que a nadie benefician y que si perjudican mucho al momento de dar mantenimiento a un sistema.

/* static void CopyObject(SampleClass original)

{

if (original == null)

{

throw new System.ArgumentException("Parameter cannot be null", "original");

}

}*/

Imaginemos que un escritor esta escribiendo (valida la rebuznancia) un nuevo libro, para llegar a la versión final tiene que pasar por numerables etapas, muchos ensayos, muchos borradores; tiene que pasar por la revisión de mucha gente antes de ser publicado. En este proceso creativo el escritor va a transformar su idea, escribir y reescribir una y otra vez líneas y líneas que /* Se pueden camoflajear como lineas validas */ se irán quedando en papeles hechos bola en la papelera.

/*{"props":{"crumb":"O2oDA5QWh6WWpHcTlLY3U.","libRoot":"http:\/\/l.yimg.com\////a\/lib\/","proxyUrl":"\/proxy","ultSpaceId":"2023538075","ultBeaconHost":"\/p.gif","re///questUrl":"\/js","comboRoot":"http:\/\/l.yimg.com\/a\/combo?","sdaRequestUrl":"\/sda2//","passthru":"","proxyTimeout":15000,"modChromeHtml":"_{view_name}\">{html} <\/div>\n */

Te gustaría comprar un libro y que traiga 3000 hojas, de las cuales solo la mitad sea contenido?, y que las otras 1500 sean anotaciones, versiones preliminares, apuntes, borradores, calis de ese libro que tanto esperas leer??

/* El concepto de culpa y de castigo, comprendida la doctrina de la gracia, de la redención, del perdón- todas las completas mentiras privadas de toda realidad psicológica- fue inventado para destruir en el hombre el sentido de las causas; fue un atentado contra la noción de la causa y efecto! */

El código comentado es así, son vagas ideas de un monstruo llamado código, que espera ser completado. Haciendo a un lado la poesía técnica, el código comentado es la punta del iceberg, si hay codigo comentado, significa que hay un problema de fondo mas grave.

Para algunos quitar el código comentado es mera estética, para otros (principalmente para quien no hizo el código) es una tarea necesaria antes de cada entrega (release), ya que es difícil trabajar con código basura.

Por lo general el desarrollador deja sus migajas en los programas por varias causas:

• Pereza
• Falta de profesionalismo
• //Porque no afecta la funcionalida!!, de todos modos compila
• Carencia de procesos de calidad
• Tiempos de entrega apretados
• Desconocimiento
• Y en algunos casos soberbia (El clásico “Yo si entiendo mi código”)
• //Porque si

Como programador es tu responsabilidad generar buen código, recuerda que tal vez mañana (Sonó a canción) tus líneas, las va a leer Apu en Bangalore y al verlo dira: यह क्या है?