UnitTest – ¿Qué nombre debe tener una prueba unitaria?

Si alguna vez has te has preguntado ¿Cómo nombrar una prueba unitaria? te recomiendo que leas este post.
        [TestMethod]//¿Qué prueba este método?
        public void Test1(){}

        [TestMethod]//¿Cuál es la respuesta esperada?
        public void GrabarCliente(){}

        [TestMethod]//¿Cuál es el escenario en que retorna falso?
        public void GrabarCliente_RetornaFalso(){}

        [TestMethod]//¿Por qué graba cliente y pedido a la vez?
        public void GrabarClientePedido_RetornaFalso(){}

Antes que todo debemos saber que asignar un nombre legible a una prueba unitaria es una tarea muy importante, sino realizamos correctamente esta actividad las pruebas unitarias no tendrían sentido.

En la vida diaria es común encontrar proyectos de pruebas unitarias que no describen adecuadamente la funcionalidad del sistema que se está probando (System under test). Este problema ocurre al nombrar clases y métodos de pruebas. Al revisar un proyecto podemos encontrar lo siguiente:

Clases de pruebas
Clases de pruebas

Como verán no es fácil identificar que funcionalidad se encarga de probar cada clase. Este problema también se repite al momento de asignar nombres a los métodos de prueba:

        [TestMethod]
        public void Test1(){}

        [TestMethod]
        public void Test2(){}

        [TestMethod]
        public void Test3(){}

        [TestMethod]
        public void Test4(){}

Entonces, ¿Qué nombre debe tener una clase de prueba?

En este caso aplico una formato muy sencillo: [NombreClase]Test.

  • Nombre de clase: Indica la clase que se encuentra bajo pruebas. Recuerda que cada clase de prueba solo debe contener las pruebas unitarias de una sola clase.

Ejemplos:

  • Clase ServicioCobranza => Prueba ServicioCobranzaTest
  • Clase ServicioLiquidacion => Prueba ServicioLiquidacionTest

Ahora, ¿Qué nombre debe tener una prueba unitaria?

Para el caso de las pruebas unitarias uso el siguiente formato que consta de tres partes: [Metodo]_[Escenario]_[Comportamiento].

  • Método: Nombre del método a ser probado. Debe responder a la siguiente pregunta: ¿Qué voy a probar? Si tienes más de una respuesta quiere decir que el método hace muchas cosas y no sigue el Principio de responsabilidad única.
  • Escenario: Indica el escenario propuesto de la prueba. Debe responder a la siguiente pregunta: ¿Qué caso voy a probar? Recuerda que cada prueba unitaria debe atacar solo un escenario.
  • Comportamiento: Es la respuesta esperada del escenario de prueba. Debe responder a la siguiente pregunta:  ¿Qué respuesta espero de la prueba? La respuesta puede ser uno de los siguientes tipos: un valor de retorno o excepción, un cambio de estado en el sistema o la llamada a una librería externa.

En este caso no uso el sufijo Test debido a que todos los métodos que se encuentran en esta clase ya son de pruebas, desde mi punto de vista suena redundante.

Ejemplo:

Para este ejemplo tenemos la clase ServicioCobranza con el método GenerarSolicutd y debe cumplir con los siguientes escenarios:

  1. Cuando llame al método GenerarSolicitud con un parámetro null, entonces devuelve un ArgumentNullException.
  2. Cuando llame al método GenerarSolicitud con una fecha mayor a la actual, entonces devuelve el mensaje “Invalido”.
  3. Cuando llame al método GenerarSolicitud con datos correctos, entonces debe enviar un correo de confirmación.

Para cumplir con lo solicitado necesitamos el siguiente código:

[TestClass]
public class ServicioCobranzaTest
{
        [TestMethod]
        public void GenerarSolicitud_ParametroNull_ThrowArgumentNullException(){}

        [TestMethod]
        public void GenerarSolicitud_FechaMayorALaActual_DevuelveMensajeInvalido(){}

        [TestMethod]
        public void GenerarSolicitud_DatosCorrectos_EnviaCorreoConfirmacion(){}
}

Conclusión

Para empezar a escribir pruebas unitarias primero debemos pensar en nombres claros y legibles para ayudar a otros desarrolladores a entender lo que se hizo. Al crear una clase de prueba se debe seguir el formato: [NombreClase]Test. En el caso de las pruebas unitarias se debe usar el formato: [Metodo]_[Escenario]_[Comportamiento] sin el prefijo Test. Finalmente, se debe tener en cuenta que una prueba unitaria solo debe probar una funcionalidad, si tu prueba se complica por los distintos flujos que tiene quiere decir que el método bajo prueba no sigue el principio de responsabilidad única.

Si te gusto este post entonces por favor ayúdame a difundirlo y logremos que el conocimiento se expanda, para lograr esto dale me gusta, compártelo en tus redes sociales a tus amigos o suscríbete a mi canal RSS, Gracias :).

Referencias:

Metal Tip:

Este artículo lo escribí escuchando la canción Cry for the moon de la banda Epica de Holanda, les comparto el enlace.

Happy coding and Stay Heavy lml

Anuncios

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 )

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 )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s