Pruebas unitarias: Definición y sus dos características

Las pruebas unitarias son la clave para tener un software fácil de probar. Presento aquí una definición y dos características importantes.

¿Por qué queremos usarlas?

Cuando hacemos un cambio en una parte de un Sistema, tenemos que asegurarnos de que no estemos afectando negativamente otra parte, produciendo defectos. Tradicionalmente, lo que se hace es asignar un grupo de personas que ejercitan el Sistema manualmente a través de la interfaz gráfica, buscando algún defecto.

Esto tiene sus inconvenientes. El testing manual requiere más personas, más tiempo (por lo que es costoso) y además no es repetible, porque para volver a probar el sistema hay que hacerlo otra vez de manera manual con el mismo costo y riesgo. El tiempo ya fue invertido y no se recupera.

Hay otra manera de trabajar y es con el testing automatizado. Lo que queremos es que la mayor parte de nuestro software pueda verificarse automáticamente. Para lograrlo, creamos otra pieza de software que nos dice si la funcionalidad opera correctamente. Cuando hagamos un cambio, entonces podemos ejecutar esa pieza de software y en pocos segundos saber si todo sigue funcionando correctamente.

Hay distintos tipos de pruebas automatizadas, donde las más rápidas y confiables son las pruebas unitarias. Este es un ejemplo:

unit-test.PNG

Definición de una prueba unitaria

Una prueba unitaria es un método que puede invocar al código que queremos probar y determina si el resultado obtenido es el esperado. Si es igual, entonces la prueba es exitosa, si no, falla.

Si estos métodos los podemos ejecutar con un solo clic, entonces podemos ejecutar miles de ellos en muy poco tiempo.

Dos características

Las pruebas unitarias tienen las siguientes características:

  1. Funcionan en memoria, por lo que son muy rápidas. Cada una tarda pocos milisegundos en ejecutarse. No acceden a recursos externos como archivos, bases de datos o webservices. No requieren configuraciones manuales, por lo que funcionan con un solo clic.
  2. Son repetibles. Para que podamos confiar en ellas, las pruebas deben  ejecutarse siempre de la misma manera. Queremos poder ejecutarlas durante el día con cada cambio que realicemos, o en el futuro cuando un programador (diferente a quien creó el Sistema) haga otro cambio. Para lograrlo, una prueba unitaria nunca debe depender de algo que cambie en el tiempo, como por ejemplo, la fecha actual, ni de alguna función aleatoria. En el ejemplo anterior, el resultado esperado es un número ya dado, así que la prueba siempre ejecutará de la misma manera.

Otra manera de explicarlo es decir que una prueba unitaria es auto contenida y determinística . Es auto contenida puedes no tiene dependencias hacia recursos externos. Es determinística pues no tiene ningún elemento aleatorio.

En la siguiente parte, veremos cómo diseñar un algoritmo fácil de probar.

7 comentarios sobre “Pruebas unitarias: Definición y sus dos características

  1. Hola profesor,2

    Me parece muy acertada la explicación aunque no me queda claro que tan eficiente es “quemar” los valores esperados. Que pasa si la regla del negocio cambia? y por ejemplo el valor esperado cambia de ser CR123456 a ser USA123456? deberia ir a las pruebas unitarias a cambiarlo para que no falle?

    Saludos

    Me gusta

    1. Muy buena pregunta. Cuando el requerimiento cambie en el futuro iremos primero a cambiar el valor esperado en la prueba unitaria, al ejecutarla fallará. Luego, vamos al algoritmo de la regla de negocio y la ajustamos para que satisfaga el nuevo requerimiento. Habremos terminado cuando todas las pruebas unitarias sean exitosas de nuevo. Así, las pruebas unitarias guían nuestro desarrollo y nos dan seguridad.

      Me gusta

  2. Hola Oscar. ¿Es obligatorio que las pruebas no accedan a recursos como la base de datos? De ser así, ¿qué pasa si queremos crear una prueba unitaria para los métodos de que atacan bases de datos?

    Me gusta

    1. Hola Aarock, gracias por tu consulta. Podemos crear un test automatizado para verificar un metodo que accede a la base de datos, pero al salir hacia la base de datos esta sería una prueba de integración. Este tipo de pruebas requiere una configuración de comunicación y configuración de la base de datos, y además, no será tan rápida como una prueba unitaria. Es por esto, te recomiendo que este tipo de pruebas las coloques aparte de las pruebas unitarias. Usualmente, creamos un projecto .NET de pruebas unitarias y otro de integración. Ya que las pruebas unitarias ejecutan en milisegundos y no requieren ninguna configuración externa, son estas las que ejecutamos en un build de integración continua para saber el estado funcional de la aplicación. Las de integración son una herramienta que usamos como programadores pero que usualmente no son para ejecutar constantemente.

      Me gusta

      1. Genial Oscar. Gracias por contestar tan pronto. Te felicito por tus publicaciones y te agradezco por compartir uts conocimientos. Entre ayer y hoy vi las listas de reproducción de Introducción a los test y la ejemplos de fragilidad. Estoy aprendiendo mucho con tu página.

        Me gusta

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s