En todos los proyectos que se desarrollan dentro del ámbito empresarial (e incluso desde la educación universitaria) se deberían tener presentes las pruebas unitarias.
Entre colegas las entendemos de una forma u otra -no hemos logrado ponernos de acuerdo con una definición genérica- y esto reduce o extiende el alcance de qué es frente a nuestros clientes y, por ende, también impacta las estimaciones y planeación para la ejecución de nuestros proyectos.
Pero en sí, ¿qué es una prueba unitaria? Es probar de manera automatizada un método construido para verificar el correcto resultado de la operación que realiza. Por ejemplo, para un método con la operación suma, verifico que esté ejecutando una suma de dos más dos (2 + 2) y el resultado sea cuatro (4). O, por ejemplo, con la lógica implementada en un desarrollo, el retorno de un método booleano sea verdadero con una casuística especifica o que genere una excepción como resultado de alguna validación. Por lo tanto, es importante tener en cuenta que la unidad de código que se está probando no tenga dependencia de otra unidad de código, ya que si, por ejemplo, tenemos una petición a una base de datos o petición a un Web API o manejo de archivos, serían pruebas de integración.
En Visual Studio .Net existen diversos frameworks para realizar estos testeos unitarios: XUnit, MSUnit y NUnit. Entre estos frameworks hay similitudes en la forma de escribir las pruebas y es sencillo migrar de uno a otro, ya que en la documentación oficial de XUnit se pueden encontrar estas equivalencias cambiando algunos decoradores o sintaxis. Para otros lenguajes, como por ejemplo, Java, encontramos los frameworks Junit o TestNG, para PHP PHPUnit, entre otros.
Las pruebas unitarias están compuestas por tres etapas siguiendo el patrón de las tres 3 A’s (Arrange, Act, Assert):
- Arrange (Organizar): definición de variables con las casuísticas que se desea probar.
- Act (Actuar): es propiamente la ejecución de esa unidad de código.
- Assert (Afirmar): verificación del resultado de la ejecución; si lo obtenido es lo que se esperaba.
Como sugerencia, la idea sería estandarizar el nombramiento de cada una de las pruebas creadas, con el fin de identificar o determinar con el nombre, qué se está probando y el resultado que se espera.
Según Vaxi Drez, quien crea contenido en la plataforma de Udemy para desarrollo con .Net, la nomenclatura debería estar compuesta por:
La acción que se va a probar, seguido de el o los inputs que tendrá la acción que se va a probar, seguido del resultado que se espera obtener.
Acción por probar – Inputs de la acción por probar – resultado esperado
A continuación, unos pequeños ejemplos:
Método que genera una cadena cifrada mediante el algoritmo SHA256 con base en unos parámetros de entrada.
