• Author / Uploaded
• noseii

Citation preview

Qué es un unit test Microsoft Community Publishing Service|Última actualización: 26/05/2017 | 1 Colaborador  

EN ESTE ARTÍCULO

Diego Rojas MCTS WCF 3.5 - MCTS Biztalk - MCTS Data Access Mayo 2012 Blog Existen muchas definiciones acerca de lo que realmente es una prueba unitaria – unit test – sin embargo algunas son ambiguas y otras tienen un enfoque determinado de acuerdo a la situación en que se utilizan o se desarrollan. En este post vamos a tratar de caracterizar más que definir que es una prueba unitaria.

Identificar un Unit Test Un unit test es un método que prueba una unidad de código. Al hablar de una unidad de código nos referimos a un requerimiento. Muchos desarrolladores tienen su propio concepto de lo que es una prueba unitaria; sin embargo, la gran mayoría coincide en que una prueba unitaria tiene las siguientes características: 

Prueba solamente pequeñas cantidades de código: Solamente prueba el código del requerimiento específico.



Se aísla de otro código y de otros desarrolladores: El unit test prueba exclusivamente el código relacionado con el requerimiento y no interfiere con el trabajo hecho por otros desarrolladores.



Solamente se prueban los endpoints públicos: Esto principalmente porque los disparadores de los métodos privados son métodos públicos por lo tanto se abarca el código de los métodos privados dentro de las pruebas.



Los resultados son automatizados: Cuando ejecutamos las pruebas lo podemos hacer de forma individual o de forma grupal. Estas pruebas las hace el motor de prueba y los resultados de los mismos deben de ser precisos con respecto a cada prueba unitaria desarrollada



Repetible y predecible: No importa el orden y las veces que se repita la prueba, el resultado siempre debe de ser el mismo.



Son rápidos de desarrollar: Contrariamente a lo que piensan los desarrolladores –> que el desarrollo de pruebas unitarias quita tiempo – los unit test por lo general deben de ser simples y rápidos de desarrollar. Difícilmente una prueba unitaria deba de tomar más de cinco minutos en su desarrollo.

Ejemplo

Para entender mejor que es una prueba unitaria vamos a proceder a hacer un ejemplo. Supongamos que tenemos un método que nos indica si en un arreglo de strings existe al menos un string que sea igual a la palabra que estamos pasando por parámetro. El código del método es el siguiente: public class AdministradorDeArreglos { public bool ExisteEnArreglo(string[] pArreglo, string pPalabra) { return pArreglo.Any(p => p.ToUpper() == pPalabra.ToUpper()); } }

Para probar el Código escribimos lo siguiente static void Main(string[] args) { var _administradorDeArreglos = new AdministradorDeArreglos(); string[] _arreglo = {"Manaza", "Papaya", "Melón", "Sandía", "Piña", "Banano"}; Console.WriteLine(_administradorDeArreglos.ExisteEnArreglo(_arreglo, "Banano") ); }

Y el resultado final será:

Ahora vamos a proceder a probar el código creando una prueba unitaria. El primer paso es agregar un proyecto a la solución del tipo Test –> vamos a utilizar MSTest para hacer las pruebas unitarias en este ejemplo [Observación: Yo utilizo Visual Studio Ultimate por lo tanto algunas opciones de testing pueden no aparecer en otras versiones menores o pueden estar en otro orden].

Como vemos en la siguiente figura, se va a crear un proyecto de testing que tiene una referencia directa al componente – dll – en donde están todas las librerías para hacer pruebas unitarias con el MSTest. Además, se crea un archivo inicial de testing y un grupo de tres “Solution Items” desde donde vamos a poder configurar y administrar las funcionalidades de nuestros tests.

Ahora procedemos a borrar el archivo UnitTest1.cs y vamos a crear uno desde cero. Luego de borrar el archivo, procedemos a agregar una referencia al proyecto que queremos probar. Luego damos botón derecho sobre el proyecto de testing y seleccionamos agregar nuevo test.

