El backend testing es la práctica de probar APIs, bases de datos y la lógica que ocurre detrás de una aplicación web. Si trabajas en QA o desarrollo y quieres asegurar que tu sistema responde bien antes de llegar al usuario, dominar este tipo de pruebas te da control sobre la capa más crítica del software.

Antes de probar cualquier cosa, necesitas entender los bloques que componen un backend: los verbos HTTP, las APIs y las bases de datos. Vamos por partes.

Qué son los verbos HTTP y para qué sirven

Los verbos HTTP son acciones que ejecutas sobre un recurso en la web. Cada uno tiene un propósito específico y reconocerlos te ahorra confusiones cuando empiezas a probar endpoints [00:25].

• GET: obtiene información de un recurso.
• POST: crea un nuevo registro.
• PUT: modifica todas las propiedades de un objeto.
• PATCH: modifica solo ciertas partes del objeto.
• DELETE: elimina un registro.

¿Cuál es la diferencia entre PUT y PATCH? PUT reemplaza todo el objeto con la información que envías. PATCH solo actualiza los campos específicos que mandas, dejando el resto intacto.

Qué es una API y qué tipos existen

Una API (Application Public Interface) es la interfaz que comunica tu backend o base de datos con un frontend u otras aplicaciones externas [01:18]. Sin ella, los sistemas no podrían hablarse entre sí.

Existen dos estándares principales que vas a encontrar en la industria:

• SOAP: el estándar más antiguo, devuelve respuestas en formato XML.
• REST: la norma actual, trabaja con JSON (JavaScript Object Notation) y es lo que vas a ver en la mayoría de proyectos modernos.

Y dónde entra GraphQL en todo esto

GraphQL no es un formato alternativo a REST, trabaja sobre REST y lo potencia [02:08]. Usa únicamente el verbo POST, pero te permite pedir exactamente la información que necesitas en una sola consulta.

Imagina un sistema de hoteles. Con una API REST tradicional, tendrías que llamar a un endpoint para los hoteles, otro para los usuarios y otro para las habitaciones. Después, en el frontend, mezclas todo. Ese exceso de datos que pides y no usas se conoce como overfetching.

GraphQL elimina ese problema porque recibe queries personalizadas y devuelve solo lo que pediste. Si solo quieres el nombre de un usuario, eso es lo que recibes.

¿Qué es el overfetching? Es cuando tu API te devuelve más información de la que realmente necesitas, obligándote a filtrar o ignorar datos en el frontend. GraphQL lo resuelve dejándote pedir solo los campos específicos que vas a usar.

Qué bases de datos entran en el backend testing

Probar el backend también implica validar las bases de datos donde vive la información [03:15]. Aquí encontrarás dos grandes familias:

• Relacionales: MySQL y PostgreSQL, que organizan datos en tablas con relaciones definidas.
• No relacionales: MongoDB, que guarda documentos en formato flexible parecido a JSON.

Dependiendo del proyecto, vas a necesitar saber consultar y validar datos en cualquiera de estos motores.

Qué cubre realmente el backend testing

Cuando hablamos de backend testing, nos referimos a probar de forma integrada todo lo que sucede detrás del telón: los endpoints de las APIs, las respuestas que devuelven, los datos que se guardan en la base de datos y la lógica que conecta cada pieza.

No es solo verificar que un endpoint responda con un 200. Es asegurar que la información viaja correcta, se guarda donde debe y se puede recuperar sin pérdidas. Por eso necesitas familiarizarte con verbos HTTP, formatos de API, GraphQL y bases de datos antes de escribir tu primera prueba.

¿Qué se prueba en el backend testing? Se prueban las APIs (REST, SOAP o GraphQL), las respuestas que devuelven, las bases de datos relacionales y no relacionales, y la integración entre todos estos componentes.

En la siguiente clase vas a ver qué herramientas te da el navegador para trabajar directamente con APIs y cómo sacarles más provecho. ¿Qué concepto de los que vimos te gustaría que se explicara con más profundidad? Déjalo en los comentarios.