{"id":143,"date":"2018-01-02T12:37:10","date_gmt":"2018-01-02T12:37:10","guid":{"rendered":"http:\/\/52.201.184.187\/?p=143"},"modified":"2018-01-04T03:38:25","modified_gmt":"2018-01-04T03:38:25","slug":"que-es-tdd","status":"publish","type":"post","link":"http:\/\/52.201.184.187\/blog\/tdd\/que-es-tdd\/","title":{"rendered":"\u00bfQu\u00e9 es TDD y por qu\u00e9 empezar a usarlo?"},"content":{"rendered":"

\u00bfQu\u00e9 es TDD?<\/h2>\n

TDD viene de la sigla de Test Driven Development, o en Espa\u00f1ol, Desarrollo Guiado por Tests. Se basa en estos pasos:<\/p>\n

    \n
  1. Escribir<\/strong> y<\/strong> Ejecutar<\/strong> el test para que falle, verificando que falle por el motivo que yo espero (ROJO<\/strong>)<\/li>\n
  2. Escribir solamente el c\u00f3digo\u00a0estrictamente necesario<\/strong> para hacer pasar el test. (VERDE<\/strong>)<\/li>\n
  3. Hacer refactor del c\u00f3digo. (REFACTOR<\/strong>)<\/li>\n<\/ol>\n

    \u00a0\"\"<\/h2>\n

    <\/h2>\n

    <\/h2>\n

    <\/h2>\n

    <\/h2>\n

    \u00bfPor qu\u00e9 hacerlo fallar primero?<\/h2>\n

    Probablemente se pregunten por qu\u00e9 escribir el test primero y hacerlo fallar. Vamos por el contraejemplo. Imaginen qu\u00e9 pasar\u00eda si escribieramos el c\u00f3digo productivo, y luego escribieramos y ejecutaramos el test. Supongamos que el test queda en verde. \u00bfEl test qued\u00f3 en verde porque el c\u00f3digo productivo est\u00e1 bien, o porque el test en realidad no prueba lo que tiene que probar? En cambio, si hacemos TDD, primero escribiendo el test y vi\u00e9ndolo fallar por el motivo que nosotros esperamos que falle, demostramos su capacidad de fallar ante c\u00f3digo que no hace lo que tiene que hacer, y entonces demuestra su capacidad de probar nuestro c\u00f3digo productivo.<\/p>\n

    El c\u00f3digo estrictamente necesario<\/h2>\n

    Como desarrolladores solemos tener el vicio de escribir c\u00f3digo innecesario, o de enroscarnos y empezar a escribir condici\u00f3n tras condici\u00f3n, y una validaci\u00f3n atr\u00e1s de otra, teniendo montones de l\u00edneas de c\u00f3digo e \u00abifs\u00bb, muchas veces innecesarias. Por eso es que tenemos que escribir el c\u00f3digo estrictamente necesario y m\u00ednimo como para hacer pasar el test. Cada l\u00ednea de c\u00f3digo, cada condici\u00f3n, cada iteraci\u00f3n debe estar respaldado por un caso de test que haya fallado, y que entonces justifique escribir una l\u00ednea de c\u00f3digo productivo.<\/p>\n

    Refactor<\/h2>\n

    Una vez que tenemos nuestro c\u00f3digo andando, vemos c\u00f3mo mejorar su calidad. La ventaja de tener TDD es que nos da la confianza necesaria para poder cambiarlo sin miedo a romperlo. Importante, respetemos el concepto de refactor: mejorar el c\u00f3digo sin modificar funcionalidad. Si necesitamos agregar o cambiar funcionalidad, tenemos que escribir un nuevo caso de test y seguir el ciclo rojo-verde-refactor.<\/p>\n

    \u00bfPor qu\u00e9 deber\u00eda empezar a usar TDD?<\/h2>\n