NUnit, ¿Por qué esta librería?

En una entrada anterior sobre herramientas para unit testing recomiendo usar esta librería, aquí justificaré y explicaré muy rápidamente algunas de las razones, como siempre estoy acostumbrando a hacer en mis entradas, aportando ejemplos prácticos, que para buscar teoría y documentación ya hay bastante fuentes.

Desde mi primera entrada comenzando a describir qué es un unit test ya menciono etiquetas propias de NUnit, como [TestFixture] para las clases que alojan baterías de test o [Test] para los test en sí. La funcionalidades que estas data annotation logran existe en las librerías nativas de microsoft, así que como podrás intuir no es la única razón y hay algo más detrás de esta elección.

NUnit extiende varios atributos a tus test, extiende assertions, aporta nuevas características y funcionalidades, una interfaz gráfica para analizar los resultados de los test, si es que necesitas esto último, dado que visual studio ofrece de por sí una magnifica interfaz para analizar el resultado de ejecutar tus test, y NUnit se integra perfectamente con visual studio.

En la página del proyecto de NUnit, en github, puedes encontrar toda la documentación referente a lo que te estoy comentando, así que no me enrollo más y voy a la práctica.

En mi entrada sobre TDD estoy haciendo un ejemplo sobre un método que devuelve un resultado bool true o false de comparar dos objetos byte[], para ello estoy escribiendo dos test, idénticos, únicamente cambian los parámetros de entrada. Esto en NUnit podría resolverse con el attribute llamado TestCases. No pretende simular diferentes test, si no ejecutar un mismo test con diferentes entradas y validar sus diferentes resultados.

El attributo TestCase esta recibiendo 3 parámetros, los dos primeros se están usando como parámetros de entrada del test, y el ultimo parámetro (ExpectedResult), indica cual es el resultado que el test deberá devolver para esos parámetros para que de un resultado positivo.

De esta forma hemos condensado dos tests en solo uno que recibe 2 casos de prueba.

Esto puede ser muy útil, o algo complicado de manejar, ya que la interfaz gráfica para analizar resultados puede no ser demasiado clara acerca de que caso de prueba es el que falla en caso de que el test sea rojo. Por ello puede ser una util herramienta para aplicar a un test diferentes casos de prueba que siempre deban arrojar el mismo resultado.

Si por ejemplo un usuario tiene posibilidad de editar 5 roles, pero para 3 tiene permiso y para 2 no, en lugar de crear un test con 5 casos de prueba, puede resultar mas ventajoso crear 2 tests, uno con 3 casos de prueba y otro con 2, en lugar de escribir 5 tests.

NUnit además puede ser ventajoso para categorizar test en base a una buena variedad de atributos, lo cual nos facilitará el mantenimiento posterior de los test, pero esto es algo sobre lo que escribiré en otra entrada.

Deja un comentario