Tests de API con APIClient en Django

Contenido del curso

Fundamentos de Django Rest Framework

Vistas y Endpoints

Serializadores Avanzados

Testing y Desempeño

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:0012:18

Tests de API con APIClient en Django

Curso de Django Rest Framework

Clase 20 de 21

Clase 20 / 21

Recursos

Probar tu API antes de mandarla a producción te ahorra horas de debugging y te protege de regresiones silenciosas. Con Django Rest Framework puedes escribir unit tests en Django usando la clase APIClient, que simula requests reales contra tus endpoints sin levantar un servidor.

Esta guía te muestra cómo estructurar pruebas para un viewset, validar códigos de respuesta y detectar bugs de permisos antes de que lleguen a tus usuarios.

Cómo se configura un test case en Django Rest Framework

Todo arranca en el archivo tests.py que Django genera automáticamente en cada aplicación. Ahí ya viene importada la clase TestCase, de la cual heredas para acceder a las utilidades de pruebas del framework.

La estructura básica empieza con una clase nombrada según lo que vas a validar. Si pruebas un viewset de appointments, una buena convención es AppointmentViewsetTest(TestCase). Dentro defines un método setUp, que se ejecuta antes de cada prueba y te permite reutilizar datos.

¿Para qué sirve el método setUp en un TestCase? Para crear datos que se usan en todas las pruebas de la clase, como un paciente o un doctor. Se ejecuta antes de cada test y evita repetir código.

Cómo crear datos de prueba con el ORM

Dentro de setUp aprovechas el ORM de Django para crear objetos directamente en la base de datos de pruebas. En el ejemplo se crean dos modelos:

Un paciente con nombre Luis Martínez, fecha de nacimiento 1990-12-05, contacto, email y dirección.
Un doctor con nombre Óscar Barajas, especialidad profesional, email, dirección Medellín y vacation=False.
Un cliente de pruebas instanciado como self.client = APIClient().

El APIClient se importa con from rest_framework.test import APIClient y trae configuraciones predeterminadas, como tratar todo el contenido como JSON. Eso te ahorra definir headers manualmente en cada request [03:30].

Cómo escribir un test que valide un endpoint

Un test es un método dentro de la clase cuyo nombre empieza con test_. La convención recomendada describe la expectativa, por ejemplo test_list_should_return_200. Dentro del método arma la URL, ejecuta el request y compara el resultado.

Para construir URLs sin hardcodearlas se usa reverse, importado con from django.urls import reverse. Esta función traduce el nombre de una URL a su path real, así que si cambias la ruta en urls.py, tus tests siguen funcionando.

¿Qué hace reverse en Django? Convierte el nombre de una URL en su path completo. Si la URL recibe parámetros, los pasas como diccionario en kwargs, por ejemplo reverse('appointments-list', kwargs={'pk': doctor.id}).

Cómo descubrir los nombres de tus URLs

Para conocer los nombres registrados de tus rutas existe una herramienta muy útil: la extensión django-extensions. La instalas con:

bash pip install django-extensions

Después la agregas a INSTALLED_APPS en settings.py como django_extensions (con guion bajo, no guion medio). Eso habilita el comando python manage.py show_urls, que lista todas las rutas del proyecto junto con su nombre y los parámetros que reciben [05:50].

Cómo validar el response con assertEqual

Una vez tienes la URL, simulas el request con el cliente:

python response = self.client.get(url) self.assertEqual(response.status_code, status.HTTP_200_OK)

El método assertEqual compara dos valores y falla la prueba si no coinciden. Para los códigos HTTP conviene importar from rest_framework import status y usar constantes legibles como status.HTTP_200_OK o status.HTTP_403_FORBIDDEN en lugar de números sueltos.

Por qué los tests unitarios detectan bugs de permisos

Al correr la prueba con python manage.py test, el primer resultado fue un fallo: el endpoint devolvía 403 Forbidden en vez de 200 OK. Lejos de ser un problema, ese error reveló un bug real en la configuración de permisos del viewset.

El código tenía una combinación de IsAuthenticatedOrReadOnly con un permiso personalizado IsDoctor, pero la lógica no estaba dejando pasar peticiones sin autenticación como debería. La prueba expuso que el comportamiento esperado y el real no coincidían.

La solución fue ajustar los permisos a IsAuthenticated combinado con IsDoctor, dejando claro que solo doctores autenticados pueden acceder. Después de ese cambio, la prueba se actualizó para esperar 403 cuando el usuario no está autenticado, y pasó exitosamente [09:40].

Qué te enseña este flujo sobre testing

