Alvaro Alvarez
Siempre que se van a ejecutar las pruebas o ejecutar la aplicación hay que correr el servidor de mongo con la version instancia utilizando el manejador m? hay forma de dejarlo como demonio utilizando el manejador de versiones?
Luis Lira
Normalmente lo que se hace en general para pruebas unitarias es crear un mock de la base de datos y esto varía mucho según el lenguaje y paquetería que uses. Si son pruebas unitarias estas no deberías estar afectando la base de datos.
Johan Tique
ProfesorHola Alvaro, esta es una pregunta interesante por lo que está detrás de la respuesta que te voy a dar, la respuesta directa es que con m si puedes dejar corriendo un proceso en background porque finalmente lo que m hace es descargar de forma ordenada y estructurada los binarios de cada versión (incluyendo el comando mongod), ahora bien, dependiendo de cada sistema operativo vas a poder configurar un proceso en background (o como tú lo llamas daemon), ten en cuenta que un proceso de servidor necesita un puerto, un ruta para los logs y en el caso de mongod una ruta para almacenar los datos como lo vímos en las primeras clases. a través del comando mongod puedes invocarlo con la opción --fork como lo explica aquí
Si también quisieras que el daemon se active de forma automática al iniciar el sistema, deberás consultar de qué forma tu sistema operativo lo hace. por ejemplo en Ubuntu esto lo puedes conseguir usando Linux services con systemd . Te diría que para desarrollo y pruebas esto no debería ser necesario.
Ahora bien, ¿por qué usamos una DB para pruebas?
Primero, porque Rails y Rspec nos permiten hacerlo con facilidad, la gestión de ambientes de desarrollo en Rails, ya contempla uno llamada Test que nos permitirá hacer configuraciones especiales para el escenario de pruebas.
Segundo, Rspec de la mano de FactoryBot te permite trabajar con Fixtures que son estructuras prediseñadas y configurables de información que te premitirán hacer tus pruebas más orientadas a la realidad del negocio.
Tercero, las pruebas y conexiones a DB durante el Testing pueden ser paralelizadas, y en el caso de ActiveRecord están corren por defecto en una transacción de base de datos.
Cuarto, al poder interactuar con modelos de información, podemos construir durante la misma prueba un reflejo claro de las relaciones de información y su interacción en una secuencia específica.
Quinto, es considerablemente más simple, si tenemos en cuenta la complejidad que tendríamos al tener que sólo para las pruebas generar interfaces robustas que respondan a los métodos de base de datos.
Debo mencionarte que habrá ocasiones en las que no necesites usar una conexión a base de datos, esto lo puedes lograr aplicando diversas técnicas, una de ellas el Test Doubles que vemos en la clase 27, esto dependerá del estilo, propósito y el diseño de pruebas que estés aplicando.
Finalmente, la introducción de pruebas dependientes de la DB pueden impactar el tiempo de duración de la suite completa, sin embargo, como menciono en el punto tercero, siempre pueden ser paralelizadas u optimizadas, así que esto no sería un problema.
