Configurar pruebas unitarias en un proyecto .NET es el primer paso para automatizar la calidad de tu código en un flujo DevOps. Aquí aprenderás cómo crear un proyecto de pruebas unitarias con xUnit, vincularlo a tu API de contactos y ejecutarlo desde la terminal, partiendo del repositorio del curso y avanzando a un ritmo práctico.

¿Por qué configurar pruebas antes de subir a la rama main?

Subir código directamente a main es un error común, incluso entre quienes llevamos años en esto. La solución empieza por preparar tu proyecto para que cada cambio pase por validaciones automáticas, y eso requiere tener pruebas unitarias bien configuradas desde el inicio.

En el repositorio del curso encontrarás una carpeta llamada Docs con archivos Markdown. Dentro de la clase seis hay una secuencia de comandos lista para copiar y pegar en tu terminal, pensada para que avances rápido sin detenerte en conceptos básicos de programación o infraestructura.

¿Qué es una prueba unitaria? Es un fragmento de código que valida automáticamente que un método de tu aplicación devuelve el resultado esperado, aislando esa unidad del resto del sistema.

¿Cómo crear el proyecto de pruebas con xUnit y .NET?

Desde tu terminal, ubícate en la carpeta src del proyecto. El primer comando crea un proyecto de pruebas usando la plantilla xUnit, uno de los frameworks más usados en el ecosistema .NET [2:00].

El flujo es el siguiente:

1. Crea el proyecto con dotnet new xunit nombrándolo ApiContactos.Test.
2. Verifica que la carpeta exista con ls.
3. Agrega una referencia desde ApiContactos.Test hacia el proyecto original ContactosApi usando dotnet add reference.
4. Confirma la referencia abriendo el archivo .csproj en Visual Studio.

El archivo .csproj es la definición del proyecto en .NET, y ahí queda registrada la dependencia entre el proyecto de pruebas y el proyecto principal. Esto permite que las pruebas accedan a las clases y métodos de la API.

¿Para qué sirve el archivo sln en .NET?

Un archivo .sln, o archivo de solución, agrupa varios proyectos relacionados bajo un mismo contenedor lógico. Es estándar en .NET y facilita compilar y administrar múltiples proyectos a la vez [3:30].

Los pasos son:

• Eliminar cualquier .sln generado por error fuera de src.
• Crear uno nuevo con dotnet new sln llamado ApiContactos.sln.
• Vincular ambos proyectos al .sln con dotnet sln add, primero ContactosApi y luego ApiContactos.Test.

Con esto tienes una solución única que orquesta tu API y tus pruebas.

¿Cómo vincular el proyecto de pruebas con la API de contactos?

Después de tener la solución armada, necesitas un paquete de NuGet que conecte xUnit con tu API web. NuGet es el gestor de paquetes oficial de .NET, equivalente a npm en Node.js.

Instala el paquete con dotnet add package siguiendo el comando del repositorio. Una vez agregado, copia el bloque de código de pruebas que aparece en la guía y pégalo dentro del archivo de pruebas de ApiContactos.Test, reemplazando el contenido por defecto [4:50].

Ese bloque hace dos cosas clave:

• Crea una vinculación con el método Weather Forecast, que viene por defecto en proyectos nuevos de API en .NET.
• Define una prueba unitaria sobre ese método para validar que responde correctamente.

¿Qué es Weather Forecast en .NET? Es el endpoint de ejemplo que se genera automáticamente al crear un proyecto de API con la plantilla por defecto, útil para probar configuraciones antes de escribir tu propia lógica.

¿Cómo ejecutar dotnet test y resolver el error de Program inaccesible?

Con todo configurado, ejecuta dotnet test en la terminal. El comando hace dos cosas en orden: compila ambos proyectos y luego corre las pruebas del proyecto de testing contra el proyecto original.

Es muy probable que aparezca un error indicando que Program es inaccesible. Esto ocurre porque, por defecto, la clase Program en .NET es interna y el proyecto de pruebas no puede acceder a ella desde fuera.

La solución es abrir el archivo Program.cs y agregar al final la línea:

csharp public partial class Program { }

Esta declaración convierte a Program en una clase parcial pública, lo que permite que el proyecto de pruebas la vea y pueda ejecutar validaciones sobre ella [6:30].

¿Qué significa que las pruebas pasen exitosamente?

Al volver a ejecutar dotnet test, los resultados muestran que la prueba pasó una vez y que solo existía una prueba en total. Esto confirma que:

• Ambos proyectos compilan sin errores.
• La vinculación entre ApiContactos.Test y ContactosApi funciona.
• El método validado responde como se espera.

Con esta base lista, tu proyecto de API ya tiene pruebas unitarias automatizables, requisito indispensable para integrarlas en un pipeline de CI/CD en la siguiente etapa.

¿Te ha pasado que olvidas hacer pública la clase Program y te pierdes media hora buscando el error? Cuéntame en los comentarios cómo resolviste tu primera configuración de pruebas en .NET.