Ir al contenido principal

TDD - Desarrollo Guiado Por Pruebas

En la reunión 30 de la comunidad TjNet estaré presentando el tema TDD (Test Driven Development), el cual es una práctica de programación que consiste en escribir primero las pruebas unitarias, después el código que cumple con las pruebas y refactorizar el código escrito.

La idea principal es que el comportamiento esperado del objeto que estamos probando lo definamos en pruebas y después nos preocupemos por que el objeto cumpla con lo que se definió en las pruebas.

Cabe aclarar que el TDD es una actividad del equipo de desarrollo y no del equipo de QA que realiza las pruebas al software. La intención de las pruebas unitarias no es que el equipo de calidad las use para realizar su trabajo. Las pruebas unitarias son para definir el comportamiento del código que vamos escribir, es decir es parte del diseño. Aunque sí aumentan en cierta forma la calidad del código escrito.

Efectos del desarrollo guiado por pruebas

Algunos de los efectos notables sobre el desarrollo guiado por pruebas es que se evita escribir código que no se utilizará. Ya que se trata de realizar solamente el código necesario para poder satisfacer las pruebas definidas.

Otro efecto que se obtiene al trabajar de esta manera es que como nuestras clases ya no solo van a ser utilizadas por la aplicación, sino también por el código de prueba, esto nos obliga a tener clases débilmente acopladas y que hacen uso de dependencias solo a través de interfaces, independientemente de la implementación. De tal forma que sea fácil utilizar ciertas clases concretas para la aplicación y otras para las pruebas. Para esto es común aplicar el principio de inyección de dependencias.

El mantenimiento del código es más manejable, la confianza en el código mejora, por que las pruebas nos sirven como alerta cuando introducimos código que hace que nuestras pruebas fallen. En lugar de introducir cambios al código sin saber cómo afectan a otras clases del sistema.

El uso del depurador disminuye ya que cuando existe un error en el código es más fácil encontrarlo en las pruebas que corriendo la aplicación en modo debug.

Ciclo de desarrollo

1. Escribir el comportamiento deseado (requerimiento) a manera de prueba unitaria, Este paso fuerza al programador a tomar la perspectiva de un cliente considerando el código a través de sus interfaces. Obviamente la prueba fallará ya que aun no está escrito el código para satisfacerla.

2. Escribir solo el código necesario para que la prueba pase.

3. Correr las pruebas para confirmar que efectivamente el código escrito cumple con los establecido por las pruebas.

4. Refactorizar el código, para eliminar código duplicado y dejarlo de tal forma que sea fácil hacerle modificaciones en el futuro.

5. Verifica que las pruebas no fallen después de la refactorización.

Conclusión

El desarrollo guiado por pruebas no es parte del proceso de calidad de un sistema en desarrollo (aunque si aumenta la calidad del código escrito) sino que forma parte del diseño de cada clase; define el comportamiento esperado de la clase desde el punto de vista del cliente que la usará.

Los espero en la reunión 30 de la comunidad TjNet.

Comentarios

Entradas más populares de este blog

Bloqueos

Una de las preguntas típicas de las juntas matutinas en los equipos de desarrollo de software es ¿Hay algún bloqueo? Si lo hay, se trata de ver qué es lo que está esperando esa persona y encontrar la forma de que se desbloquee; pero ¿Qué son los bloqueos? Los bloqueos son obstáculos que te impiden realizar o avanzar en tu trabajo. Evitan que puedas seguir progresando en el proyecto.

He notado que es común en las personas con menos experiencia decir que tienen un bloqueo cuando están batallando, debido a su poca experiencia, en la forma de resolver un problema. Han intentado varias formas y se empiezan a quedar sin ideas de como puede ser resuelto el problema o como pueden cumplir con el requerimiento especificado. Al quedarse sin opciones de qué intentar dicen que tienen un bloqueo con la tarea y que a menos que alguien les diga como resolverlo, no se puede avanzar en la tarea.

En personas con más experiencia, ese tipo de bloqueos no ocurren, una persona con experiencia ha visto pro…

Firebird 2.1 UPDATE OR INSERT

Another great feature that I like in Firebird 2.1 is the UPDATE OR INSERT statement. It's a really time saver and it makes the SQL cleaner.

For example suppose I have a products table like the one I use in my last post and an inventory table to store the product stock. Before Firebird 2.1 if I want to set the stock for a product I needed to check if a record for that product_id already exists; if the product_id already exists then I write an update. If not then I write an insert statement. So I ended up with something like this:


IF EXISTS(SELECT * FROM inventory WHERE product_id = :product_id ) THEN
UPDATE
inventory
SET
stock = :stock
WHERE
product_id = :product_id;
ELSE
INSERT INTO inventory
(product_id, stock)
VALUES
(:product_id, :stock);

In this example I only update one field but when I have to update a big table I ended up with a big chunk of code and thinking: "there should be another (better) way to do this".

Fortunately now with Firebird 2.1 there…

Database Mail en MS SQL Server 2005

Configuración de Database Mail en MS SQL Server 2005

Primero se debe de habilitar, ya que por omisión el componente esta deshabilitado, Utilizando el SSMS (SQL Server Management Studio)


Si no esta habilitado aparecerá un mensaje preguntado si lo habilita, después aparece esta ventana donde se pregunta al usuario que es lo desea hacer.


Seleccionamos la primera opción para crear un perfil.


Configuramos el perfil y le agregamos por lo menos una cuenta.


Seleccionamos el perfil como public y default.


Para mandar correo se utiliza el procedimiento msdb.sp_send_dbmail por lo tanto el usuario que intente mandar correo debe de tener permiso para la base de datos msdb.

Referencias:
http://www.sqlservercentral.com/columnists/cBunch/introtodatabasemailinsql2005.asp