CAPÍTULO 6 · Los datos empiezan a llegar
La confianza tiene que sobrevivir al próximo cambio
Probar una pantalla manualmente nos permite conocer una parte del comportamiento, pero no alcanza para recordar todas las reglas del proyecto. Un cambio en la base genérica afecta varios consumidores; un ajuste de permisos puede alterar una API que no abrimos durante la revisión. La base replicable necesita una memoria verificable de lo que promete.
Escribimos pruebas sobre resultados relevantes: solicitudes válidas e inválidas, operaciones permitidas y denegadas, cambios completos y reintentos. La intención no es reproducir cada línea de implementación en otro archivo. Queremos descubrir cuándo una modificación rompe un contrato que otras piezas o personas utilizan.
Con esas comprobaciones podemos avanzar con una confianza mejor fundada. El recorrido local ya explica cómo se construye el comportamiento. Ahora debemos relacionarlo con la organización que alojará usuarios y recursos. La identidad externa que introdujimos antes necesita configurarse para que las pruebas del equipo y el uso real tengan límites claros.
Leer esta parte dentro del relato completo →DEL RELATO A LA PRÁCTICA
Vamos a desarrollar esta decisión con su mapa, explicación, código y ejercicio.
MIRA · CONECTA · COMPRENDE
Una prueba observa comportamiento
Las flechas resumen el recorrido conceptual. Los controles y dependencias se detallan debajo.
Selecciona una pieza para destacar su responsabilidad.
Leer la explicación del mapa
- Escenario. Define estado y objetivo
- Acción. Ejecuta comportamiento real
- Resultado. Comprueba efecto esperado
- Caso negativo. Verifica que lo inválido falle
01 / EL PROBLEMA
¿Para qué sirve?
Una prueba valiosa falla cuando se rompe algo que el usuario o el negocio necesita. Repetir la implementación en una prueba no demuestra corrección.
02 / COMPRENDER
El concepto, explicado
Prueba funciones puras con referencias; servicios con integridad; APIs con identidades y payloads; y frontend con interacciones relevantes.
Las condiciones límite importan: cero, ausencia, fechas repetidas, entradas inválidas y dos peticiones simultáneas. Algunas carreras necesitan PostgreSQL real, no solo SQLite.
03 / CONSTRUIR
Implementación paso a paso
- Enumera los riesgos por caso de uso.
- Prueba un caso válido y uno inválido.
- Verifica que denegaciones no escriben.
- Mantén fixtures pequeños pero representativos.
04 / APLICAR
Ejemplo en SensorHub
from django.test import TestCase
from UTIL_LIB.conversiones import celsius_a_fahrenheit
class ConversionTests(TestCase):
def test_reference_points(self):
for celsius, fahrenheit in [(0, 32), (100, 212), (-40, -40)]:
with self.subTest(celsius=celsius):
self.assertEqual(celsius_a_fahrenheit(celsius), fahrenheit)
# Ejecutar:
# python manage.py testCómo leer el ejemplo
- Las referencias son independientes de la fórmula interna.
- subTest muestra qué entrada falló.
- Las pruebas de permisos deben usar la clase compuesta o endpoint real.
Error habitual
SQLite no reproduce select_for_update de PostgreSQL. No concluyas que una carrera de producción está resuelta por una prueba local serial.
05 / PRACTICAR
Tu turno
Prueba la creación repetida de una lectura y el alcance de un operador.
Ver solución orientativa
Comprueba una sola fila para la misma clave; verifica que una estación ajena no aparece en la lista ni en una consulta por ID.
06 / VERIFICAR
Cómo sabes que funciona
- Las pruebas comprueban resultados y ausencia de efectos indebidos.
- Una regresión importante hace fallar al menos una prueba.
CONTINUAR LA EXPERIENCIA
El siguiente paso del recorrido:
Identidades separadas para DEV y PROD →Continuar en modo relato