Ir al contenido principal

Permiso para hacer TDD

Al estar en platicas/presentaciones sobre TDD (Test Driven Development) donde los participantes son gente que ya esta trabajando. La mayoría de los participantes coincide en que es una buena practica realizar el desarrollo guiado por pruebas. Sin embargo una pregunta que surge frecuentemente es ¿Como convenzo a mi jefe de hacer TDD?

Bueno para empezar no creo que un equipo de desarrollo deba pedir permiso para escribir mejor código, debería ser su obligación. Todos deberíamos de tratar de realizar cada vez un mejor trabajo. Mientras se entreguen resultados con calidad no debería de haber problema con los jefes.

Es claro que el realizar pruebas unitarias aumenta la cantidad de código escrito. Pero solo es eso, mas código y de mejor calidad. Si bien es cierto que eso implica mas tiempo (al principio), también es cierto que el tiempo invertido en el código de una prueba es menor al tiempo que se invierte en mantener el código después o en encontrar un bug que una prueba (y un mejor diseño) nos hubiera evitado. Al final estamos escribiendo mejor código que prácticamente ya esta probado. Y al realizar TDD frecuentemente el tiempo para realizar prueba e implementación mejora.

Entonces al realizar TDD pasa lo siguiente:

  1. Mejora el diseño
  2. Mejora el código, es mas fácil modificarlo después
  3. Aumenta el numero de clases (código)

Ahora yo te pregunto ¿Necesitas convencer a tu jefe de que te deje escribir una clase?

Creo que la respuesta es no; así que solo hazlo. Escribe tus pruebas unitarias sin hacer una junta con tu jefe. Hazlo como parte del desarrollo normal del proyecto. Pero, si la respuesta es sí, es decir que necesitas convencer a tu jefe que te deje escribir una clase o un archivo con código entonces quizás tengas un problema mas grande.

Si tu estas convencido que es lo mejor, no esperes a convencer a otros para sentir que tienes la razón. Solo haz lo mejor.

Comentarios

  1. Hola,

    Yo no soy fan de TDD en su totalidad, o sea no estoy de acuerdo con la receta completa, pero como lider de proyecto debo asegurarme que mi producto venga con los menores errores posibles, por lo que es mi tarea (y no la del programador) justificar el tiempo invertido en test a la directiva, la responsabilidad del programador no es solo entregar codigo que satisfaga las necesidades pero tambien que cubra escenarios no previstos.

    La forma en la que aplico TDD en mi equipo es hacer que los tests sean escritos por programadores ajenos al source code. Ademas de no dejar que los UnitTest sean los garantizadores de la funcionalidad total del producto, pero eso es harina de otro costal.

    Saludos

    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