Pruebas Automaticas de Software - dcmendoza/Domus GitHub Wiki
Tests Realizados para la Aplicación
Este documento recoge la estrategia, organización y detalles de los tests implementados para la API Django de Domus.
1. Visión general
La API de Domus cuenta con varias capas críticas:
- Modelos: validaciones de negocio (
clean()
), métodos especiales (approve()
,reject()
) y representaciones (__str__
). - Serializadores: validaciones de datos y creación de instancias.
- Autenticación: backend personalizado para autenticar usuarios por email.
- ViewSets: lógica de permisos y endpoints personalizados (
approve
,review
). - Flujos completos: signup → aprobación de usuario → autenticación → creación y revisión de reservas.
Para garantizar la estabilidad y detectar regresiones, se han creado pruebas de distintos niveles:
- Pruebas unitarias: verifican componentes aislados (modelos, serializadores, backend).
- Pruebas de integración: validan la interacción de ViewSets con permisos y paginación.
- Pruebas end-to-end: cubren un flujo de negocio completo a través de varios endpoints.
2. Requisitos y configuración
-
Django ≥ 5.1
-
djangorestframework
-
Entorno virtual con dependencias instaladas:
pip install -r requirements.txt
Nota: Asegúrate de tener un backend de email en memoria para tests en
settings.py
(solo durante tests):
# settings.py (solo para tests)
EMAIL_BACKEND = 'django.core.mail.backends.locmem.EmailBackend'
3. Estructura de directorios de tests
api/
└── tests/
├── __init__.py
├── test_models.py
├── test_serializers.py
├── test_backends.py
├── test_views.py
└── test_end_to_end.py
- Cada archivo contiene casos de prueba agrupados por capa o tipo.
- Los nombres comienzan con
test_
para que Django y pytest los detecten automáticamente.
4. Cómo ejecutar los tests
Desde la raíz del proyecto:
# Usando el runner de Django
python manage.py test api/tests
# O con pytest (si está instalado)
pytest api/tests
Todos los tests deben pasar con salida “OK” o similar, sin errores ni fallos.
5. Descripción de cada archivo de test
test_models.py
5.1 Pruebas unitarias sobre los modelos:
-
ShiftAssignment
- Rango de fechas inválido
- Turnos solapados
-
Reservation
- Representación en texto (
__str__
) - Validación de solapamiento
- Representación en texto (
-
LeaveRequest
approve()
borra turnos y envía correo
test_serializers.py
5.2 Pruebas unitarias sobre serializadores:
-
ReservationSerializer
- Fechas válidas → instancia creada con estado
'pendiente'
- Fechas inválidas → error de validación
- Fechas válidas → instancia creada con estado
-
UserSerializer
- Empleado sin
subrole
→ error - Auto-signup con rol
admin
→ error
- Empleado sin
test_backends.py
5.3 Pruebas unitarias del backend de autenticación:
-
EmailBackend.authenticate()
- Login exitoso por email
- Rechazo de credenciales incorrectas
test_views.py
5.4 Pruebas de integración de ViewSets:
-
FacilityViewSet
- Listado paginado accesible a usuarios autenticados
- Creación permitida solo a staff (
is_staff=True
) - Prohibición (403) para no-staff
-
UserViewSet
- Signup público (
POST /users/
) - Endpoint
GET /users/me/
- Signup público (
test_end_to_end.py
5.5 Pruebas end-to-end que cubren un flujo completo:
- Registro de un empleado nuevo
- Aprobación de ese usuario por un admin
- Login y obtención de token
- Creación de una reserva por parte del empleado
- Revisión (aprobación) de la reserva por el admin
- Consulta de la reserva para verificar estado final
6. Resumen de pruebas
Archivo | Test | Descripción | Tipo |
---|---|---|---|
test_models.py | test_shift_invalid_date_range |
Verifica que ShiftAssignment.clean() rechace un turno cuyo start_datetime ≥ end_datetime . |
Unitario |
test_shift_overlapping |
Comprueba que clean() de ShiftAssignment lance ValidationError si un turno solapa con otro existente. |
Unitario | |
test_reservation_str_and_overlap |
- Comprueba Reservation.__str__() - Verifica que clean() impida reservas solapadas. |
Unitario | |
test_leave_request_approve_removes_shifts_and_sends_email |
- Al aprobar, elimina turnos relacionados y envía un correo. | Unitario | |
test_serializers.py | test_reservation_serializer_valid |
Verifica creación de reserva válida con estado 'pendiente' . |
Unitario |
test_reservation_serializer_invalid_dates |
Asegura que fechas inválidas produzcan error de serialización. | Unitario | |
test_user_serializer_employee_requires_subrole |
Garantiza error al registrar empleado sin subrole . |
Unitario | |
test_user_serializer_forbid_admin_signup |
Comprueba que un signup público no pueda usar rol admin . |
Unitario | |
test_backends.py | test_authenticate_by_email |
- Login exitoso usando email- Fallo con contraseña incorrecta. | Unitario |
test_views.py | test_facility_list_authenticated |
GET /facilities/ retorna estructura paginada con results para usuario autenticado. |
Integración |
test_facility_create_by_admin |
POST a /facilities/ crea instalación (201) solo si is_staff=True . |
Integración | |
test_facility_create_forbidden_to_non_admin |
Asegura 403 al intentar crear sin ser staff. | Integración | |
test_user_signup |
POST /users/ crea nuevo usuario en estado pendiente (201). |
Integración | |
test_me_endpoint |
GET /users/me/ devuelve datos del usuario autenticado. |
Integración | |
test_end_to_end.py | test_full_user_flow_reservation_review |
Flujo completo:1) Signup de empleado2) Admin aprueba usuario3) Login y token4) Crear reserva5) Admin aprueba reserva6) Verificar estado final | End-to-End |