Apple Podcast (iTunes) | iVoox | Spotify | Suscríbete al podcast

Último episodio de la #TecnoTrilogía centrado en la madre de todas las buenas prácticas: el desarrollo guiado por pruebas o Test-Driven Development (TDD).

Pero antes repasamos la segunda entrega del #desafíoPython, donde ya tenemos nuestro repositorio en Github en marcha.

También hablamos de la encuesta de OpenSource.com sobre qué lenguaje de programación quieres aprender.

¿Qué se esconde detrás del testing?

Detrás de todo software hay una gran realidad: antes o después habrá algún bug, algún fallo.

¿Por qué no prevenir mejor que curar?

Para eso hablamos de testing. Es una gestión de una expectativa, de encontrarnos un error, para lanzarnos después a su elemento positivo: tenerlo controlado y saber que funciona correctamente.

Pasar los test de “rojo” a “verde” se convertirá en uno de nuestros motivos de vida, en una forma de trabajar completamente distinta. Es cierto que es laborioso, como te cuento en el episodio, pero es una gran recompensa saber que cuando vas a añadir nueva funcionalidad, todo esta probado para que funcione.

Puedes usarlo en cualquier lenguaje de programación, porque encontrarás una librería que se ajuste a las necesidades de estas pruebas: PHPUnit, JUnit, Pytest, Jasmine…

Los tests según el nivel

Hay muchas formas de clasificar los tests y, sobre todo, de llamar a cada parte. A mi me gusta la que lo reduce a tres, teniendo en cuenta que el minimalismo es una cuestión importante en nuestras vidas.

Tests unitarios.

Prueban una función concreta de nuestro código. Son en los que se centran el episodio y, probablemente, los más difíciles de hacer cuando no tenemos práctica.

Integración o Funcionales

Escalamos hacia arriba y estos son los tests que implican tener por ejemplo una conexión a la base de datos o a otros elementos de tal forma que no solo el código a testear es el protagonista.

Aceptación o End to End

Son los que arrancan el entorno completo. Si estamos en web, abren un navegador y hacen las pruebas necesarias como si fuera un usuario probando el sistema.

Cada nivel está haciendo pruebas también de los anteriores. Si algo falla en lo unitario fallará también en integración y aceptación si probamos sobre la misma funcionalidad.

Además, estamos acostumbrados a utilizar el mecanismo de pruebas de esta pirámide invertida que ves más abajo. Y lo ideal sería más pruebas automatizadas y menos manuales.

Piramide invertida del testing

Ciclo de pruebas

Aquí la metodología de testing, un proceso repetitivo, sin duda, pero donde radica su fortaleza:

  1. Conocer claramente la especificación
  2. Crear el test
  3. Hacer que falle
  4. Implementar el método mas sencillo que lo cumpla
  5. Refactorizar
  6. Vuelta a empezar

¿Cómo probamos las dependencias?

Los test unitarios deben ser independientes y poder ejecutarse sin ningún orden concreto. Nuestra aplicación en infinidad de ocasiones depende de conexiones a bases de datos, APIs de datos, otras clases y modelos de nuestro proyecto…

Para eso se pueden utilizar los “tests dobles”, como si fueran los dobles de cine. Estos son algunos de ellos:

  • Mocks: a veces solo queremos saber si en una clase un método está siendo llamado, sin necesidad de saber su resultado.
  • Stubs: ajustamos el resultado de un método a lo que nos es necesario. Forzamos esa respuesta para poder probar nuestro código.
  • Dummy: la clase que sustituimos no tiene efectos colaterales, simplemente está ahí y la colocamos “de mentira”.

Recursos recomendados

Puedes seguir a Web Reactiva en el canal de telegram t.me/webreactiva o en la cuenta de twitter @webreactiva con referencias, recursos y enlaces de interés.

Escrito por Dani

Soy programador web freelance. Especialista en frameworks basados en PHP como Drupal, aunque también me gusta trabajar con microframeworks en varios lenguajes y, por supuesto, tengo a Javascript de gran aliado. aquí.
comments powered by Disqus