Ahora procedemos a seleccionar el tipo de prueba de unidad que vamos a crear, en nuestro caso una prueba de unidad básica.

Este paso nos va a generar un archivo de pruebas básico con un método de pruebas de ejemplo que cual vamos a proceder a eliminar. using Microsoft.VisualStudio.TestTools.UnitTesting; namespace Pruebas { [TestClass] public class Pruebas_SeriePruebasUnitarias { [TestMethod]

public void TestMethod1() { }

}

}

En el código anterior vemos que la clase generada esta marcada con el atributo TestClass, esto le indica al motor de pruebas de visual studio que dentro de esta clase existen pruebas de unidad que debe ejecutar. Los métodos de prueba son métodos públicos de tipo void que están marcados por el atributo [TestMethod] como se ve en la figura anterior. Ahora procedemos a crear nuestra primera prueba unitaria. El código de la prueba unitaria es el siguiente: [TestClass] public class Pruebas_SeriePruebasUnitarias { [TestMethod] public void ExisteArreglo_RetornaTrue() { var _administradorDeArreglos = new AdministradorDeArreglos(); var _resultado = _administradorDeArreglos.ExisteEnArreglo(new[] { "Argentina", "Brasil", "Perú" }, "Brasil"); Assert.IsTrue(_resultado); } }

La prueba unitaria anterior prueba específicamente la unidad de código “ExisteEnArreglo” de la clase AdministradorDeArreglos. Al Ejecutar el unit test el resultado será el siguiente:

Como podemos ver, el test pasó y el panel de resultados de VS así me lo hace saber. Estructura del Unit Test Para terminar, es importante notar que los unit test tienen por lo general una estructura compuesta de tres partes: Arrange: Es la parte del unit test en donde se configura todo el código para ejecutar la prueba unitaria. En nuestro caso, el “arrange” es la creación de la instancia de la clase AdministradorDeArreglos. Act: Esta es la fase del unit test en donde se ejecuta el código a probar. En nuestro caso es la invocación del método de instancia ExisteEnArreglo.

Assert: Es la sección de la prueba unitaria en donde se prueba el resultado del mismo. En este caso y por lo general, lo hacemos con la clase Assert –> en MSTest –> y es donde verificamos que la variable _resultado == true;

Sobre TDD con Visual Studio Microsoft Community Publishing Service|Última actualización: 26/05/2017 | 1 Colaborador  

EN ESTE ARTÍCULO

Nicolás Herrera MVP, miembro Gold del grupo de Microsoft Community Specialist Colombia, blogger y speaker Julio 2012 Blog En nuestro diario vivir como desarrolladores siempre debemos cumplir con tareas que demandan tiempo como pueden ser realizar cambios en el código, hacer mantenimiento a un software o simplemente querer desarrollar más rápido y mejor. Pero ¿cómo se podrían lograr estas metas? Bien, pues aplicando unos conceptos claves a la hora del desarrollo, como lo son Refactoring y *Pruebas Unitarias. * El refactoring es una técnica para reestructurar un código fuente, alterando su estructura interna sin cambiar su comportamiento externo, esto es, la capacidad de mejorar el código sin perder la funcionalidad del mismo y lo aplicamos siempre que veamos acoplamiento, complejidad innecesaria y en general siempre que veamos algo que puede ser mejorado, y para poder aplicar el refactoring debemos apoyarnos de las pruebas unitarias, ¿por qué? Porque es difícil pensar en cambiar algo que creemos que funciona perfectamente. Las pruebas unitarias son código que prueba otro código, con Visual Studio por ejemplo, tenemos herramientas que nos permiten hacer este tipo de pruebas a nuestro código persiguiendo el objetivo de verificar que estamos cumpliendo con los requerimientos del cliente, esto nos permite trabajar de la mano del cliente mostrando resultados inmediatos y corregir en tiempo record, no solo nuestros errores si nos los mismos errores del cliente, pues como sabemos NI SIQUIERA LOS CLIENTES SABEN LO QUE QUIEREN y si no lo sabías, no esperes a comprobarlo. Ahora bien, ¿sobre qué aplicamos nuestras pruebas unitarias? Estas se deben aplicar sobre las partes más pequeñas y comprobables de una aplicación, esto es, en los métodos de las clases. Características de las pruebas unitarias: 

