En metodologías ágiles, las pruebas unitarias son clases que implementan métodos que prueban el correcto funcionamiento de unidades o fragmentos requeridos para el correcto funcionamiento de la aplicación. Aunque hasta hace poco las pruebas unitarias servían al Desarrollo Guiado por Pruebas (TDD – Test Driven Development) actualmente este modelo de desarrollo está desapareciendo.

Las pruebas unitarias deben cumplir las siguientes premisas:

  • Automatizables: no deben requerir de intervención manual.
  • Repetibles: deben poder ejecutarse más de una vez.
  • Aisladas e independientes: no deben afectar a la ejecución de otras pruebas, y serán invisibles tanto para el resto de código como para el resto de desarrolladores.
  • Auto validables: deben conllevar una resolución –afirmativa o negativa- por sí mismas.
  • Rápidas: no deben tardar mucho en ejecutarse ni en programarse.

¿Por qué son importantes? Nos ayudan a hacer que futuros cambios en el código sean fácilmente testeables, y nos facilitarán la localización y acotación de errores, presentes y futuros. Además, sirven como documentación del código, ya que quedarán registrados diversos escenarios de uso del mismo.

Y eso no es todo, ¡no! Es muy probable que, si la prueba unitaria se realiza correctamente –y se explota la funcionalidad desde todos los escenarios posibles (tanto positivos como negativos)- es muy probable que nos ayude a realizar mejoras sustanciales en nuestro código para que este sea más ágil, controle más posibles excepciones y sea mucho más integrable. Esto se llama refactorización de código.

Así que, lo que en principio podría parecer una “pérdida de tiempo” puede ahorrarnos trabajo a largo plazo.

No todo es testeable. Ni podremos testear interfaces, ni maquetación, ni vistas. ¿Por qué? Sencillo. En la mayoría de estos casos, es necesaria la intervención del usuario. Así que no se pueden automatizar ni repetir, ni podrán validarse a sí mismas.

¿Y qué hay de JavaScript? La respuesta la da nuestro compañero Juan José García: Selenium.

Ahora bien (y aquí abriremos debate), las buenas praxis nos indican que deben ser repetibles, automatizadas e independientes. Entonces… ¿qué hay de testear una API rest? ¿O una BBDD? La opinión está dividida, pero son muchos los que contraindican realizar unit tests contra servicios de terceros.

Pero hay diversas formas de realizar dichas pruebas. Victor Puertas, por ejemplo, escribe en YO! Symfony sólo dos métodos para realizarlas. ¿Alguien sabe si son los métodos más extendidos actualmente?

A mí, personalmente, me gusta simular el acceso a datos mediante mocks (objetos virtuales que simulan a los objetos de la base de datos). Y por esto mismo, hablaré de los Tests Dobles y de alguno de los frameworks de creación de mocks en una próxima entrada.

¿Vosotros qué opináis? ¿Qué solución usaríais para realizar las pruebas de vuestras APIs?

Espero vuestras respuestas. ¡Un saludo!

 

Álvaro Dama Jiménez (LinkedIn | Twitter | GitHub)

Alumno del curso Microsoft MCSD 2015-2016

Centro de formación Tajamar.

Leave a Comment

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.