Este pequeño ejercicio resume tres beneficios concretos de las pruebas unitarias:

Validan contratos: confirman que cada endpoint responde con el código y el formato que prometes.
Detectan regresiones: si alguien rompe la lógica de permisos, el test falla antes de que el bug llegue a producción.
Documentan comportamiento: leer los tests es leer las reglas del negocio sin abrir la documentación.

El APIClient de Django Rest Framework es la pieza central porque te deja simular cualquier verbo HTTP (GET, POST, PUT, DELETE) sin levantar el servidor ni configurar herramientas externas. Combinado con setUp, reverse y las constantes de status, tienes todo para cubrir tu API con pruebas rápidas y mantenibles.

¿Qué endpoint vas a cubrir primero con tests? Cuéntame en los comentarios qué parte de tu API te genera más dudas al momento de probarla.

Mario Alexander Vargas Celis

Hace 2 años

Para realizar pruebas unitarias de **endpoints anidados** usando APIClient en Django REST Framework, puedes simular las solicitudes HTTP a tus endpoints dentro de un contexto de prueba. Aquí te explico cómo hacerlo paso a paso.

### 1. **Escenario: Endpoints Anidados**

Supongamos que tienes un endpoint de **doctores** y uno de **pacientes** anidado bajo los doctores. Un ejemplo de URLs anidadas podría ser algo como:

- /api/doctors/ → Lista de doctores.

- /api/doctors/{doctor\_id}/patients/ → Lista de pacientes para un doctor en particular.

### 2. **Configuración de las Pruebas**

Primero, asegúrate de tener configurado tu APIClient y tus modelos.

#### Modelos

Si tienes los siguientes modelos:


\# models.py

from django.db import models



class Doctor(models.Model):

&#x20;   name = models.CharField(max\_length=100)

&#x20;   specialization = models.CharField(max\_length=100)



class Patient(models.Model):

&#x20;   name = models.CharField(max\_length=100)

&#x20;   doctor = models.ForeignKey(Doctor, related\_name='patients', on\_delete=models.CASCADE)

#### Serializers

Los serializers podrían verse así:


\# serializers.py

from rest\_framework import serializers

from .models import Doctor, Patient



class PatientSerializer(serializers.ModelSerializer):

&#x20;   class Meta:

&#x20;       model = Patient

&#x20;       fields = \['id', 'name']



class DoctorSerializer(serializers.ModelSerializer):

&#x20;   patients = PatientSerializer(many=True, read\_only=True)



&#x20;   class Meta:

&#x20;       model = Doctor

&#x20;       fields = \['id', 'name', 'specialization', 'patients']

#### ViewSets

Las vistas para los endpoints anidados:


\# views.py

from rest\_framework import viewsets

from .models import Doctor, Patient

from .serializers import DoctorSerializer, PatientSerializer



class DoctorViewSet(viewsets.ModelViewSet):

&#x20;   queryset = Doctor.objects.all()

&#x20;   serializer\_class = DoctorSerializer



class PatientViewSet(viewsets.ModelViewSet):

&#x20;   serializer\_class = PatientSerializer



&#x20;   def get\_queryset(self):

&#x20;       return Patient.objects.filter(doctor\_id=self.kwargs\['doctor\_pk'])

Y en el archivo de **urls.py**:


from rest\_framework.routers import DefaultRouter

from .views import DoctorViewSet, PatientViewSet



router = DefaultRouter()

router.register(r'doctors', DoctorViewSet)



\# URL anidadas para pacientes de un doctor específico

from rest\_framework\_nested import routers

doctor\_router = routers.NestedSimpleRouter(router, r'doctors', lookup='doctor')

doctor\_router.register(r'patients', PatientViewSet, basename='doctor-patients')



urlpatterns = router.urls + doctor\_router.urls

### 3. **Prueba de Endpoints Anidados**

Para realizar una prueba unitaria sobre los endpoints anidados usando APIClient, sigue los pasos siguientes:

#### Crear el archivo de pruebas


\# tests.py

from rest\_framework.test import APITestCase, APIClient

from django.urls import reverse

from rest\_framework import status

from .models import Doctor, Patient



class DoctorPatientAPITests(APITestCase):

&#x20;   def setUp(self):

&#x20;       self.client = APIClient()

&#x20;      &#x20;

&#x20;       \# Crear un doctor y pacientes

&#x20;       self.doctor = Doctor.objects.create(name="Dr. Smith", specialization="Cardiology")

&#x20;       self.patient1 = Patient.objects.create(name="John Doe", doctor=self.doctor)

