No tienes acceso a esta clase

¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera

Pruebas Unitarias en .NET con XUnit: Resumen y Buenas Prácticas

11/19
Recursos

¿Qué es el desarrollo guiado por pruebas (TDD) y cómo se relaciona con las pruebas unitarias?

El Desarrollo Guiado por Pruebas, o TDD por sus siglas en inglés, es una metodología que propone construir el código de un programa a partir de las pruebas unitarias. Estas pruebas sirven como una base sólida, permitiéndonos comprobar la lógica del código antes de su implementación total. ¿Cómo funciona esto?

  1. Escribir una prueba fallida: Primero, se escribe una prueba que el nuevo código debe pasar, antes de que el código mismo sea escrito. Como el código no ha sido implementado, esta prueba inicialmente fallará.

  2. Implementar el código necesario: Luego, se desarrolla el código requerido para que la prueba pase.

  3. Refactorizar: Finalmente, se refina el código para mejorar su estructura y eficiencia, sin alterar su funcionalidad original.

Pese a sus ventajas, no es común aplicar TDD en todos los proyectos. Las pruebas unitarias, en la mayoría de los casos, se implementan posteriormante para asegurar y mantener la calidad del software.

¿Qué herramientas y librerías podemos usar en .NET para pruebas unitarias?

Visual Studio .NET ofrece varias librerías para la creación de pruebas unitarias, como MSTest, NUnit y XUnit. Cada una de estas librerías tiene sus propias características, aunque las diferencias principales residen en la sintaxis al implementar las pruebas. Algunos aspectos a considerar:

  • MSTest: Es la librería oficial de Microsoft y se integra perfectamente con Visual Studio.

  • NUnit: Ofrece gran flexibilidad y es similar a JUnit, la librería para Java.

  • XUnit: Favorecida por su enfoque moderno y el soporte de características avanzadas.

Es indispensable elegir una librería que se adapte a las necesidades del equipo y del proyecto, ya que nos permitirá escribir y ejecutar pruebas de manera eficiente.

¿Cómo nombrar correctamente los proyectos y clases de prueba?

El nombramiento adecuado de nuestros proyectos y clases de prueba es esencial para una organización clara y eficiente. Te recomendamos seguir estas pautas:

  • Proyectos de prueba: Crea un proyecto independiente para las pruebas, utilizando el mismo nombre que el proyecto a probar, añadiendo "Test" al final. Por ejemplo, para un proyecto llamado AplicacionPrincipal, el proyecto de prueba sería AplicacionPrincipalTest.

  • Clases de prueba: Sigue el mismo principio que con los proyectos. Si estás probando una clase llamada Calculadora, la clase de prueba debería llamarse CalculadoraTest.

Estos nombramientos facilitan la identificación de la relación entre los proyectos y las clases correspondientes.

¿Cuál es la estructura ideal para una prueba unitaria?

La estructura AAA (Arrange, Act, Assert) se posiciona como un estándar no solo para .NET, sino también para otros lenguajes y frameworks. Esta estructura garantiza claridad y mantenibilidad en las pruebas:

  1. Arrange (Preparar): Declara los objetos y variables necesarios para la prueba.

  2. Act (Actuar): Ejecuta la función o método que se desea comprobar.

  3. Assert (Afirmar): Realiza las comprobaciones necesarias para verificar que el resultado es el esperado, utilizando los asserts que provee la librería de pruebas.

La estructura AAA no solo mejora la legibilidad de las pruebas, sino que también es un tema frecuente en entrevistas de trabajo, por lo que es importante familiarizarse con su aplicación.

Es crucial recordar este enfoque al escribir pruebas, ya que favorecerá no solo el proceso de desarrollo sino también la futura mantenibilidad de nuestro código.

Cada vez que apliquemos estas prácticas, estaremos más preparados para enfrentar desafíos en la práctica y aumentar nuestro dominio sobre las pruebas unitarias en .NET utilizando XUnit. ¡Continúa explorando, aprendiendo y mejorando tu habilidad en pruebas unitarias!

Aportes 7

Preguntas 0

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad?

