Test-Driven Development in Microsoft .NET
August 23, 2006 — emorito¿Como leer el
libro?
Para leer el libro hice
lo siguiente:
- Empecé a leer el Capitulo 1 “Test-Driven Development
Practices” en donde están las pautas generales de esta practica, que
clases de test hay y te explica que pasos seguir.- Seguí por el Appendix A “NUnit Primer” en donde explican
que son los test de NUnit y como realizarlos con dicho
FrameWork.- Capitulo 2
“Test-Driven Development in Microsoft .NET – By Example”
en donde fui siguiendo el ejemplo del Stack. Con esto me termino de cerrar como
utilizar NUnit y empecé a comprender TDD.- Capitulo 3
“Refactoring – By Example” en donde fui siguiendo
el ejemplo para comprender como iba refactoreando el código y en base a
que.
En la Segunda Parte “Test-Driven Development
Example” hice lo siguiente:
- Baje el FrameWork
NUnit.- Fui desarrollando el proyecto
Media Library con Visual Studio
2003- Tome al libro como el cliente y seguía la lista de
Test.- Así fui desarrollando el
proyecto.
¿Que es TDD?
- ¿Para que sirven
los Test?
Los test nos sirven para ir desarrollando el código,
en base a ellos podemos ir escribiéndolo para
cubrir cierta funcionalidad.Nos
dan las pautas para ir desarrollando las clases y
los métodos que necesitamos para que el código cumpla con lo que tiene que
hacer.
- ¿Qué tienen que
hacer los Test?
En primer lugar, tienen
que fallar (que el test no pase, Red), ya que es lo
primero que hacemos y por ende no hay ninguna clase ni método que cubra la
funcionalidad que se esta testeando.Luego de desarrollar los
métodos y las clases para cubrir la funcionalidad (que el test pase, Green), estos
siempre tienen que pasar (Green). Y nos sirve
para que cada vez que hagamos un cambio en el código, nos demos cuenta de si
este rompió algo. Por eso cada vez que hacemos un cambio tenemos que volver a
correr los test, para verificar que todo siga andando
correctamente.
- ¿Cómo tienen que
ser los Test?
Los test tienen que ser
concisos, o sea tienen que testar únicamente una sola funcionalidad y llegar a
cubrirla. Con esto vamos a como dice el libro no more and no less, todos podemos
entender que no tiene que hacer menos. Pero a la hora de no más, se refiere a que el código
solamente tiene que cubrir la funcionalidad que se le pidió. Para no tomar mas responsabilidades de la que deberíamos, creo
yo. El test solamente tiene que testear esa funcionalidad y no anticipar
otra.
- ¿Para que sirve
el Refactoring?
Al ir escribiendo el
código en base a los test, luego de un par de estos, nos podemos ir encontrando
con código duplicado o con variables que
cumplen la misma función en varias partes del
código.Podemos ir encapsulando ese código duplicado que
cumple la misma función, por ejemplo conectar
a la base de datos. Y en cuanto a las variables le podemos ir dando otra
visibilidad dentro de la clase o el método para que no aparezca
repetida varias veces en el código, por ejemplo el string de
conexión.Luego de hacer esto,
tenemos que volver a correr los test para verificar que los cambios que hagamos
no rompan ninguno de los test. Con este último paso completamos lo que en el
libro llama (Red/Green/Refactor).
¿Como Implementar
TDD?
Primero hay que tener en cuenta
que:
- Nunca se debe
escribir ni una sola línea de código sin antes tener el Test que
falle.- Eliminar
Duplicados.
Luego
hay que hacer lo siguiente:
- En base al requerimiento a cubrir,
hacer una lista de
tests.- Darle una prioridad a los test para
saber por cual empezar. Acá, se puede elegir por empezar por el test mas sencillo o por el que cubra en
mayor parte el requerimiento.- Empezar escribiendo el
Test.- Mientras el test vaya fallando
(Red), en base al mismo, ir escribiendo el código para
cubrir la funcionalidad.- Luego de escribir el código,
comprobar que el test pase (Green).- Una vez que terminamos con todos los
test de la lista, puede que tengamos que hacer refactoring (Refactor). Después de esto, volver a
correr todos los test para verificar que
todos pasen (Green).