Desarrollar pruebas de xUnit que detecten errores con Copilot
Una prueba puede pasar demostrando muy poco. Verifica el comportamiento del repositorio de producción en lugar de probar un auxiliar definido únicamente dentro de la prueba.
Resumen del laboratorio
Ilustración conceptual original (SVG)
| De un vistazo | Tu ruta |
|---|---|
| Nivel y tiempo | 300; 65 minutos (estimación de facilitación) |
| Acción inicial | Agrega una prueba de componente con ID encontrado y comprueba las entidades pobladas mediante aserciones. |
| Materiales del aprendiz | Descarga 04-xunit.zip |
| Espacio de trabajo | Abre la raíz del kit extraído; ejecuta la baseline desde . relativa a esa raíz |
| Comprobación inicial esperada | Las pruebas suministradas pasan. Los nuevos requisitos de funcionalidad siguen necesitando sus propias pruebas. |
| Ayuda de configuración | Descarga, extrae, Git local y GitHub opcional |
[!NOTE] Simular el método bajo prueba no puede demostrar que su implementación funcione.
Conceptos · Primera tarea · Lista de evidencias · Restablecer
Objetivos de aprendizaje
- Distingue pruebas unitarias, de componentes y de interfaz.
- Usa las convenciones existentes de xUnit y NSubstitute.
- Aísla los datos del sistema de archivos y demuestra la detección de fallos.
Antes de empezar
Prepara 04-xunit con la configuración común.
Usa el
fixture de xUnit incluido.
No sustituyas xUnit por otro framework ni instales paquetes globalmente.
Conceptos y casos de uso
| Tipo de prueba | Objeto | Punto de aislamiento apropiado |
|---|---|---|
| Prueba unitaria de servicio | Decisión de préstamo o membresía | Sustituir el contrato de repositorio |
| Prueba de componente de repositorio | Cargar y completar registros JSON reales | Archivos temporales más JsonLoanRepository real |
| Comprobación de consola | Entrada y presentación | Escenario manual con guion |
El proyecto de pruebas existente referencia ApplicationCore. Probar Infrastructure requiere
una referencia explícita al proyecto; un mock de GetLoan no puede probar su propia implementación.
Escenario del ejercicio
Añade pruebas de repositorio para GetLoan: encontrado, ausente y relaciones completadas.
No añadas reglas de conversión de tipos no documentadas a una API de IDs enteros.
Tarea 1 - Inspeccionar y descubrir la línea base
dotnet test tests/UnitTests/UnitTests.csproj -m:1 -p:UseSharedCompilation=false --list-tests
dotnet test tests/UnitTests/UnitTests.csproj -m:1 -p:UseSharedCompilation=false
Lee JsonLoanRepository, JsonData, las pruebas de servicios existentes y LoanFactory.
Explica qué pruebas usan sustitutos y cuáles necesitan el comportamiento real de almacenamiento.
Tarea 2 - Diseñar los casos antes de generar pruebas
| Caso | Aserción |
|---|---|
| ID existente | Los campos del préstamo devuelto coinciden con el fixture |
| ID ausente | El resultado es null; ningún registro sintético de éxito |
| Relaciones encontradas | Usuario, ejemplar físico, libro y autor correctos |
| Archivo de préstamos vacío | Ninguna coincidencia falsa |
| Consulta de solo lectura | Los archivos fuente permanecen sin cambios |
| Archivo ausente o corrupto | Caracteriza el comportamiento actual del cargador; no inventes una alternativa |
Usa un directorio temporal en la unidad de trabajo con los cinco archivos JSON y rutas de configuración
que apunten allí. Evita escribir en el src/Library.Console/Json distribuido.
Tarea 3 - Planificar y generar una prueba
Solicita:
Trace GetLoan and JsonData.EnsureDataLoaded. What must a repository component test
construct? Cite the constructor and configuration keys. Do not mock the method
under test or create a replacement validation function in the test.
Planifica el ciclo de vida del fixture, los datos esperados y la limpieza. Después, en Agent:
- Añade la referencia al proyecto Infrastructure en el proyecto de pruebas.
- Crea una prueba de componente de ID encontrado usando el repositorio real.
- Verifica campos y relaciones, no solo «no es null».
- Usa una prueba que devuelva
Tasky espera al método con await. - Añade los casos restantes sin duplicar excesivamente la preparación.
Tarea 4 - Validar la calidad de las pruebas
-
Ejecuta las nuevas pruebas filtradas y después la batería del fixture:
dotnet test tests/UnitTests/UnitTests.csproj -m:1 -p:UseSharedCompilation=false --filter "FullyQualifiedName~JsonLoanRepository" dotnet test tests/UnitTests/UnitTests.csproj -m:1 -p:UseSharedCompilation=false -
Confirma que los nombres descubiertos coincidan con las pruebas previstas. Ajusta el filtro al nombre real de la clase en lugar de aceptar cero coincidencias.
-
Cambia deliberadamente el ID esperado. Verifica el fallo y después restáuralo.
-
Confirma que se limpien los datos temporales sin eliminar el directorio de otra prueba.
-
Opcional: ejecuta el recopilador de cobertura existente. Informa de la métrica real y de su alcance; un porcentaje no demuestra todos los requisitos.
Verifica tu trabajo
- Las pruebas ejercitan el repositorio de producción.
- Se espera al método asíncrono con await.
- Se verifican los campos y las referencias completadas.
- Los archivos están aislados y las consultas de solo lectura los dejan sin cambios.
- Una aserción incorrecta produce una salida distinta de cero.
Solución de problemas
Un espacio de nombres Infrastructure sin resolver suele indicar que falta una referencia de proyecto. Un archivo no encontrado suele indicar que la configuración apunta al fixture fuente o al directorio de trabajo incorrecto. No lo arregles copiando rutas absolutas específicas de tu máquina al código.
Práctica independiente
Prueba UpdateLoan con un ID conocido y documenta lo que ocurre con un ID ausente.
Separa la caracterización de cualquier cambio propuesto en la semántica de IDs ausentes.
Restablecimiento
Restaura únicamente los cambios de pruebas y referencias de proyectos en el proyecto copiado. Elimina su propio directorio temporal tras verificar la ruta. Mantén intactos los fixtures JSON originales.