&#x20;       self.patient2 = Patient.objects.create(name="Jane Doe", doctor=self.doctor)

&#x20;      &#x20;

&#x20;       \# URL para obtener la lista de pacientes de un doctor específico

&#x20;       self.patients\_url = reverse('doctor-patients-list', kwargs={'doctor\_pk': self.doctor.id})



&#x20;   def test\_get\_patients\_for\_doctor(self):

&#x20;       """Prueba para obtener la lista de pacientes de un doctor específico"""

&#x20;      &#x20;

&#x20;       \# Simular una solicitud GET al endpoint de pacientes

&#x20;       response = self.client.get(self.patients\_url)

&#x20;      &#x20;

&#x20;       \# Comprobar que la respuesta tenga código 200 (éxito)

&#x20;       self.assertEqual(response.status\_code, status.HTTP\_200\_OK)

&#x20;      &#x20;

&#x20;       \# Verificar que los pacientes se devuelvan correctamente en la respuesta

&#x20;       self.assertEqual(len(response.data), 2)

&#x20;       self.assertEqual(response.data\[0]\['name'], self.patient1.name)

&#x20;       self.assertEqual(response.data\[1]\['name'], self.patient2.name)



&#x20;   def test\_create\_patient\_for\_doctor(self):

&#x20;       """Prueba para crear un paciente bajo un doctor específico"""

&#x20;      &#x20;

&#x20;       \# Datos para el nuevo paciente

&#x20;       data = {

&#x20;           'name': 'Tom Doe'

&#x20;       }

&#x20;      &#x20;

&#x20;       \# Simular una solicitud POST al endpoint de pacientes

&#x20;       response = self.client.post(self.patients\_url, data, format='json')

&#x20;      &#x20;

&#x20;       \# Comprobar que la respuesta tenga código 201 (creado)

&#x20;       self.assertEqual(response.status\_code, status.HTTP\_201\_CREATED)

&#x20;      &#x20;

&#x20;       \# Verificar que el paciente fue creado correctamente y asociado al doctor

&#x20;       self.assertEqual(Patient.objects.filter(doctor=self.doctor).count(), 3)

&#x20;       self.assertEqual(response.data\['name'], 'Tom Doe')

### Explicación de la Prueba

1. **setUp**: Configuramos el cliente de la API (APIClient), creamos un Doctor y dos Patient. También generamos la URL de los pacientes anidados bajo un doctor específico.

2. **test\_get\_patients\_for\_doctor**:

- Enviamos una solicitud GET al endpoint anidado /doctors/{doctor\_id}/patients/.

- Verificamos que la respuesta tenga código de estado 200 OK.

- Comprobamos que se devuelvan los pacientes correctos en la respuesta.

3. **test\_create\_patient\_for\_doctor**:

- Enviamos una solicitud POST para crear un nuevo paciente bajo el doctor.

- Verificamos que el código de estado sea 201 CREATED.

- Comprobamos que el paciente fue correctamente añadido a la base de datos y asociado al doctor.

### 4. **Ejecutar las pruebas**

Para ejecutar las pruebas, utiliza el siguiente comando en la terminal:


python manage.py test

Esto ejecutará las pruebas en tu proyecto y validará que los endpoints anidados funcionen correctamente.

Fundamentos de Django Rest Framework

Django REST Framework para APIs escalables

Qué es una API REST y cómo usar JSON

Configuración de Django REST Framework paso a paso

Django Rest: qué reutiliza de Django

Serializers Django: modelos a JSON fácil

Listado de pacientes con serializers en DRF

POST y GET en el mismo endpoint con Django REST

CRUD completo con PUT y DELETE en Django Rest

Cómo probar APIs con Postman y curl

Django Rest Framework: de funciones a vistas genéricas

Vistas genéricas en Django Rest Framework

Documentación automática de APIs con drf-spectacular

Vistas y Endpoints

ViewSets vs APIView: refactor automático de URLs

Acciones personalizadas en ViewSets REST

Autenticación y permisos en Django Rest Framework

Validaciones custom en Django Rest Framework

Serializadores Avanzados

Serializadores anidados en Django REST Framework

Calcular campos dinámicos con SerializerMethodField

Endpoint anidado para citas en Django REST

Testing y Desempeño

Tests de API con APIClient en Django

Throttling en Django Rest para evitar ataques DOS

Tests de API con APIClient en Django

Progreso del curso

Fundamentos de Django Rest Framework

Vistas y Endpoints

Serializadores Avanzados

Testing y Desempeño

Recursos

Recursos