El desarrollo del frontend a menudo empieza antes de que el backend esté listo para servir datos reales. En vez de esperar a tener una API funcional, se pueden generar datos JSON de prueba realistas con la forma adecuada y empezar a trabajar de inmediato.
Qué son los datos de prueba
Un JSON «mock» son datos generados pero estructuralmente verosímiles: nombres que parecen nombres reales, fechas en el formato correcto, identificadores con el aspecto que deberían tener. A diferencia de valores de relleno como "test123", los mocks realistas muestran enseguida si la interfaz maneja bien nombres largos, campos vacíos o formatos de fecha concretos.
Para qué sirve
- Empezar a construir la interfaz antes de que el equipo de backend termine la API.
- Probar cómo se comporta la interfaz con muchos registros, sin necesidad de llenar una base de datos real.
- Crear una demo o un prototipo sin exponer datos reales de usuarios.
- Escribir pruebas automatizadas que no dependan del estado de un servicio externo o de una base de datos.
El nombre completo hispano no cabe en «firstName» + «lastName»
Un generador de mocks pensado para el formato anglosajón produce un solo apellido por persona, pero la convención hispanohablante habitual usa dos: apellido paterno y apellido materno (por ejemplo, «García Fernández»). Un campo {{lastName}} que solo genera una palabra da un dato con forma plausible en inglés, pero que un usuario de España o Latinoamérica reconoce de inmediato como incompleto si la interfaz muestra el nombre completo en un formulario o factura.
A qué prestar atención
Los datos de prueba reproducen bien la forma y los tipos de los datos reales, pero no la lógica de negocio ni las relaciones entre registros. Antes de pasar a producción, el código sigue necesitando probarse contra una API real; los mocks solo aceleran las primeras etapas del desarrollo.
Edge cases realistas en los mocks
Un buen generador de mocks incluye deliberadamente valores «incómodos» — nombres muy largos, cadenas vacías, caracteres Unicode (incluidas tildes y la letra «ñ»), números nulos o negativos, fechas en el límite del rango. Precisamente esos valores son los que más a menudo rompen la interfaz o la lógica que un desarrollador solo probó con datos «cómodos» como "John Doe" — por eso la aleatoriedad de los mocks es más útil que usar siempre el mismo ejemplo de prueba.