Ir al contenido principal

TDD ¿Por qué escribir primero las pruebas?

Hace poco leí el blog post de Eber Irigoyen donde escribe sobre duct tape programming. Lo que me llamo la atención en ese post es que Eber mencionó que al escribir pruebas, estas no las hace antes de escribir el código necesario para que las pruebas pasen e incluso menciona que la idea de escribir la prueba primero la considera algo tonta (no son sus palabras exactas pero es la idea). En lo personal la idea de escribir la prueba antes del código lo considero como una buena practica y no pensaría que es algo tonto.

Muchas de las veces cuando se me solicita realizar un nuevo programa o agregar funcionalidad a uno ya existente primero se realiza una entrevista con el usuario final, analista de negocio o cliente (de ahora en adelante lo llamaré cliente) que solicita la funcionalidad. Para que ahí explique a detalle que es lo que necesita. En ocasiones al cliente se le dificulta expresar que es lo que realmente necesita y eso se debe en gran parte porque el tampoco esta seguro que es lo que realmente necesita.

He notado que esto sucede principalmente cuando el cliente, al empezar a explicar el problema y lo que desea lograr con la nueva funcionalidad, esta pensando en la solución que le ayudará a resolver su problema. Inicia explicando como es que ve su solución en lugar de explicar el problema o lo que quiere lograr con ello. En ocasiones se empieza a discutir la implementación de esa solución y que problemas pudiéramos encontrar, después se discute como es que se podría ayudar a resolver esos problemas. Así la discusión puede continuar centrándose en como resolver los problemas de una posible solución que pudiera o no ser la ideal.

Si el desarrollo se centra en hacer que la posible solución funcione, se corre el riesgo que al terminar el desarrollo, esta no cumpla con las expectativas del cliente, ya que lo que se tomo en cuenta para desarrollarla fue la posible solución en lugar de lograr que el problema inicial del cliente se resolviera. Esto hace que el cliente se de cuenta que la solución no le sirve del todo pero el desarrollador siente que cumplió porque hizo que funcionara lo que le pidieron.

Cuando el cliente se centra primero en explicar el problema y en especificar lo que espera lograr, en lugar de pensar en la posible solución. Es entonces cuando yo como profesional puedo trabajar en un programa que resuelva su problema y logre lo que él espera.

Del mismo modo cuando el desarrollador inicia escribiendo el código que resuelva un problema sin especificar antes que es lo que quiere lograr con ello. Es posible que termine escribiendo código que no va a necesitar. Esto es porque se centra en escribir una solución robusta en lugar de solo resolver el problema.

Por eso que pienso que el escribir lo que esperamos del código, como una prueba unitaria, antes de escribir la implementación nos da la ventaja de centrarnos en lo que realmente es importante: cumplir con al expectativa. Y no tanto en hacer que nuestra posible solución funcione. De igual forma ayuda a no escribir código que posiblemente no se necesite, ya que la prioridad es hacer que la prueba unitaria (especificación) pase.

Considero que es benéfico que al iniciar el desarrollo de nueva funcionalidad primero se especifiquen las expectativas que se tienen sobre ella y después se evalúe en base a esas especificaciones. Las expectativas se escriben usando pruebas unitarias y es por eso que me gusta que las pruebas se escriban primero.

El desarrollo guidado por pruebas o TDD (Test Driven Development) no solo se trata de las pruebas. TDD es una tarea de diseño.

Comentarios

  1. Son temas muy discutidos ya por mucho tiempo, en mi caso, siempre me gusta hacer todas las preguntas antes de iniciar el desarrollo, de hecho creo que es una de las habilidades mas importantes de un desarrollador, el saber hacer las preguntas correctas, tener una idea clara de lo que quieren, y hacerles ver escenarios que talvez no tenian contemplados o darles opciones de otras posibles soluciones, una vez que tengo claro que se requiere, me dispongo a escribir la solucion, finalmente escribo las pruebas unitarias para comprobar que se cumplen los requisistos

    ResponderBorrar
  2. ...y lo de que las pruebas unitarias son tontas, es por la expresion en ingles, creo que en español no diria eso porque el mensaje que se transmite es muy diferente por la diferencia de culturas

    ResponderBorrar
  3. Pues eso es parte de ingenieria de software, debes saber cuales son los problemas y com solucionarlos, por que al final resulta que el cliente, creia que necesitaba algo, cuando en realidad necesitaba otra cosa

    ResponderBorrar
  4. Concuerdo contigo, las pruebas unitarias ayudan a interpretar mejor los requerimientos, por lo tanto las considero elementos de diseño

    ResponderBorrar
  5. @BlackTigerX de acuerdo y se que no consideras las pruebas unitarias tontas.
    Solo que (por lo que mencionas en el post) me pareció una buena oportunidad para reflexionar en porque considero bueno escribir las pruebas primero.

    ResponderBorrar
  6. Muy interesante su comentario Mario, en cierta oportunidad investigué sobre el tema y coincido con uds que el TDD es una técnica de diseño y no solamente de pruebas. Se basa en pruebas , que deben ser creadas antes de desarrollar el código operativo. Mediante el uso de herramientas de automatización de pruebas unitarias sumado a integración continua se puede mejorar mucho la calidad del software creado.

    Cabe destacar que se debe contemplar en el esfuerzo estimado la contrucción de las pruebas unitarias, pues en ciertas ocaciones requieren tanto o más código que el código a probar. la gran ventaja es luego de ese esfuerzo es tener un forma muy simple de hacer pruebas de regresión ante cambios evolutivos o correctivos.
    Le comparto más reflecciones sobre el tema

    http://ssalanitri.blogspot.com/2009/08/introduccion-al-tdd-i.html

    ResponderBorrar

Publicar un comentario

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