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

5.1 test_models.py

Pruebas unitarias sobre los modelos:

  • ShiftAssignment

    • Rango de fechas inválido
    • Turnos solapados
  • Reservation

    • Representación en texto (__str__)
    • Validación de solapamiento
  • LeaveRequest

    • approve() borra turnos y envía correo

5.2 test_serializers.py

Pruebas unitarias sobre serializadores:

  • ReservationSerializer

    • Fechas válidas → instancia creada con estado 'pendiente'
    • Fechas inválidas → error de validación
  • UserSerializer

    • Empleado sin subrole → error
    • Auto-signup con rol admin → error

5.3 test_backends.py

Pruebas unitarias del backend de autenticación:

  • EmailBackend.authenticate()

    • Login exitoso por email
    • Rechazo de credenciales incorrectas

5.4 test_views.py

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/

5.5 test_end_to_end.py

Pruebas end-to-end que cubren un flujo completo:

  1. Registro de un empleado nuevo
  2. Aprobación de ese usuario por un admin
  3. Login y obtención de token
  4. Creación de una reserva por parte del empleado
  5. Revisión (aprobación) de la reserva por el admin
  6. 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_datetimeend_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

image