Pruebas unitarias fáciles de entender

Queremos que el código fuente del sistema sea fácil de entender para evitar retrasos y defectos, y las pruebas unitarias deberían cumplir con la misma meta. Veremos cinco recomendaciones:

  1. Organización por clases
  2. Organización con namespaces
  3. Cómo nombrar una prueba unitaria
  4. El patrón: Esperado, Obtenido y Comparación
  5. Organización de escenarios de prueba

Todos los ejemplos los puede leer completos en este repositorio: https://github.com/oscarcenteno/algoritmos.cs.garantias.

Organización por clases

Las pruebas unitarias de un método se ubican en una sola clase de pruebas unitarias. Recomiendo que nombremos las clases de pruebas unitarias como el método que prueban + “_Tests”. Agregando dicho sufijo evitamos errores frecuentes cuando los nombres producen conflictos de compilación.

Es decir, si probamos una propiedad llamada “AporteDeGarantia”, entonces su clase de pruebas unitarias se llama “AporteDeGarantia_Tests”, como en este ejemplo:

nombre-de-la-clase

 

De esta manera, logramos que todas las pruebas unitarias de un mismo método puedan leerse juntas y puedan compartir las mismas variables de instancia.

Organización con namespaces

Los mismos namespaces que nos ayudan a organizar los algoritmos que vamos a probar deberían existir en el proyecto de Pruebas Unitarias. Podemos decir que son un idénticos a nivel de namespaces y esto nos ayuda a encontrar fácilmente las pruebas de cualquier clase. Este es un ejemplo:

organizacion-por-namespaces

Cómo nombrar una prueba unitaria

Siguiendo la recomendación del libro “The Art of Unit Testing“, las nombramos con este patrón:

MetodoQueProbamos_Escenario_ResultadoEsperado

Especialmente en casos donde hay condicionales, en “Escenario” indicamos el caso que probamos. ResultadoEsperado explica en pocas palabras lo que esperamos recibir. Con esto, buscamos que cuando una prueba unitaria falle podamos ubicarnos fácilmente en cuál funcionalidad tiene un defecto:

ayuda-cuando-una-falla

El patrón: Esperado, Obtenido y Comparación

Este patrón logra una apariencia similar en todas las pruebas unitarias, y nos recuerda que toda prueba unitaria confiable tiene una comparación y solamente una.

esperado-obtenido-comparacion

Organización de escenarios de prueba

Cuando se da el caso que varias clases de pruebas unitarias tienen los mismos escenarios a partir de los cuales obtienen sus resultados, podemos extraer esos casos a una clase de “Escenarios”.

Esto nos ayuda a no duplicar código, y hace que todas las pruebas sean más concisas y claras. Los ejemplos anteriores utilizan una clase de Escenarios, y este es el contenido de parte de esta clase:

clase-de-escenarios

Puede leer todas las pruebas unitarias y sus escenarios en el repositorio: https://github.com/oscarcenteno/algoritmos.cs.garantias

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 )

w

Conectando a %s