01
Qué es y qué problema resuelve
Una prueba unitaria verifica una regla con pocas dependencias y una causa de fallo comprensible. El valor no proviene de cubrir líneas, sino de detectar cambios que romperían una garantía.
Una regla de cancelación, un intervalo inválido o una autorización por grupo tienen entradas y resultados observables.
02
Ejemplo paso a paso
Punto de partida Ejemplo autónomo con comprobaciones de consola. En el proyecto usa el framework de pruebas elegido y una prueba con nombre por comportamiento.
Antes de ejecutar
Ejemplo de consola .NET 10. Integra el fragmento en Program.cs o en sus tipos auxiliares según corresponda; no mezcles declaraciones de tipos antes de instrucciones de nivel superior. No requiere una API ni una base.
static bool PuedeReservar(int asistentes, int capacidad) =>
asistentes > 0 && asistentes <= capacidad;
if (!PuedeReservar(8, 8)) throw new Exception("Debe admitir aforo exacto");
if (PuedeReservar(9, 8)) throw new Exception("Debe rechazar sobreaforo");
if (PuedeReservar(0, 8)) throw new Exception("Debe rechazar grupo vacío");
Console.WriteLine("Tres límites comprobados");Cómo funciona
- El caso de aforo exacto comprueba el límite inclusivo.
- El sobreaforo y el grupo vacío comprueban dos rechazos distintos.
- Cambiar temporalmente <= por < debe hacer fallar la primera comprobación.
Resultado esperado: Las tres comprobaciones pasan; cambiar <= por < debe hacer fallar el caso de aforo exacto.
03
Cuándo usarlo y qué debes evitar
Organiza preparación, acción y comprobación. Usa datos que expliquen el límite, y evita afirmar sobre llamadas internas si el requisito es un resultado de negocio.
No mezcles acceso de red con una prueba del dominio. Una prueba negativa debe explicar qué efecto no ocurrió y por qué.
Ampliación opcional · contexto y variantes del tema
Una estrategia de pruebas por frontera
Pruebas unitarias comprueban reglas y casos de uso aislados; integración prueba adaptadores, contratos HTTP y motor de datos; arquitectura verifica dependencias; un pequeño conjunto end to end observa flujos críticos desplegados. El número de mocks no mide calidad: una prueba que replica cada llamada interna puede impedir refactorizar sin detectar un defecto real.
El laboratorio usa 15 comprobaciones ejecutables sin paquetes externos para hacer accesible el primer paso. Falla con una excepción y código de salida distinto de cero si una condición no se cumple. Para un proyecto mayor adopta un framework de pruebas que dé descubrimiento, reportes y paralelización controlada. No presentes este runner como pruebas de integración de EF o HTTP.
En integración de EF prueba traducción de Specification, restricciones y dos conexiones en conflicto con el proveedor real. El proveedor InMemory no reproduce SQL, transacciones ni restricciones del motor. Para HTTP usa un host de pruebas y verifica JSON, estado y efectos. Un adaptador falso de autenticación solo se registra en ese host aislado.
Punto de partida La prueba protege una regla observable. Si cambias la condición por true, debe fallar. Ese ensayo de mutación muestra que la comprobación puede detectar el defecto que intenta prevenir.
Antes de ejecutar
Fragmento de prueba con tipos del laboratorio
var reserva = new Reserva(Guid.NewGuid(), "grupo-lima",
"sala-norte", new Intervalo(inicio, inicio.AddHours(1)));
if (Acceso.PuedeCancelar("grupo-cobre", reserva))
throw new InvalidOperationException("Acceso cruzado aceptado");Resultado esperado: La identidad ajena se rechaza; la reserva sigue activa.
04 · Práctica guiada · opcional
Practica lo aprendido
Comprueba aforo exacto, sobreaforo y grupo vacío con el ejemplo. Cambia temporalmente <= por < y verifica qué prueba detecta el defecto.
- 01Ejecuta los tres casos: 8 de 8, 9 de 8 y 0 de 8.
- 02Cambia el límite inclusivo por exclusivo y conserva el fallo del caso exacto.
- 03Restaura la regla y verifica las tres comprobaciones; después puedes ampliar a Intervalo y Cancelar.
Ver solución orientativa
8 de 8 se acepta; 9 y 0 se rechazan. Al usar < falla el aforo exacto. Esta sensibilidad demuestra que el caso protege ese borde; no demuestra ausencia de otros errores.
05
Comprueba lo aprendido
Responde antes de abrir la explicación. Esta comprobación es opcional y no guarda una puntuación.
01¿Una cobertura alta demuestra ausencia de errores?
No. Debes evaluar la calidad de casos y las garantías observadas.
02¿Qué prueba debería fallar si el límite inclusivo se convierte en exclusivo?
Debe fallar el caso de 8 asistentes con capacidad 8. Sobreaforo y grupo vacío siguen rechazados, por lo que no detectan ese cambio de borde.
Cómo demostrar el objetivo
Compara tu práctica con estos resultados. Si solo diseñaste una prueba, registra su resultado como esperado, no como observado.
- La regla acepta 8 de 8 y rechaza 9 y 0.
- El cambio temporal a < hace fallar el caso de aforo exacto y restaurar <= lo recupera.
Qué debes recordar
- Prueba garantías observables y límites.
- Una prueba útil debe detectar un cambio que rompa su requisito.
Tu cuaderno · notas personales
Cuaderno local
Tus notas del contenido
Se guardan únicamente en este dispositivo. Puedes exportarlas cuando quieras.
Material de apoyo · descarga, glosario y referencias
Explicaciones, ejemplos y prácticas propios de Academia de Software. Los fragmentos de integración requieren las dependencias indicadas; el ZIP contiene el núcleo de consola. Las lecturas externas se consultan en su sitio original y conservan sus condiciones. Procedencia y condiciones de uso.