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.