Automatizable: no debería requerirse una intervención manual.



Completas: deben cubrir la mayor cantidad de código.



Repetibles o Reutilizables: no se deben crear pruebas que sólo puedan ser ejecutadas una sola vez.



Independientes: la ejecución de una prueba no debe afectar a la ejecución de otra.

Las pruebas unitarias están conformadas por una estructura triple A, estas son: 

Arrange (Inicialización): donde se prepara el contexto de la prueba y se inicializan variables y demás.



Act (Ejecución): Ejecutas la funcionalidad que se desea probar.



Assert (Comprobación): se comprueba que lo que se ejecuto hace lo que se desea.

¿Y todo esto para qué? Las dos practicas que se mencionaron anteriormente constituyen al TDD, el test driven development es toda una forma de construir software y se basa en que las pruebas son las que deben regir el desarrollo, esto es, antes de tener empezar a escribir código funcional escribimos primero la prueba y luego si nos preocuparemos de su implementación. Para hacer TDD aplicamos el semáforo de las TDD, esto es, Rojo, Verde Refactoring, es decir, primero escribimos las prueba, probamos que falle, escribimos el código necesario para que funcione y comprobamos si algo puede ser mejorado y refactorizamos Ejemplo: Para este ejemplo, supondremos que nuestro cliente nos ha pedido una calculadora que dado dos números enteros haga las operaciones básicas, estas son Suma, resta, multiplicación y división. Empezamos por crear un proyecto de librería de clases donde tendremos el código y para realizar las pruebas a este código, agregaremos un nuevo proyecto de tipo test, eliminamos las clases que nos genera Visual Studio automáticamente:

Agregamos una clase llamada Operacion al proyecto calculadora, y sobre el proyecto de test añadimos un test llamado CalculadoraTest, sobre este agregamos una referencia al proyecto Calculadora. Lo siguiente será realizar la prueba más simple (en este caso todas son igualmente simples) pero empezaremos por poder sumar dos números. Nuestra primera prueba unitaria luciría de esta forma:

Vemos que Visual Studio nos informa que el método Sumar(int, int ) no existe en la clase operación, entonces le pedimos a este que nos cree el método en esta clase:

Compilamos, comprobamos que compila, ejecutamos la prueba unitaria haciendo click derecho en el método y comprobamos que falle:

Lo que sigue es intentar ponerla en verde, para esto realizamos los cambios necesarios en el método Sumar:

Volvemos a ejecutar la prueba y comprobamos que funcione:

El siguiente paso es hacer refactoring, pero simplificar o arreglar la implementación de este método es innecesario porque es muy simple. Seguimos escribiendo las pruebas para cada uno de los requerimientos que tenemos, implementamos, comprobamos que fallen, hacemos solo lo necesario para que funcionen y hacemos refactoring, el resultado de mis pruebas es:

Sí, me falla una prueba, y es una prueba un poco rara, pero es que este es uno de los principios de TDD, no solo podemos probar lo que estamos seguros funcionara, debemos probar también lo mas poco común y que es lo que siempre falla en producción, pues si hay algo para lo que es bueno un usuario final, es para reventar programas no se ofendan. El código de esta prueba es:

Hacemos lo necesario para que esta prueba funcione, y volvemos a correr todas las pruebas:

Bien con esto llegamos al final de esta introducción a las TDD con Visual Studio, en próximos post veremos más a detalle esta herramienta y otras más, espero además poder presentarles unos casos más empresariales y cómo podemos afrontarlos desde el punto de vista de las TDD.