**Está muy bien que hagamos un "Revisemos lo que hemos aprendido" ya que nos ayuda a recordar y poder implementarnos con información que probablemente no hayamos entendido del todo.**
**Resumen de TDD vs unit Testing:** El TDD (Test Driven Development) y las "Unit Testing" (Pruebas Unitarias) son dos prácticas relacionadas pero diferentes en el desarrollo de software. El TDD es una metodología de desarrollo de software en la que se enfatiza la creación de pruebas antes de escribir el código de la aplicación. Las pruebas unitarias son una práctica dentro del desarrollo de software en la que se crean pruebas específicas para cada componente o unidad individual del código (por ejemplo, una función, método o clase) aisladamente.
**Pruebas Unitarias (Unit Testing)** **TDD(Test-Driven Development): Desarrollo basado en pruebas** Al principio se crean las pruebas, gracias a las historias de usuario ya se conocen los resultados de las pruebas, buscando un fallo de las pruebas ya que no existe aun la implementación del código, a medida que se avanza se van implementando cada código a cada prueba. Fail – Pass – Refactor **Pruebas unitarias**: son pruebas que se realizan sobre una unidad de código; una propiedad, una función o un método. Deben ser automatizables para ir implementando el código. Deben ser reutilizables e independientes. Son piezas de código que prueban otras piezas de código. Importancia: · Nos ayuda a verificar de manera rápida la lógica del negocio de nuestro código · Detectan cambios que afectan la funcionalidad de manera rápida · Se implementan del lado del desarrollo · Son fáciles de implementar. **Librerias de pruebas unitarias:** · **Microsoft Test(MSTest)** o **Gran soporte por el equipo de Microsoft** o **Exelente integración con visual studio.** o **Alta complejidad para algunos escenarios** · **NUnit** o **JUnit para .Net.** o **Opensource con gran soporte** o **Muy fácil de usar.** · **xUnit** o **Creada por la comunidad.** o **Open source con gran soporte.** o **Simplifica todo el proceso de creación de pruebas.** o **Una de las mas populares para nuevos y modernos proyectos con .NET** **\[Fact]** **Public void MyTest()** **{** **Var objectToTest = new MyClass();** **String result = objectToTest.Method();** **Assert.Equal(“MyResult”,result);** **}** Se agrega un nuevo proyecto para la prueba en la misma solución del proyecto que deseamos probar, a este proyecto se le nombra con el mismo nombre del proyecto a probar y se le agrega .Test al final. Para crear las pruebas de las clases, se crean también con el mismo nombre y al final se le agrega la palabra Test al final (en singular y sin punto ya que es una clase común y corriente .cs) Luego se agrega la referencia al proyecto al que le estaremos realizando las pruebas, esto se hace dando click en dependencias->Add Project Reference Se crea un método tipo void con el nombre del método que queremos probar(en este caso ConcatenateStrings()) Se le agrega \[Fact] Esto lo convierte en una prueba. Se crea una variable de tipo StringOperations() <- Esta es la clase que vamos a probar(contiene los métodos a probar) Hacemos el llamado al método a probar y almacenamos el resultado en una variable que luego comparamos con el resultado esperado. \[Fact] Public void ConcatenateStrings() { var strOperations = new StringOperations(); *//Este método espera dos strings para concatenarlos* var results = StringOperations.ConcatenateStrings(“Hola”,”Mundo”); *//Assert.Equal Compara valores, En este caso el resultado esperado y la //respuesta del método.* Assert.Equal(“Hola Mundo”,results); } Buenas practicas sobre pruebas unitarias que debemos aprender · Estructura AAA **(Profundizar sobre esto)** o Arrange: Configurar datos iniciales, datos de pruebas y variables o Act: Ejecucion de la prueba y guardar el resultado, normalmente se prueba una función a la vez o Assert: Comparar resultado esperado. · F.I.R.S.T Principios de pruebas **(Investigar sobre esto)** o Fast o Isolated/Independent o Repeatable o Self-Validating o Thorough Otra buena practica es llamar a la prueba con el nombre del método a probar y al final colocarle el nombre del escenario en particular que estamos observando por ejemplo en el caso anterior donde comparamos la concatenación de los dos strings en el escenario que sean iguales deberíamos poner al final del nombre de la prueba la palabra \_iguales o \_equals, luego crear otra prueba igual comparando donde no sea el resultado esperado, y pasar los respectivos resultados esperados. Asserts Usados: * Assert.Equal() = Compara dos valores si son iguales o no. * Assert.NotEquals()=Compara dos valores que no sean iguales. * Asser.True/False = verifica si un valor es True/False Assert.StartsWith()=Revisa si un string empieza con una palabra en particular. * Assert.Contains()=Comprueba si un Texto contiene un texto en particular. Reutilización de pruebas Atributos **Theory e InlineData** \[Theory] \[InLineData(“V”,5)] \[InLineData(“III”,3)] \[InLineData(“X”,10)] public void FromRomanToNumber(string romanNumber,int expected) { Var strOperations = new StringOperations(); Var result = strOperations.FromRomanToNumber(romanNumber); Assert.Equal(expected,result); } Theory e InLineData nos permiten crear pruebas con multiples valores en una misma prueba. Atributo Skip \[Fact(Skip=”Razon para omitir”] Esto permite omitir una prueba dependiendo de la necesidad, si sabemos que la prueba fallara.
**Estructura AAA (Arrange, Act, Assert)** La estructura AAA es un patrón común para organizar pruebas unitarias, proporcionando una forma clara y consistente de escribir pruebas. Aquí hay una descripción de cada paso: **Arrange (Preparar):** Configura el entorno necesario para la prueba. Esto incluye la creación de objetos, configuración de dependencias, y cualquier inicialización necesaria. `var calculator = new Calculator();` `int a = 5;` `int b = 10;` **Act (Actuar):** Ejecuta la operación o método que se quiere probar. `int result = calculator.Add(a, b)` **Assert (Afirmar):** Verifica que el resultado de la operación es el esperado usando asserts. `Assert.Equal(15, result);` **Ejemplo Completo usando AAA** `public class CalculatorTests` `{` ` [Fact]` ` public void Add_TwoNumbers_ReturnsSum()` ` {` ` // Arrange` ` var calculator = new Calculator();` ` int a = 5;` ` int b = 10;` ` // Act` ` int result = calculator.Add(a, b);` ` // Assert` ` Assert.Equal(15, result);` ` }` `}`
De momento hasta este punto y sin ver el video completo de esta clase me genera aun dudas de como se pueden implementar por ejemplo servicios, inyeccion de dependencias y cosas similares en las pruebas, me ha gustado el curso :D
Sin duda creo que lo que me aporto más es \[Theory] y \[InLineData]
Me pareció muy práctico el `[Theoy]` y el `[InlineData]` para reutilizar pruebas con parámtros.