{"id":20834,"date":"2022-06-01T12:43:20","date_gmt":"2022-06-01T10:43:20","guid":{"rendered":"https:\/\/www.hiberus.com\/crecemos-contigo\/?p=20834"},"modified":"2023-11-28T09:24:08","modified_gmt":"2023-11-28T08:24:08","slug":"todo-lo-que-necesitas-saber-de-tdd-en-3-minutos","status":"publish","type":"post","link":"https:\/\/www.hiberus.com\/crecemos-contigo\/todo-lo-que-necesitas-saber-de-tdd-en-3-minutos\/","title":{"rendered":"TDD: Todo lo que necesitas saber de esta metodolog\u00eda en 3 minutos"},"content":{"rendered":"

Cada cosa tiene su momento. Es por esto que en el mundo del desarrollo software existen diferentes metodolog\u00edas de trabajo para definir la estrategia y el m\u00e9todo a seguir para llevar a cabo un proyecto.<\/span><\/p>\n

Existen diversas metodolog\u00edas de desarrollo, cada una<\/span> de ellas <\/span>define una serie de pr\u00e1cticas con las cueles fortalecer ciertos aspectos en el proyecto. Existen pr\u00e1cticas que se pueden aplicar de forma combinada, al igual que hay algunas que simplemente no se puedan aplicar dada la naturaleza de un proyecto.<\/span><\/p>\n

Para saber cu\u00e1l (o cu\u00e1les) aplicar en un proyecto, es necesario conocer al menos las m\u00e1s habituales, en este art\u00edculo vas a leer sobre una de ellas, el Test Driven Development<\/strong> (TDD).<\/span><\/p>\n

\u00bfQu\u00e9 es el TDD o Test Driven Development?<\/span><\/b>\u00a0<\/span><\/h2>\n

El Test Driven Development (TDD) o \u201cDesarrollo guiado por pruebas\u201d se basa en traducir los requisitos del software en casos de testing<\/a>, para poder <\/span>primero <\/span><\/b>escribir sus test, <\/span>luego <\/span><\/b>realizar la implementaci\u00f3n necesaria para que estos test pasen, y <\/span>finalmente <\/span><\/b>refactorizar el c\u00f3digo escrito.<\/span><\/p>\n

De esta forma, se crea un ciclo llamado red, green, refactor.<\/span><\/p>\n

\u00a0<\/span>\"\"<\/span><\/p>\n

En la fase red<\/strong> (roja), se escriben los test que cubren los casos de prueba (provenientes de un requisito). Estos test por norma general van fallar, ya que no existe todav\u00eda la implementaci\u00f3n necesaria. Cuando un test falla, este se ve de color rojo, de all\u00ed esta fase.<\/span><\/p>\n

En la fase green<\/strong> (verde), se escribe c\u00f3digo con el <\/span>\u00fanico <\/span><\/b>objetivo de pasar los test (pasar del color rojo del test fallido, al verde del test aprobado). Durante esta fase no se van a tener en cuenta las buenas pr\u00e1cticas a la hora de desarrollar c\u00f3digo, lo importante (por ahora) en es pasar los test.<\/span><\/p>\n

En la fase de refactor<\/strong>, se va a revisar el c\u00f3digo escrito para que cumpla con las buenas pr\u00e1cticas del c\u00f3digo. Se podr\u00eda decir que es pasar a limpio el c\u00f3digo realizado en la fase anterior. En esta fase se juega con la ventaja de que con cualquier modificaci\u00f3n que se realice al c\u00f3digo, se puede comprobar si se siguen pasando los test o no.<\/span><\/p>\n

Evita malas pr\u00e1cticas<\/span><\/b>\u00a0<\/span><\/h2>\n

Aplicar TDD implica un cambio de filosof\u00eda. De forma habitual los test se escriben una vez realizada la implementaci\u00f3n con el objetivo de <\/span>encontrar <\/span><\/b>bugs. Sin embargo, con TDD los test se escriben antes, por lo que los test se escriben para <\/span>prevenir <\/span><\/b>bugs.<\/span><\/p>\n

C<\/span>uando se escriben primero los test, posteriormente en la etapa de la implementaci\u00f3n, el desarrollador tiene una mejor visi\u00f3n del problema, ya que tiene en mente los escenarios en los que se va a probar su c\u00f3digo.<\/span><\/p>\n

Si bien el TDD es un proceso que debe ser llevado a cabo por un desarrollador, la presencia de un analista QA<\/a> es fundamental<\/strong>, con la idea de que se valide todo lo realizado hasta el momento. El TDD forma parte de los procesos de trabajo de Quality Assurance<\/a> mediante sus testeos y diferentes pruebas.<\/p>\n

Antes de aplicar TDD<\/span><\/b>\u00a0<\/span><\/h2>\n

Para poder aplicar TDD, se deben describir correctamente las historias de usuario. Los requisitos deben quedar claros, y a partir de estos formar los casos de prueba que espera el cliente. Si no se realiza correctamente la traducci\u00f3n de requisito<\/strong> a caso de prueba<\/strong>, aplicar TDD va a ser un desastre.<\/span><\/p>\n

Un punto importante y extensible a cualquier proyecto y metodolog\u00eda, es que los requisitos los debe definir el cliente. Es el cliente quien decide el comportamiento de su producto. Si corremos el riesgo de asumir requisitos, es muy probable que estos no est\u00e9n en sinton\u00eda con los del cliente.<\/span><\/p>\n

\u00bfPor qu\u00e9 TDD?<\/span><\/b>\u00a0<\/span><\/h2>\n
    \n
  1. Todo queda probado<\/strong>. Haciendo los test primero, se evita que se dejen para el final, se olviden casos de prueba, o se recorten por falta de tiempo.<\/span><\/li>\n
  2. Cliente satisfecho<\/strong>. Los test a cumplir se basan en los casos de uso, extra\u00eddos de los requisitos acordados con el cliente.<\/span><\/li>\n
  3. Mejor c\u00f3digo<\/strong>. Tener definida una etapa de refactorizaci\u00f3n obliga a que el c\u00f3digo escrito sea revisado y mejorado siempre.<\/span><\/li>\n
  4. Evita desarrollo innecesario<\/strong>. El c\u00f3digo que se escribe se hace con el objetivo de pasar un test, y este test ha sido escrito para comprobar un caso de uso, basado en un requisito del cliente. Por lo que siempre es necesario.<\/li>\n<\/ol>\n

     <\/p>\n

    En Hiberus Tecnolog\u00eda contamos con un amplio equipo de expertos en QA Services & Testing.<\/strong> Sus m\u00e1s de ocho a\u00f1os de experiencia en el sector, junto a su certificaci\u00f3n ISTQB<\/a> hacen de este equipo una apuesta segura dentro de nuestras tecnolog\u00edas diferenciales<\/a>. Conf\u00eda en nosotros. \u00a1Te ayudaremos en todo lo que necesites!<\/p>\n

    \n
    \n
    \n
    \n

    \u00bfQuieres m\u00e1s informaci\u00f3n sobre nuestros servicios de QA?<\/p>\n

    Contacta con nuestro equipo de expertos en QA y Testing<\/p>\n <\/div>\n

    \n \n
    \n

    <\/p>

      <\/ul><\/div>\n
      \n
      \n<\/fieldset>\n
      \n\t
      \n\t\t
      \n\t\t\t

      <\/span>\n\t\t\t<\/p>\n\t\t<\/div>\n\t\t

      \n\t\t\t

      <\/span>\n\t\t\t<\/p>\n\t\t<\/div>\n\t<\/div>\n\t

      \n\t\t
      \n\t\t\t

      <\/span>\n\t\t\t<\/p>\n\t\t<\/div>\n\t\t

      \n\t\t\t

      <\/span>\n\t\t\t<\/p>\n\t\t<\/div>\n\t<\/div>\n\t

      \n\t\t
      \n\t\t\t

      <\/span>\n\t\t\t<\/p>\n\t\t<\/div>\n\t<\/div>\n\t

      \n\t\t
      \n\t\t\t