¿Cómo gestionas los datos de prueba para que los tests sigan siendo fiables entre ejecuciones y entornos?

Haz que cada test cree los datos que necesita y limpie después, con identificadores únicos para que las ejecuciones en paralelo no puedan chocar. Prefiere construir los datos por la API o con factorías antes que una base de datos sembrada y compartida, porque los fixtures compartidos se pudren y crean acoplamiento oculto entre tests. Nunca dependas de datos que alguien cargó a mano, y nunca te apoyes en datos de producción sin enmascarar que contengan información personal.

El objetivo es que cualquier test pueda ejecutarse solo, en cualquier orden, en paralelo con los demás, y aun así pase. Eso descarta un conjunto de datos sembrado y compartido, que siempre empieza ordenado y a los dos meses es un pantano porque nadie sabe qué test depende de qué fila. Así que cada test construye lo que necesita, idealmente con llamadas a la API o un helper de factoría en vez de por la interfaz, lo que es más rápido y mucho menos frágil. Cada registro lleva un identificador único, normalmente un ID de ejecución más una marca de tiempo en el email o en el nombre, para que diez workers en paralelo no se peleen por la misma cuenta. La limpieza va en el teardown, pero diseño de forma que los datos que queden sean inofensivos, en vez de asumir que la limpieza siempre se ejecuta, porque no lo hará cuando un test reviente. Así que también hay un job programado que borra todo lo que tenga más de un día y encaje con el patrón de nombres de test. Con los datos de producción me planto con firmeza ante las copias sin enmascarar. Si necesitamos volumen y forma realistas, los quiero generados o bien anonimizados, porque un entorno de pruebas lleno de registros reales de clientes es una brecha esperando a pasar y suele tener controles de acceso más flojos que producción.