logoCoderhouse.png
Ë
By Felix Enriquez • February 1, 2016

Testing: Introducción General

¿Qué es el testing?

Apenas comenzamos a programar y dar nuestros primeros pasos dentro de este hermoso mundo, sea en nuestro primer proyecto, estudiando en la facultad o en el afán de conocimiento, damos con los términos de 'testing', 'unit test', 'tests de integración' o 'tests de caja negra'.

El testing lo podemos definir como la acción de poner a prueba algo y verificar si su resultado o comportamiento es el esperado. En nuestro caso particular es poner a prueba nuestros códigos, aplicaciones y procesos para verificar que resuelvan como el cliente lo espera.

Debemos siempre tener un conjunto de tests para cada uno de los módulos de nuestra aplicación (login, formularios, acciones, pedidos de datos, etc).

Como es de pensar, es necesario que los tests estén alineados con lo descrito en los casos de usos, es decir, que el programa tenga los resultados esperados tal cual se definieron en los documentos que describen todo el programa.

Nosotros desarrollamos los tests dentro del proceso de desarrollo como una etapa más del proyecto. Podríamos, por ejemplo, comenzar escribiendo los tests, para luego desarrollar el programa para que los satisfaga. Otra forma, no tan aceptada, es hacerlos después de desarrollar la funcionalidad que nos pidieron.

Tipos de Testing

Ahora bien, tenemos diferentes formas y enfoques de que testear en un programa:

  • Unit Test: Se realizan para testear cada módulo por separado, probando cada método y comprobar su resultado con el esperado.
  • Pruebas funcionales: Aquí se diseñan los famosos "casos de prueba", en los que se verifican los flujos de trabajo que involucran varios módulos en conjunto.
  • Pruebas de Integración: se testea nuestro programa dentro del ecosistema donde va a convivir. Por ejemplo, si nuestro programa necesitara de un login en Facebook y Twitter o traer imágenes de Instagram, la prueba de estas funcionalidades estarán dentro de esta categoría.
  • Pruebas de caja blanca: Se verifican cada función y camino posible dentro del módulo en cuestión. Aquí tenemos herramientas muy útiles que verifican la cobertura de los tests llamado Test coverage.
  • Pruebas de caja negra: Sólo se verifican la entrada y la salida del módulo que queremos poner a prueba.
  • Pruebas de performance: Verificamos el rendimiento de la aplicación bajo los parámetros que queremos que sea aceptable operar. Por ejemplo, que cuando entramos a una web cargue en menos de 500 milisegundos o realizar un login en menos de 1 segundo.

Dentro del proceso de desarrollo, además de tener las pruebas que creamos los desarrolladores, también se incluyen las llamadas "Pruebas de Aceptación", las cuales realizan el cliente, analistas de sistemas o testers para dar la aceptación de la nueva versión del sistema antes de ponerla en funcionamiento, también llamado producción.

Bugs

Dentro de las pruebas realizadas nacen los famosos BUGS y correcciones funcionales, que nos dirán cómo se producen y cómo debería ser el resultado esperado para poder corregirlos.

Ahora bien, unos consejos de como comenzar a implementar el testing en nuestros proyectos.

Lo ideal es comenzar con la práctica clásica de Unit Tests. Tal como les comenté antes, escribir unos tests que verifiquen que el comportamiento de nuestros módulos son los correctos y esperados, poniendo a prueba su funcionalidad. Lo mejor es comenzar a escribirlos antes de escribir el programa en si, de modo de obligarnos a pensar en cómo pasar el test creando el módulo sólo para ese fin y no perder el horizonte de lo que queremos hacer. Como esta práctica puede ser complicada en nuestro inicio como developers, lo mejor es crear unos tests una vez que tenemos el programa escrito, pero apenas nos estemos más cómodos, pasar la otra modalidad.

Un ejemplo sería tener un pequeño script escrito en javascript, que multiplica por dos cualquier número que le pasamos por parámetro:

Captura de pantalla 2016-01-27 a las 13.43.57 

 Nuestro test seria algo así:

Captura de pantalla 2016-01-27 a las 13.43.47

Luego de prácticas en el Unit Tests, lo ideal es planificarlos y ver cuales son los tests prioritarios para nuestro proyecto, si bien todos son importantes, por lo general no podemos cubrir todos los aspectos a probar en nuestros proyectos por temas de presupuesto y tiempos. Dicho esto último, es importante definir qué tipos de tests queremos hacer y priorizar, así no caemos en el problema de que nuestros tests no tengan un tema definido. Nos puede pasar que pensar que hicimos un Unit Test, pero en realidad habernos mezclado con tests de integración y a su vez validando la performance.

Lo importante es incluirlos de partes y con sentidos claros de que estamos testeando sin mezclar los objetivos de los mismos.

Y ustedes ¿Cómo vienen de Testing? ¿Lo implementan antes o después? ¿Conocen algún otro proceso? ¡Los leo!