17 marzo 2006
Aquí empezamos la casa por el tejado
...y estamos orgullosos!!
Cómo no...empezaré por el principio, creo que era mi segundo día cuando JM comenzó a explicarme nuestra metodología, empezando por XP llegamos a las pruebas unitarias..
eh??? ¿qué son las pruebas unitarias? (uff que vergüenza reconocer que no las conocía).
A pesar de que es una práctica altamente recomendable y condición sine qua non con el software de calidad, por las empresas por las que he pasado no conocíamos ni el termino.
Después de explicarme su sentido(a grosso modo "las pruebas unitarias prueban que cada modulo de código funcione correctamente por separado", lo vi todo clarísimo (os recomiendo leerlos el artículo de Jm sobre este tema), a partir de ahora siempre usaría pruebas unitarias, hasta que JM siguió explicando y de nuevo consiguió darle la vuelta a mi "claridad"...
ahora decía que hiciera las pruebas unitarias antes que el código!!!,
Pero éste está loco!!! ¿qué empiece la casa por el tejado?..."sí hombre y ahora me dirá que primero programe y luego diseñe" :).
Quería que probase métodos que no existían, clases que no existían...en fin loco!! jejeje, puede parecer una locura pero tiene mucho sentido, esta técnica se conoce como TDD(Test Driven Development), si haces las pruebas primero te estás anticipando a posibles fallos, las pruebas te harán modelar tu diseño de la clase, del método, tendrás una visión muy clara del comportamiento que esperas que tenga un método, clase, etc..
si queréis más información sobre esto nos perdáis el articulo completo de JM.
Cómo no...empezaré por el principio, creo que era mi segundo día cuando JM comenzó a explicarme nuestra metodología, empezando por XP llegamos a las pruebas unitarias..
eh??? ¿qué son las pruebas unitarias? (uff que vergüenza reconocer que no las conocía).
A pesar de que es una práctica altamente recomendable y condición sine qua non con el software de calidad, por las empresas por las que he pasado no conocíamos ni el termino.
Después de explicarme su sentido(a grosso modo "las pruebas unitarias prueban que cada modulo de código funcione correctamente por separado", lo vi todo clarísimo (os recomiendo leerlos el artículo de Jm sobre este tema), a partir de ahora siempre usaría pruebas unitarias, hasta que JM siguió explicando y de nuevo consiguió darle la vuelta a mi "claridad"...
ahora decía que hiciera las pruebas unitarias antes que el código!!!,
Pero éste está loco!!! ¿qué empiece la casa por el tejado?..."sí hombre y ahora me dirá que primero programe y luego diseñe" :).
Quería que probase métodos que no existían, clases que no existían...en fin loco!! jejeje, puede parecer una locura pero tiene mucho sentido, esta técnica se conoce como TDD(Test Driven Development), si haces las pruebas primero te estás anticipando a posibles fallos, las pruebas te harán modelar tu diseño de la clase, del método, tendrás una visión muy clara del comportamiento que esperas que tenga un método, clase, etc..
si queréis más información sobre esto nos perdáis el articulo completo de JM.
Etiquetas: programación, TDD