Testing

LR #1 Mar '23 Penitente

Estoy dandole al tema testing que no le habia dedicado apenas tiempo. Unitarios, e2e y demas.

Estoy haciendo varias pruebas pero tengo un problema.

Tengo documentos relacionados en la bbdd, y no se como habria que hacerlo para usar los ids que genera mongo para los test crud.

Al principio probe que todo fuera bien de forma aislada, pero cuando meti las relaciones, obviamente, se me ha ido una parte de los tests al carajo porque ahora si que comprueba que las ids sean validas y demas.

Algun consejo de por donde tirar o que hacer ahora mismo?

Kaledros #2 Mar '23

los ids que genera mongo
— LR:1

cuando meti las relaciones
— LR:1

Algo no me cuadra aquí. Por lo demás, nunca deberías usar las id autogeneradas por ninguna DB, usa los id que tu sistema asigna a una entidad que vayas a persistir.

1 respuesta

LR #3 Mar '23 Penitente

#2 tengo 3 modelos que se relacionan entre si. Hice un intento de tdd asi que todo iba funcionando bien hasta que termine de meter las relaciones y comprobaciones.

Si tengo modelos A B C, al crear C, tiene que ir asignado a A y B, si borro C tiene que borrar de B, B no se puede borrar si hay C y cosas asi.

Al hacer un reset de la bbdd antes del os tests, me genera un nuevo id en cada test como es normal. No se como hacer de forma "facil" para pillarl os ids sin tener que hacer varias consultas antes de empezar y asi tener al menos un par de ids pilladas para que todo el sistema empiece a funcionar.

Lo de los Ids es por algo en concreto? Pensaba que el sistema de mongo iba relativamente bien.

2 respuestas

r2d2rigo #4 Mar '23 Inocente

#3 pero tu estas testeando tu capa CRUD o la base de datos? Fakea todo el acceso a datos hombre.

2 1 respuesta

squ4r3 #5 Mar '23

haz un objeto en memoria que simule la respuesta que quieres obtener de tu bbdd y ya está, no? Mucho más fácil. Si no, cada vez que quieras testear tienes que hacerlo contra una bbdd de verdad?

2 1 respuesta

Wei-Yu #6 Mar '23

#3 en los unitarios mockea el acceso a datos, en los e2e ten fases de clean up después de hacer requests http normales a la api

si lo que quieres es testear cosas que hay detrás de ese hipotético mock (testear la capa de datos, vaya) mira a ver si puedes mover la lógica fuera de la capa de datos, aunque te suponga alguna llamada extraa la db; las llamadas extra probablemente sean sobre índices y sea una carga ínfima tanto en latencia como de recursos en db

1 respuesta

LR #7 Mar '23 Penitente

#5 tengo una para test a la que le meto antes de los tests 2 o 3 registros para probar.

#4 Es como lo tenia, primero lo tenia todo falseado con la estructura de los modelos. He ido metiendo codigo para ir haciendo las relaciones y ahora obviamente los ids no los puedo ya falsear si quiero testearlo en bbdd.

#6 Es lo que tenia pensado si no encontraba otra forma, hacer varias llamadas extra para sacar las ids que ya estan en la bbdd y tirar desde ahi

desu #8 Mar '23

En que lenguaje y que db usas?

1 respuesta

Kaledros #9 Mar '23

He ido metiendo codigo para ir haciendo las relaciones y ahora obviamente los ids no los puedo ya falsear si quiero testearlo en bbdd.
— LR:7

Te estás liando. Estás usando los id que te autogenera el motor para relacionar las entidades y, como es normal, no te van a coincidir en la vida porque se regeneran con cada insert. Pero es que esos id no se usan nunca, se usan los que tú generas al crear el objeto. Y si te interesa saber cuales son, es muy sencillo: o haces un SELECT como te han dicho, o los generas aparte (en un generador online o lo que sea) y los hardcodeas. Luego buscas por esos id y ya.

1 respuesta

LR #10 Mar '23 Penitente

#8 js y mongo

#9 Ya ya, al final es lo que hare. Lo que si tengo la duda de lo que te puse antes. Lo de los ids, por que no usar los que te crea el propio motor con cada insert si en teoria son unicos? Entiendo que por controlar/predecir los proximos ids, pero si no es por eso, por que?

2 respuestas

desu #11 Mar '23

#10 es express? y para testear que estas usando? jest?

voy a intentar hacerte un hello world de CRUD + test a mongo con tu stack

yo hoy estaba practicando cypress, pero eso es para e2e frontend XD

1 respuesta

Kaledros #12 Mar '23

#10 Esos ObjectId funcionan como clave primaria interna del objeto, sí. Se lo puedes asignar tú y si no se lo asignas Mongo lo autogenera. Puedes usarlo como clave primaria, pero lo normal es asignar un UUID o similar porque un ObjectId es un objeto y puede ser engorroso de manipular mientras que a un UUID le haces un toString() y puedes usar los métodos de la librería sin problemas (compare, etc).

1 respuesta

LR #13 Mar '23 Penitente

#11 si, estoy con express y jest.

Cypress tenía pensado echarle un ojo más adelante cuando tenga el front hecho.

#12 vale, me queda más claro ahora, thx

1 respuesta

desu #14 Mar '23

#13 cuel es el objetivo de tu aplicacion? cual es el caso de uso que estas tratando de resolver?

que endpoints tiene tu crud? dime uno o dos.

1 respuesta

LR #15 Mar '23 Penitente

#14 crear listas donde añadir regalos y que la gente que esté suscrita a cada lista pueda decidir que regalos compra. Luego gestiona el tema quién paga que a quien y demás mierdas.

Testing

Usuarios habituales

Tags