Resumen de pruebas unitarias con xUnit

Cursos Empresas Blog Live Conf Precios

Contenido del curso

Introducción

Pruebas unitarias con xUnit

¿Qué hemos aprendido?

11
Resumen de pruebas unitarias con xUnit
Viendo ahora

Utilizando librería moq

Cobertura de pruebas unitarias

Cierre

19
Qué aprendiste en este curso de xUnit
03:14 min

Tomar examen

Resumen de pruebas unitarias con xUnit

Resumen

Las pruebas unitarias en .NET con xUnit son la base para escribir código confiable y aplicar metodologías como TDD. Aquí repasamos los conceptos esenciales que necesitas dominar: la relación con Test Driven Development, las librerías disponibles, las convenciones de nombres y la estructura triple A para escribir pruebas mantenibles.

¿Cómo se relacionan TDD y las pruebas unitarias en .NET?

Test Driven Development es una metodología que se apoya por completo en las pruebas unitarias. La idea es escribir primero la prueba, ver que falla, implementar el código mínimo para que pase y luego refactorizar.

En la práctica, esto rara vez ocurre así. La mayoría de equipos escribe las pruebas después de implementar la lógica, con el objetivo de mantener la calidad del código y evitar regresiones. No está mal, pero conviene recordar el origen: las pruebas unitarias existen para sostener un ciclo de desarrollo guiado por verificaciones constantes.

¿Qué es TDD en pocas palabras? Es una metodología donde escribes la prueba antes que el código. Implementas, ejecutas la prueba y repites hasta que pase. Las pruebas unitarias son su base operativa.

¿Qué librerías puedes usar para escribir pruebas unitarias en .NET?

En el ecosistema .NET tienes tres opciones principales para crear tus pruebas, y cualquiera funciona bien. Lo único que cambia entre ellas es la sintaxis y algunos atributos.

MSTest: la opción nativa de Microsoft.
NUnit: una librería madura y muy usada en la comunidad.
xUnit: moderna, ligera y la que se utiliza en este curso.

Elegir entre ellas depende del equipo y del proyecto. Si llegas a una base de código existente, lo normal es seguir con la que ya esté configurada.

¿Cómo se nombran los proyectos y clases de prueba?

Una convención clara facilita encontrar y mantener tus pruebas. La regla es simple: replica el nombre original y añade la palabra test al final.

Nombres de proyectos

Las pruebas unitarias siempre van en un proyecto independiente dentro de la solución. Si tu proyecto se llama MiAplicacion, el proyecto de pruebas debe llamarse MiAplicacion.Test. Así, con solo leer el nombre, sabes a qué proyecto hacen referencia esas pruebas.

Nombres de clases

La misma lógica aplica a nivel de clase. Si estás probando la clase CalculadoraService, tu clase de pruebas se llama CalculadoraServiceTest. Esta correspondencia uno a uno hace que el equipo encuentre rápido la prueba asociada a cualquier pieza de lógica.

¿Por qué separar el proyecto de pruebas? Para no incluir código de testing en el binario de producción y mantener las dependencias limpias.

¿Qué es la estructura triple A en pruebas unitarias?

La estructura triple A (Arrange, Act, Assert) es el estándar para escribir pruebas legibles, sin importar el lenguaje o framework que uses. Te organiza el cuerpo de cada prueba en tres bloques claros.

Arrange: declaras los objetos, datos o variables que necesitas para la prueba.
Act: ejecutas la función o método que quieres probar.
Assert: realizas todas las comprobaciones con los asserts que ofrece tu librería.

Seguir este patrón hace que cualquier persona del equipo lea una prueba y entienda en segundos qué se está verificando. También facilita el mantenimiento cuando la lógica cambia. Y como dato extra, es una pregunta clásica en entrevistas técnicas para roles de desarrollo en .NET.

¿Cuál es la estructura ideal de una prueba unitaria? Triple A: primero preparas el escenario, luego ejecutas la acción y por último verificas el resultado con asserts.

Cuéntame en los comentarios cuál ha sido el concepto más retador hasta ahora y qué tema te interesa profundizar en la segunda mitad del curso.

Comentarios

Ricardo Ivan Mora Salazar

Estudiante

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.

Chanel Mariannis Paredes Sánchez

Estudiante

Así es.

Sergio Sanchez

Estudiante

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.

Jhan Carlos Bacca

Estudiante

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.

Johan Sebastian Arboleda Mazo

Estudiante

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); } }

David Sanchez

Estudiante

Esta es la primera vez que veo este curso. Tenía que hacer pruebas unitarias, y no sabía como hacer le pedí a la IA que generara los unit test, pero no entendía nada, revisé este curso, y la manera como enseñaron, fue lo mejor, me ayudó a entender de manera muy sencilla los casos de uso, y los test unitarios

Daniel Mauricio Becerra Rincon

Estudiante

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

Juan Daniel Ramirez Coroy

Estudiante

Sin duda creo que lo que me aporto más es [Theory] y [InLineData]

Raúl Alejandro Chávez Valenzuela

Estudiante

Me pareció muy práctico el [Theoy] y el [InlineData] para reutilizar pruebas con parámtros.

Introducción

Pruebas Unitarias en .NET: Calidad en Desarrollo de Aplicaciones

Prerrequisitos para pruebas unitarias en .NET

Qué son las pruebas unitarias y TDD

Pruebas Unitarias en .NET con XUnit: Implementación y Ejemplos

Descarga y explora el proyecto StringManipulation

Pruebas unitarias con xUnit

Primera prueba unitaria con xUnit en .NET

Buenas prácticas y asserts en xUnit

Pruebas con StartsWith, Contains y Throws

Pruebas parametrizadas con Theory e InlineData

Atributo Skip en xUnit para pausar pruebas

¿Qué hemos aprendido?