Las Pruebas Unitarias

Hoy estoy abriendo un nuevo sub genero de temas en este blog, Basado en Q.A y Tdd que orientare a lo largo de este año (2018) a Python, Ruby y C#. Con esto espero no dejar de lado sobre

Las pruebas unitarias: 

Funcionan como un control de calidad y de efectividad del código. A través de ellas, podemos ver cómo una unidad de código es investigada y cómo esta funciona  de manera correcta o incorrecta. Al igual que en la ingeniería mecánica, las pruebas consisten en llevar un mecanismo desde su estado primigenio hasta forzar un comportamiento y/o llevarlo a un  ambiente hostil, probando sus respuestas y comportamiento interno. Cuando pensamos en pruebas unitarias, pensamos en cada caso por separado; con esto quiero decir que pensamos en cada prueba como única e independiente. Imaginemos que somos los profesores de un salón y que cada pregunta en un examen es una caso; Desde la primera pregunta, como por ejemplo: ¿Cuál es tu nombre?, hasta la más complicada,  como por ejemplo: Defina los pasos a seguir en caso de ser abordado por un marciano embriagado con Coca-Cola? Haciendo alusión a las preguntas, la primera es sencilla; el código/persona dirá su nombre y en la última es muy probable que ambos sujetos a evaluar queden consternados, de esta manera se analiza la respuesta buscando que tipo de excepcion u error arroja.

Las pruebas unitarias que, en este caso, las pensamos como preguntas de un examen, son entonces preguntas concretas y simples, y en la mayoría de las veces deben ser atómicas. ¿Qué eres? ¿Qué das? ¿Cómo lo das? Para luego integrarlas todas en una sola ejecución, a diferencia de las pruebas de integración, que probarían directamente un sistema combinado con otro, algo así como probar que ambos se hablan y se comunican bien y de forma correcta.

En ocasiones,  para realizar las pruebas unitarias debemos saber que es 50 % conocimiento del código y otro 50% creatividad destructiva. Lo digo porque debemos considerar todas las otras maneras en las que el sistema/código no debe funcionar para así, ver cómo reacciona y en caso de ser pertinente modificar el código para adecuarlo a pasar la prueba.

La mayoria del tiempo cuando realizamos pruebas unitarias analizamos la excepciones que arrojan. El trabajo de pruebas unitarias pasa desde el punto de buscar que una respuesta sea correcta pero siempre con el objetivo de buscar inconcistencias y errores que puede o debe responder un programas, es entonces las pruebas unitarias en un 70% la busqueda y control de excepciones de un sistemas o codigo, por ello es el campo al cual mayo importancia le debemos destinas. En sisntencis muchas veces al realizar pruebas unitarias sonbre un proyecto nuevo las excepciones son escasas y en la gran mayoria estan controladas, conforme el proyecto crece y se anaden nuevas lineas, metodos o clases es cuando mas excepciones pueden aparecer, por ende se debe re-organizar o re-editar pruebas unitarias que tomen dichos errores y los cotejen contra lo que se quiere dar. Para ejemplificar esto de mejor maneras pensemos en un algoritmo que debe arrojar la suma de dos enteros,  al dicho algoritmo se le pasa o sobrecargan dos enteros y sabiendo la respuesta se buscar que sea la correcta, si pasa entonces el algoritmo de suma esta correccto. Sin embargo que pasaria si se le sobrecarga con dos string u objetos de tipo numericos pero no del tipo enteros?. En alguno de estos caso arrojara error indefactiblemente, y surge la duda, Debemos capturar el error y hacerle un correcto manejo o refactorizar el codigo para que este intente transformar los valores que se le pasa al tipo que se maneja en el metodo?. Cualquiera de estas dos opciones son validas, no obstante es vital modificar la pruebas unitarias y en el caso del codigo refactorizar es indispensable.

una maqueta de pruebas a este modulo como ejemplo seria algo asi como:

1. uso el metodo con dos enteros.
2. uso el metodo con un entero y un string
3. uso el metodo con dos string 
4. uso el metodo con dos valores flotantes
5. uso el metodo y no sobrecargo los parametros

en el caso de 2 y el 3 debe arrojar error, pero es valido que el codigo intente transformar los valores que vienen en string a numerico en caso de que el string se un numero como por ejemplo: "3" en vez de un 3

Ventajas de las pruebas unitarias: 

• Errores acotados: las pruebas unitarias te permiten saber dónde está tu zona de código efectivo y por ende poder localizar errores más fácilmente. 
• Son parte de la documentación del código. 
• Simplifican la integración: aseguran las fases de integración del código  con otros sistemas para las pruebas de integración. 
• Aprueban el cambio: son una herramienta excelente para que los desarrolladores cambien de manera positiva el código, mejorando su funcionamiento. 
• Separación de la interfaz y la implementación: Dado que la única interacción entre los casos de prueba y las unidades bajo prueba son las interfaces de estas últimas, se puede cambiar cualquiera de los dos sin afectar al otro, a veces usando objetos mock (mock object) para simular el comportamiento de objetos complejos 
• Calidad legal  Proporcionan un contrato escrito que el trozo de código debe satisfacer 

Características  

Cuando me preguntan cómo son las pruebas unitarias suelo responder que son ACAPRI. Esto significa:

• Automatizables: No debería requerirse una intervención manual 
• Completas: Cubren la mayor parte de código posible 
• Atómicas:  Pequeñas e dirigidas a un punto del código en concreto 
• Profesionales: Son igual de importantes y forman parte del proyecto 
• Reusables: deben apoyar la metodología DRY (Don’t Repeat Yourself), incluso entre proyectos 
• Independientes: Aunque pueden comportarse o ejecutarse en cadena, cada una debe poder ejecutarse por separado 

Pruebas de integración: 

Se centra principalmente en probar la comunicación entre los componentes y sus comunicaciones ya sea hardware o software. La prueba de subsistemas es un tipo de prueba de integración donde se prueba el contenido de un subsistema.