DEV Community: Dailos Rafael Díaz Lara

Definiendo nuestras infraestructuras para desarrollo y testing con Docker

Dailos Rafael Díaz Lara — Mon, 28 Dec 2020 16:39:44 +0000

🎯 Objetivo

Cuando estamos creando una nueva aplicación o funcionalidad, normalmente necesitamos enviar peticiones a recursos independientes como pueden ser una base de datos o servicios con comportamiento controlado pero obviamente, realizar estas tareas contra servidores en la nube tiene un coste.

En este tipo de situaciones es cuando el aislamiento de sistemas que nos proporcionan los contenedores de Docker, es realmente útil.

En este artículo vamos a ver cómo podemos usar Docker para levantar una infraestructura mínima que nos permita ejecutar las tareas de desarrollo y/o testing, localmente.

El principal objetivo de este texto es mostrar cómo utilizar un único archivo docker-compose.yml para ambos entornos, empleando diferentes archivos .env para personalizar cada contenedor específico tanto para desarrollo como para testing.

Además, nos centraremos en cómo arrancar un nuevo contenedor para testing, ejecutar los tests que sean pertinentes y finalmente, apagar dicho contenedor.

💻 Configuración del sistema

Si vamos a hablar sobre Docker, es obvio que necesitamos tenerlo instalado en nuestro sistema. Si aún no lo tienes, puedes seguir las indicaciones dadas en la documentación oficial, para el sistema operativo que corresponda.

Otro elemento que vamos a necesitar tener instalado en nuestro sistema es docker-compose. De nuevo, si aún no lo tienes instalado, puedes seguir las indicaciones de la documentación oficial.

Por último, dado que este ejemplo está orientado a aplicaciones basadas en JavaScript/TypeScript, necesitamos tener instalado NodeJS (documentación oficial).

🏗 Inicialización del proyecto

🔥 Si ya tienes inicializando tu propio proyecto basado en NodeJS, puedes saltarte esta sección 🔥

Vamos a inicializar nuestro proyecto NodeJS abriendo una consola de comandos, en el directorio donde queramos trabajar, y escribimos el siguiente comando:

npm init -y

Esta acción nos creará una único archivo package.json en la raíz de nuestro proyecto, con el siguiente contenido:

Ahora podemos instalar Jest ejecutando la siguiente instrucción en nuestra consola de comandos, para incluir esta librería en nuestro proyecto:

npm i -D jest

El siguiente paso es crear la estructura más básica de directorios para el proyecto.

/
|-- /docker # <= Nuevo directorio.
|-- /node_modules
|-- /src # <= Nuevo directorio.
|-- package-lock.json
|-- package.json

🐳 Definiendo la configuración de Docker

Vamos a tener dos entornos principales (development y test) y la idea es tener un único archivo docker-compose.yml para gestionar los contenedores de ambos entornos.

📄 Definición del archivo `docker-compose.yml`

Para conseguir nuestro objetivo, dentro del directorio /docker vamos a crear un único archivo llamado docker-compose.yml, el cual contendrá el siguiente código:

Como podemos apreciar, hay varias líneas marcadas como coupling smell. Esto significa que, con la configuración actual, podemos ejecutar un único contenedor de Docker destinado principalmente para tareas de desarrollo. Por lo tanto, está altamente acoplado a su entorno de ejecución.

¿No sería genial si fuésemos capaces de reemplazar esas configuraciones definidas directamente en el código, por referencias las cuales vinieran establecidas por algún tipo de archivo de configuración?

⚙ Archivos `.env` para contenedores Docker

!Sí! Podemos usar archivos .env de la misma manera que ya los usamos para nuestras aplicaciones, pero para configurar contenedores de Docker.

Lo primero que necesitamos hacer es modificar el archivo docker-compose.yml que acabamos de crear para usar plantillas basadas en llaves, para definir nombres de constantes que reemplazaremos con los valores indicados en nuestros archivos .env. De este modo, el contenido del archivo docker-compose.yml quedará de la siguiente manera:

Como podemos ver, hemos reemplazado los valores directamente escritos en el código por referencias del tipo ${CONSTANT_NAME}. El nombre de las variables escrito entre llaves será el nombre de los valores definidos en nuestros archivos .env. De esta manera, cuando arranquemos el comando docker-compose usando una opción específica de la línea de comandos que veremos más adelante, el contenido del archivo .env será reemplazado en nuestro archivo docker-compose.yml antes de que se cree el contenedor de Docker.

Ahora es el momento de definir nuestros entornos así que modificamos el contenido del directorio /docker para que quede tal que así:

/
|-- /docker
|   |-- /dev # <= Nuevo directorio y archivo.
|   |   |-- .docker.dev.env
|   |-- /test # <= Nuevo directorio y archivo.
|   |   |-- .docker.test.env
|   |-- docker-compose.yml
|-- /node_modules
|-- /src
|-- package-lock.json
|-- package.json

Por cada entorno hemos creado un único subdirectorio: dev y test.

Dentro de cada subdirectorio de entorno hemos creado un archivo .env específico: .docker.dev.env y .docker.test.env.

🙋❓ ¿Sería posible nombrar los archivos de entorno sólo como .env?

Sí, es posible y además, no habría ningún problema en ello pero... un nombre de archivo tan descriptivo es una ayuda para nuestro rol como profesionales del desarrollo. Dado que en un mismo proyecto es muy probable que haya múltiples archivos de configuración, es útil ser capaz de diferenciarlos cuando tenemos varios de ellos abiertos, en el editor de código, al mismo tiempo. Esta es la razón por la que los archivos .env tienen uno nombres tan descriptivos.

Ahora pasaremos a definir el contenido de nuestros archivos de entornos, para que queden de la siguiente manera:

y...

Hay cuatro propiedades a las que debemos prestar atención a la hora de diferenciar entre los dos archivos:

CONTAINER_NAME
EXTERNAL_PORT
VOLUME_NAME
CONFIGURATION_PATH

La propiedad CONTAINER_NAME nos permite definir el nombre del contenedor que veremos después de que éste ha sido creado y además, cuando ejecutamos el comando docker ps -a para listar todos los contenedores presentes en nuestro sistema.

EXTERNAL_PORT es una propiedad realmente sensible ya que nos permite definir el puerto que el contenedor tendrán publicado y a través del cual, nuestra aplicación podrá conectarse con él. Es realmente importante tener cuidado con este parámetro porque algunas veces nos interesará tener levantados ambos entornos al mismo tiempo (development y test), pero si hemos definido el mismo puerto de acceso para ambos contenedores, el sistema nos lanzará un error al lanzar el segundo contenedor, ya que el puerto estará ocupado.

La propiedad VOLUME_NAME definirá el nombre del almacenamiento de datos en nuestro sistema.

Finalmente, en caso de que hayamos definido cualquier tipo de conjunto de datos para inicializar nuestra base de datos antes de usarla, la propiedad CONFIGURATION_PATH nos permitirá definir dónde está ubicado ese conjunto de datos.

🙋‍♀️❓ Oye pero, ¿qué pasa con la propiedad COMPOSE_PROJECT_NAME?

Esa es una magnífica pregunta.

Nuestro primer objetivo es crear un contenedor específico por cada entorno, basándonos en el mismo archivo docker-compose.yml.

Ahora mismo, si ejecutamos nuestro docker-compose para development, por ejemplo, crearemos el contenedor con esa definición de entorno y el archivo docker-compose.yml quedará enlazado a dicho contenedor.

De este modo, si intentamos ahora arrancar el mismo archivo pero utilizando la configuración para testing, el resultado final será que hemos actualizado el contenedor previo de development, sin la configuración para el entorno de testing. ¿Por qué? Pues porque el archivo de composición está enlazado al contenedor que arrancamos inicialmente.

Para conseguir nuestro objetivo satisfactoriamente, empleamos la propiedad COMPOSE_PROJECT_NAME dentro de cada archivo .env y le asignamos valores diferentes dependiendo del entorno al que pertenezca.

De esta manera, cada vez que ejecutemos el archivo de composición, dado que el nombre de proyecto es diferente para cada archivo .env, las modificaciones que se apliquen sólo afectarán al contenedor que corresponda con dicho nombre de proyecto.

🙋❓ Vale, bien, pero hemos usado la propiedad COMPOSE_PROJECT_NAME sólo dentro de nuestros archivos .env y no en el archivo docker-compose.yml. ¿Cómo es posible que afecte al resultado final?

Es posible porque esa propiedad es leída directamente por el comando docker-compose y no es necesario que esté incluida dentro del archivo docker-compose.yml.

En este enlace puedes encontrar toda la documentación oficial about COMPOSE_PROJECT_NAME.

🤹‍♂️ Inicializando la base de datos

🔥 Advertencia: El proceso que se expone a continuación está dirigido a inicializar el contenido de una base de datos MongoDB. Si quieres usar un motor diferente, necesitarás adaptar este proceso así como la configuración del docker-compose.yml para ello. 🔥

El concepto más básico que debemos saber, si es que no lo sabemos ya, es que cuando un contenedor basado en MongoDB se ejecuta por primera vez, todos los archivos con extensión .sh o .js ubicados en el directorio /docker-entrypoint-initdb.d dentro del propio contenedor, son ejecutados.

Esto nos proporciona una manera para inicializar nuestra base de datos.

Si quieres profundizar en esta propiedad, puedes consultar la documentación de la imagen oficial de MongoDB en Docker.

🧪 Configuración del entorno de testing

Para ver cómo podemos hacer esto, vamos a empezar por el entorno de testing así que antes de nada, tenemos que crear la siguiente estructura de archivos dentro del directorio /docker/test de nuestro proyecto:

/
|-- /docker
|   |-- /dev
|   |   |-- .docker.dev.env
|   |-- /test
|   |   |-- /configureDatabase # <= Nuevo directorio y archivo.
|   |   |   |-- initDatabase.js
|   |   |-- .docker.test.env
|   |-- docker-compose.yml
|-- /node_modules
|-- /src
|-- package-lock.json
|-- package.json

El contenido del archivo initDatabase.js será el siguiente:

Este script está dividido en tres elementos diferentes.

La constante apiDatabases contiene todas las definiciones de bases de datos que queremos crear para nuestro contenedor.

Cada definición de base de datos contendrá su nombre (dbName), un array de usuarios (dbUsers) los cuales estarán autorizados para operar con la base de datos (incluyendo la definición de sus privilegios de acceso) y el conjunto de datos con los que inicializaremos la base de datos.

La función createDatabaseUser está destinada a gestionar la información contenida en cada bloque del apiDatabases, procesar los datos de usuarios y crearlos dentro de la base de datos indicada.

Finalmente, el bloque try/catch contiene la magia porque en este bloque iteramos sobre la constante apiDatabase, conmutamos entre bases de datos y procesamos la información.

Una vez que hemos analizado este código, si recordamos el contenido de nuestro archivo docker-compose.yml, dentro de la sección volumes definimos la siguiente línea:

- ${CONFIGURATION_PATH}:/docker-entrypoint-initdb.d:rw

Además, para el entorno de testing, dentro del archivo .docker.test.env, configuramos lo siguiente:

CONFIGURATION_PATH="./test/configureDatabase"

Con esta acción, el proceso docker-compose está copiando el contenido de la ruta indicada por CONFIGURATION_PATH dentro del directorio del contenedor /docker-entrypoint-initdb.d:rw antes de que éste se arranque por primera vez. Así es como estamos definiendo el script de configuración de nuestra base de datos, para que sea ejecutado al iniciarse el contenedor.

🙋‍♀️❓ Para esta configuración no estás usando ningún conjunto de datos iniciales. ¿Por qué?

Porque esta será la base de datos de testing y la intención es que se almacenen y eliminen datos ad-hoc en base a los tests que estén ejecutándose en un momento concreto. Por esta razón no tiene sentido que inicialicemos la base de datos con información que vamos a crear/editar/eliminar dinámicamente.

🛠 Configuración del entorno de desarrollo

Esta configuración es muy similar a la de testing.

Lo primero que tenemos que hacer es modificar el subdirectorio /docker/dev de nuestro proyecto, para que quede tal que así:

/
|-- /docker
|   |-- /dev
|   |   |-- /configureDatabase # <= Nuevo directorio y archivos.
|   |   |   |-- initDatabase.js
|   |   |   |-- postsDataToBePersisted.js
|   |   |   |-- usersDataToBePersisted.js
|   |   |-- .docker.dev.env
|   |-- /test
|   |   |-- /configureDatabase
|   |   |   |-- initDatabase.js
|   |   |-- .docker.test.env
|   |-- docker-compose.yml
|-- /node_modules
|-- /src
|-- package-lock.json
|-- package.json

Los archivos postsDataToBePersisted.js y usersDataToBePersisted.js sólo contienen información estática definida dentro de constantes independientes. Esta información será almacenad en la base de datos indicada, dentro de la colección especificada.

La estructura de dichos contenidos será la siguiente:

Por otro lado, el contenido del archivo initDatabase.js es bastante similar al del entorno de testing pero un poco más complejo ya que ahora tenemos que gestionar colecciones y datos. De este modo, el resultado final es este:

En este script hay varias partes que necesitamos analizar.

En la cabecera tenemos un bloque compuesto por dos llamadas a la función load() encaminadas a importar los datos preparados y almacenados en las constantes que declaramos en los otros archivos JavaScript.

🔥 Hay que prestar atención a que la ruta indicada para hacer referencia a los archivos de datos, es relativa al interior de la estructura de ficheros del contenedor de Docker y no a la de nuestro sistema. 🔥

ℹ️ Si quieres aprender más acerca de cómo ejecutar MongoDB archivos JavaScript en su consola de comandos, echa un vistazo a su documentación oficial.

Después de "importar" las definiciones de las constantes usersToBePersisted y postsToBePersisted mediante el uso de la función load(), estas están disponibles globalmente dentro del contexto de nuestro script de inicialización.

El siguiente bloque a analizar es el de la constante apiDatabases donde, además de los campos dbName y dbUsers que ya vimos en la configuración de testing, en este caso el array dbData es un poco más complejo.

Cada objeto declarado dentro del array dbData define el nombre de la colección así como el conjunto de datos que debe ser almacenado en dicha colección.

Ahora nos encontramos con la definición de la constante collections. Es la definición de un mapa de funciones el cual contiene las acciones que se deben ejecutar por cada colección definida en el bloque apiDatabases.dbData.

Como podemos ver, en estas funciones estamos invocando directamente instrucciones nativas de MongoDB.

La siguiente función que nos encontramos es createDatabaseUsers la cual no tiene diferencias con la que definimos para el entorno de testing.

Justo antes de terminar el archivo, encontramos la función populateDatabase.

En esta función es donde vamos a través de las colecciones de bases de datos, insertando los datos asignados y aquí es donde invocamos al mapa de funciones collections.

Finalmente tenemos el bloque try/catch donde ejecutamos las mismas acciones que para el entorno testing pero hemos incluido la llamada a la función populateDatabase.

De esta manera es como hemos podido configurar el script de inicialización para nuestra base de datos del entorno de desarrollo.

🧩 Comando de Docker Compose

Una vez que hemos definido el archivo de composición así como el conjunto de datos que inicializará nuestra base de datos, tenemos que definir los campos mediante los cuales, operaremos nuestros contenedores.

🔥 Hay que prestar especial atención al hecho de que las rutas empleadas están referenciadas a la raíz de nuestro proyecto. 🔥

🌟 Configurando los últimos detalles para NodeJS

El último paso es definir los scripts necesarios dentro de nuestro archivo package.json.

Para proporcionar una mejor modularización de los scripts, es muy recomendable que se dividan en diferentes scripts atómicos y luego, crear otros scripts diferentes para agrupar aquellos que sean más específicos.

Por ejemplo, en este código hemos definido los scripts dev_infra:up, dev_infra:down, test:run, test_infra:up and test_infra:down que son atómicos porque definen una acción simple y serán los encargados de arrancar y para los contenedores para cada entorno, así como de ejecutar la suite de test.

Por el contrario tenemos los scripts build:dev y test que son compuestos ya que cada uno involucra varios scripts atómicos.

🤔 FAQ

❓ ¿Qué pasa si la suite de testing se para repentinamente porque alguno de los tests ha fallado?

No hay que preocuparse por esto porque es verdad que la infraestructura de testing continuará ejecutándose pero tenemos dos opciones:

Mantener en ejecución el contenedor ya que la próxima vez que ejecutemos la suite de tests, el comando docker-compose actualizará el contenido del contenedor.
Ejecutar manualmente el script de apagado del contenedor de testing.

❓ ¿Qué sucede si en lugar de una base de datos, necesitamos ejecutar algún servicio más complejo como una API?

Sólo necesitamos configurar los contenedores/servicios necesarios dentro del archivo docker-compose.yml, prestando especial atención a la configuración .env para cada entorno.

No importa lo que queramos incluir en nuestros contenedores. Lo importante aquí es que vamos a ser capaces de arrancarlos y detenerlos cuando nuestro proyecto lo necesite.

👋 Conclusiones finales

Con esta configuración podemos incluir la gestión de la infraestructura necesaria para nuestros proyectos con NodeJS.

Este tipo de configuraciones nos proporciona un nivel de desacoplamiento que aumenta nuestra independencia durante la fase de desarrollo, ya que vamos a tratar elementos externos a nuestro código como una caja negra con la cual interactuar.

Otro punto interesante de esta estrategia es que cada vez que arrancamos el contenedor mediante el comando docker-compose, éste es totalmente renovado lo que nos permite asegurar que nuestras suites de tests van a ejecutarse sobre sistemas completamente limpios.

Además, mantendremos limpio nuestro propio sistema ya que no necesitaremos instalar ningún tipo de aplicación auxiliar porque todas ellas, estarán incluidas en diferentes contenedores que compondrán nuestras infraestructura de pruebas.

Sólo una advertencia a este respecto, trata de mantener el contenido de dichos contenedores lo más actualizado posible para, de ese modo, hacer las pruebas contra un entorno lo más parecido posible al que podemos encontrarnos en producción.

Espero que este contenido te sea útil. Si tienes cualquier pregunta, siéntete totalmente libre de contactar conmigo. Aquí están mis perfiles de Twitter, LinkedIn y Github.

🙏 Reconocimientos y agradecimientos

Jonatan Ramos por darme la pista del COMPOSE_PROJECT_NAME para crear archivos docker-compose.yml único que se comparten entre diferentes entornos.

Mocking our development and testing infrastructures with Docker

Dailos Rafael Díaz Lara — Mon, 28 Dec 2020 16:39:18 +0000

🇪🇸 Versión en español

🎯 Context

When we are creating a new application or feature, we usually need to send requests to independent resources such as databases or mocked services, but it's obvious that running these kind of actions against deployed servers have a cost.

On these kind of situations is where the isolation of systems provided by Docker containers becomes really useful.

In this post we are going to see how to use Docker for getting up the minimum infrastructure which allows us to run the development and/or testing tasks... locally.

The main target of this text is to show how to user a single docker-compose.yml file for both environments, using different .env files to customize the specific container for every one, development and testing.

In addition, we will focus on how to start up the new container for testing purposes, execute the tests and then, shut down the container.

💻 System configuration

If we are going to be talking about Docker, it's obvious that we need to have it already installed in our system. If you don't have it yet, you can follow the official documentation instruction for your specific operative system.

Another element that we are going to need is docker-compose. Once again, if you have not installed it yet, you can follow the official documentation.

Finally, due to this example is aimed to applications development based on JavaScript/TypeScript, we need to have installed NodeJS (official documentation).

🏗 Project initialization

🔥 If you have already started your NodeJS project, you can skip this section 🔥

We are going to initialize our NodeJS project opening a CLI, in the folder where we want to work, and typing the next command:

npm init -y

This action will create a single package.json file in the root of our project, with the next content:

Now we can install Jest running the next command in our CLI, in order to include this library in the project:

npm i -D jest

The next step is to create the most basic folder structure for the project.

/
|-- /docker # <= New subfolder.
|-- /node_modules
|-- /src # <= New subfolder.
|-- package-lock.json
|-- package.json

🐳 Setting up the Docker configuration

We are going to have two main environments (development and test) and the main idea is to have a single docker-compose.yml file in order to manage both environment containers.

📄 `docker-compose.yml` file definition

In order to reach that goal, inside the /docker folder we are going to create our single docker-compose.yml file which will contains the next code:

As we can see, there are several lines marked as coupling smell. It means that, with the current configuration, we can only run a single Docker container mainly aimed for development tasks. So we are strongly coupled to this environment.

Wouldn't it be fine whether we were able to replace those hardcoded configurations by references and that those references are defined by any kind of configuration file?

⚙ `.env` files for Docker containers

Yes!!! We can use .env files in the same way we do that for our applications, but for configuring Docker containers.

First at all, we need to edit the docker-compose.yml file we created recently in order to use curly-braces templates to define the constant names which will be replaced with the value defined in our .env files. This way, the docker-compose.yml file content will be defined this way:

As we can see, we have replaced the hardcoded values by ${CONSTANT_NAME} references. The name typed between curly braces will be the name of the values defined into our .env files. This way, when we run the docker-compose command, using some special CLI options that we will see later, the .env file content will be replaced into our docker-compose.yml file before creating the Docker container.

Now it's time to define our environments so we are edit the /docker folder content this way:

/
|-- /docker
|   |-- /dev
|   |   |-- .docker.dev.env
|   |-- /test
|   |   |-- .docker.test.env
|   |-- docker-compose.yml
|-- /node_modules
|-- /src
|-- package-lock.json
|-- package.json

For every environment, we have created a single subfolder: dev and test.

Into every environment subfolder we have created a specific .env file: .docker.dev.env and .docker.test.env.

🙋❓ Could it be possible just naming the environment files as .env?

Yes, it could and besides, there wouldn't be any issue with it but... a so descriptive file name is a kindly help for us as developers. Due to in the same project it's really likely there are multiple configuration files, it's useful to be able to differentiate between then when we have several ones open, at the same time, in the code editor. That is the reason why the .env files have a so descriptive names.

Now it's time to define the content of our environment files this way:

and...

There are four properties which you must pay attention in order to differentiate both files:

CONTAINER_NAME
EXTERNAL_PORT
VOLUME_NAME
CONFIGURATION_PATH

The CONTAINER_NAME property will define the name that we will see after the container is created and we run the command docker ps -a in order to list the whole containers in our system.

EXTERNAL_PORT is a really sensitive property due to it will define the connection port published by the container through which our application will connect with it. It's really important to be careful with this parameter because some times we will want to run the testing suite at the same time we have up the application in development mode, so if we define the same port for both containers, the system will throw an error because the selected port is already in use.

The VOLUME_NAME property will define the data storage name in our system.

Finally, in case we have defined any kind of data to prepopulate the database before using it, the CONFIGURATION_PATH property will allow us to define where that set of data is located.

🙋‍♀️❓ Hey but, what about the COMPOSE_PROJECT_NAME property?

That's a great question.

Our main goal is to create a specific container per environment, based on the same docker-compose.yml file.

Right now, if we run our docker-compose for development, for instance, we will create the container with that environment definition and the docker-compose.yml file will be bound with that container.

This way, if we try to run the same file but setting the testing configuration, the final result will be an update of the previous development container, without the defined testing configuration. Why? Because the compose file is bound to the first started container.

In order to reach our target successfully, we use the COMPOSE_PROJECT_NAME property into every .env file and we set a different value depending on the environment.

This way, every time we run the compose file, due to the project name is different for every .env file, the modifications will only affect to the containers bound with every project name.

🙋❓ That's fine but we are using COMPOSE_PROJECT_NAME only into our .env files and not in the docker-compose.yml one. How is possible that it affect to the final result?

It's possible because that property is read directly by docker-compose command and it's not needed to be included into the docker-compose.yml file.

In this link you have the whole official documentation about COMPOSE_PROJECT_NAME.

🤹‍♂️ Populating the database

🔥 Caveat: The next explained process is aimed to populate a MongoDB database. If you want to use a different engine, you have to adapt this process and the docker-compose.yml configuration for it. 🔥

The most basic concept we must know, if we already don't, is that when a MongoDB based on container starts first time, the whole files with extension .sh or .js located into the container folder /docker-entrypoint-initdb.d are executed.

This situation provides us a way to initialize our database.

If you want to get deeper about it, you can find the whole information about it in this link of the MongoDB Docker image documentation.

🧪 Testing environment configuration

In order to see how we can do that, we are going to start by the testing environment so first at all, we have to create the next file structure into the /docker/test folder of our project:

/
|-- /docker
|   |-- /dev
|   |   |-- .docker.dev.env
|   |-- /test
|   |   |-- /configureDatabase # <= New subfolder and file.
|   |   |   |-- initDatabase.js
|   |   |-- .docker.test.env
|   |-- docker-compose.yml
|-- /node_modules
|-- /src
|-- package-lock.json
|-- package.json

The content of the initDatabase.js file will be the next one:

This script is divided in three different elements.

The apiDatabases constant contains the whole databases definitions that we want to create for this container.

Every database definition will contain its name (dbName), an array of users (dbUsers) whose will be allowed to operate with the database (including their accessing privilege definitions) and the dataset which we will populate the database.

The createDatabaseUser function is focused on handle the information contained into every apiDatabases block, process the users data and create them into the specified database.

Finally the try/catch block contains the magic because in this block we iterate over the apiDatabases constant, switch between databases and process the information.

Once we have checked this code, if we remember our docker-compose.yml file content, into the volumes section we defined the next line:

- ${CONFIGURATION_PATH}:/docker-entrypoint-initdb.d:rw

In addition, for the testing environment, into the .docker.test.env file we set this configuration:

CONFIGURATION_PATH="./test/configureDatabase"

With this action, the docker-compose process is copying the content of the path defined by CONFIGURATION_PATH into the container /docker-entrypoint-initdb.d:rw before it's run first time. So we are setting our database configuration script to be executed in the container start up.

🙋‍♀️❓ For this configuration you are not setting any initial data. Why?

Because it will be the testing database so the intention is to persist and remove data ad-hoc based on the tests that are running in a specific moment. By this reason, it has not sense to populate this database with mocked information once we are going to create/edit/delete it dynamically.

🛠 Development environment configuration

This configuration is pretty similar to the testing one.

First at all, we have to modify the /docker/dev subfolder content in our project, in order to get this result:

/
|-- /docker
|   |-- /dev
|   |   |-- /configureDatabase # <= New subfolder and files.
|   |   |   |-- initDatabase.js
|   |   |   |-- postsDataToBePersisted.js
|   |   |   |-- usersDataToBePersisted.js
|   |   |-- .docker.dev.env
|   |-- /test
|   |   |-- /configureDatabase
|   |   |   |-- initDatabase.js
|   |   |-- .docker.test.env
|   |-- docker-compose.yml
|-- /node_modules
|-- /src
|-- package-lock.json
|-- package.json

The postsDataToBePersisted.js and usersDataToBePersisted.js files only contain static data defined into independent constants. That information will be stored in the defined database, into the specified collection.

The structure for the content included into these files is like that:

In the other hand, the content of initDatabase.js file is pretty similar to the testing environment definition but a little bit complex due to we have to manage collections and data. So the final result is this one:

At this script there are several parts that we need to analyze.

The header block composed by two load() function calls which are used in order to import the mocked data constants declarations that we did in the other JavaScript files.

🔥 Pay attention to the full data location path is referenced to the inner Docker container file structure, not to our system. 🔥

ℹ️ If you want to learn more about how MongoDB executes JavaScript files in its console, take a look to the official documentation.

After "importing" the usersToBePersisted and postsToBePersisted constants definitions via load() function, they are globally available into the context of our initialization script.

The next block to be analyzed is the apiDatabases constant definition where besides the dbName and dbUsers that we covered in the testing configuration, in this case the dbData array is a little bit more complex.

Every object declared into the dbData array defines the collection name as well as the dataset that must be persisted in that collection.

Now we find the collections constant definition. It's a set of mapped functions (or object lookup) which contains the actions to execute for every collection defined into the apiDatabases.dbData block.

As we can see, in these functions we are directly invoking native MongoDB instructions.

The next function is createDatabaseUsers which has not differences with the defined for the testing environment.

Just before ending the script file we can find the populateDatabase function.

In this function we go through the database collections inserting the assigned data and here is where we invoke the collections mapped functions object.

Finally we have the try/catch block where we run the same actions that we did for the testing environment but we have included the populateDatabase function call.

This way is how we can configure the initialization script for our development environment database.

🧩 Docker Compose commands

Once we have defined the composing file as well as the dataset that will initialize our databases, we have to define the commands which will run our containers.

🔥 Pay attention to the used paths are referenced to our project root. 🔥

🌟 Setting the final NodeJS commands

The final step is to define the needed scripts into our package.json file.

In order to provide a better modularization of scripts, it's strongly recommended to divide the different scripts in atomic ones and then, create new ones which group the more specific ones.

For instance, in this code we have defined the dev_infra:up, dev_infra:down, test:run, test_infra:up and test_infra:down scripts which are atomic because define a single action to do and will be in charge to start and turning off the containers for every environment as well as to run the testing suite.

In opposite we have the build:dev and test scripts which are composed due to they include several atomic actions.

🤔 FAQ

❓ What happen if the testing suite suddenly stops because any test fails?

Don't worry about that because it's true that the testing infrastructure will keep running but we have two options:

To keep it running so the next time we run the testing suite, the docker-compose command will update the current container.
To run manually the shutting down script for the testing container.

❓ What happen whether instead of a database we need to run a more complex service like an API?

We just need to configure the needed containers/services into the docker-compose.yml file, paying special attention to the .env configurations for every environment.

It doesn't matter what we wrap and/or include in our container/s. The important point here is that we are going to be able to start and turning off them when our project needs it.

👋 Final words

With this configuration, we can include infrastructure management to our NodeJS based on project.

This kind of configuration provides us a decoupling level that will increase our independency during the development period, because we are going to treat the external elements to our code as a black box which we interact.

Another interesting point for this strategy is that every time we start up the container via docker-compose, it's totally renewed so we can be sure that our testing suites are going to be run in a completely clean system.

In addition, we will keep clean our system due to we don't need to install any auxiliar application on it because all of them will be included into the different containers that compose our mocked infrastructure.

Just a caveat, try to keep the content of the containers up-to-date in order to work with the closest production environment conditions as it's possible.

I hope this tip is useful for you. If you have any question, feel free to contact me. Here there are my Twitter, LinkedIn and Github profiles.

🙏 Credits and thanks

Jonatan Ramos for providing the clue of COMPOSE_PROJECT_NAME to create a single docker-compose.yml file shared between different environments.

De if/switch a mapped functions (a.k.a. object lookup)

Dailos Rafael Díaz Lara — Mon, 14 Dec 2020 22:12:23 +0000

🇬🇧 English version

🎯 Objetivo

Este texto está orientado a proporcionar una alternativa para aquellas situaciones donde nuestro código debe estructurarse para ejecutar una u otra función, dependiendo de un conjunto definido de posibles condiciones.

En ningún momento es mi intención criticar el uso de if/else o de switch/case. Mi único objetivo es proporcionar una propuesta diferente con que mejorar el mantenimiento y la escalabilidad de nuestro código.

Una vez dicho esto... empecemos!!!

📚 Instrucción if/else

Desde que empezamos a aprender a programar, el primer control de flujo de información que aprendemos es el if/else (MDN if/else documentation). De este modo, cuando ya lo hemos aprendido, es realmente fácil utilizarlo.

Incluso cuando la cantidad de posibles opciones se incrementa, podemos encadenar multiples if/else.

Además, cuando tenemos varias opciones que deben tratarse de la misma manera, es decir que comparten la misma lógica de negocio, podemos usar operadores booleanos (el OR en este caso), para agrupar todas esas opciones bajo el mismo bloque de código.

Todo esto está genial pero cuando los posibles casos superan las dos o tres opciones, el código empieza a parece un poco sucio.

Pros (✅) y contras (👎)

✅ Es la manera más fácil de controlar el flujo de información.
✅ Es relativamente fácil de aprender.
✅ discriminar entre dos posibles opciones es realmente cómodo.

👎 Cuando gestionamos más de tres opciones, el código empieza a parece un poco sucio..
👎 Encadenar múltiples opciones disminuye la legibilidad y el mantenimiento de nuestro código.
👎 Agrupar opciones empleando operadores booleanos puede hacer más complicadas las reglas de comparación en cada situación.
👎 Para una cantidad relativamente grande de casos posibles, es más lento ya que cada condición deber ser comprobada hasta alcanzar aquella que coincida con el valor de referencia proporcionado.

🤓 Instrucción switch/case

Cuando queremos mejorar la legibilidad y mantenimiento de nuestro código debido a que tenemos múltiples opciones que gestionar, es cuando aprendemos la alternativa al if/else, es decir, el switch/case (MDN switch/case documentation).

De la misma manera que hacíamos con el if/else, con el switch/case también podremos agrupar opciones pero en este caso, no necesitamos utilizar ningún operador booleano. Sólo necesitamos mantener unidos los diferentes casos a agrupar.

Como ya sabrás, esto es posible gracias a que la ejecución del switch/case es un proceso secuencial, donde cada posible caso definido en el conjunto de opciones, es comparado con la referencia proporcionada.

Si ambos valores coincide, el bloque de código incluido en ese caso se ejecuta y, si no hay una instrucción break o return al final de dicho bloque de código, el siguiente caso será comprobado hasta encontrar la próxima coincidencia o hasta llegar al bloque default.

Basándonos en esto, para agrupar múltiples opciones las cuales van a ser gestionadas por el mismo bloque de código, sólo necesitamos definir el caso para el valor deseado, sin ningún tipo de lógica de negocio. De este modo seremos capaces de encadenar múltiples opciones para el mismo resultado.

Pros (✅) y contras (👎)

✅ Proporciona una mejor estructura del código que al usar instrucciones if/else.
✅ Es posible crear agrupamiento de casos de una manera más clara que con instrucciones if/else.
✅ Es realmente sencillo discriminar entre más de dos opciones.

👎 Tenemos que estar pendiente de completar todos los bloques de código con una instrucción break o return. Si nos olvidamos de hacerlo, nos podemos meter en un buen lío.
👎 Para cantidades relativamente grandes de casos, es lento dado que cada condición debe ser comprobada hasta llegar a aquella que coincide con la referencia que le hemos proporcionado.

🔥 Mapped functions

Esta es una estrategia poco conocida (también llamada object lookup) y está destinada a mejorar determinados aspectos del uso de instrucciones if/else y switch/case.

La idea es aprovechar el comportamiento de los objetos de JavaScript para usar sus claves como mapa de referencias y acceder directamente a lógica de negocio específica.

Antes de nada, necesitamos tener definidos los posibles casos que van a ser gestionados.

Cada caso individual será asociado a una clave del objeto literal.

Una vez hemos creado nuestro objeto, usaremos el estilo de acceso array para ejecutar el código de cada caso individual.

Pros (✅) y contras (👎)

✅ Proporciona una estructuración del código mejor que la que obtenemos al usar instrucciones if/else y switch/case.
✅ No hay agrupamiento de posibles casos dado que cada uno de ellos tiene definida su propia lógica de negocio.
✅ Es extremadamente fácil diferenciar entre múltiples opciones de ejecución.
✅ Puede ser reutilizado en varias partes de nuestra aplicación (via exportación de módulo).
✅ Es más rápido que if/else y switch/case dado que accedemos a la condición específica que queremos ejecutar, sin necesitar verificar cada uno de los casos secuencialmente, hasta encontrar el correcto.

👎 Esta estrategia rara vez aparece en las formaciones más habituales.
👎 Si el objeto no se define en el lugar indicado de la aplicación, puede consumir un poco más de memoria de la necesaria.

🤔 FAQ

❓ ¿Qué sucede si proporcionamos una opción que no están entre las claves del objeto?

La respuesta corta es que se disparará una excepción ya que no es posible ejecutar una función de undefined.

No obstante, podemos prevenir esto definiendo un caso default, de la misma manera que hacemos en la instrucción switch/case.

Para ser capaces de acceder a este nuevo caso, comprobaremos si la opción proporcionada existe dentro del objeto y si no existe, entonces ejecutaremos la opción default.

Para estos casos, operador condicional (ternario) será nuestro aliado.

❓ ¿Qué puedo o debo devolver en el caso `default`?

Esto va a depender del caso de uso que estemos definiendo pero básicamente, vamos a tener tres opciones principales:

1 - Devolver el mismo valor que hemos proporcionado:

2 - Devolver null o undefined:

En este caso, podemos incluso aprovechar el optional chaining y dejar más limpio nuestro código:

Debemos prestar atención porque in este caso, si no hay coincidencia en las opciones disponibles, vamos a devolver undefined.

3 - Definir una lógica de negocio específica:

Aquí debemos tener cuidado si nuestro código, como se muestra en el ejemplo, va a disparar un error. Tenemos que gestionar dicho error para evitar un error total que bloquee nuestra aplicación.

Obviamente el código que implementa el error puede ser reemplazado por cualquier otra lógica de negocio que se adecue mejor al comportamiento de nuestra aplicación.

❓ ¿Necesito definir una función anónima para cada caso?

No, en absoluto.

Si tenemos perfectamente definida la función que debe ser ejecutada para cada caso y además, dicha función recibe únicamente un argumento que coincide con el que estamos proporcionando cuando invocamos al mapa, podemos usar esta sintaxis:

Incluso si queremos devolver undefined cuando la opción proporcionada no está incluida dentro del mapa, podemos usar esta otra sintaxis extremadamente simplificada (Advertencia ‼️: todas las funciones usadas para crear las claves del mapa, han de estar definidas previamente):

❓ ¿Es posible que el nombre de una propiedad entre en conflicto con el de un objeto?

Rotundamente sí.

Es totalmente posible, pero para evitar esto tenemos que prestar atención a los nombres que estamos usando, de la misma manera que nunca utilizaríamos una palabra reservada del lenguaje como nombre de variable, función u objeto.

❓ ¿Esto podría formar una nueva convención de nombres?

Sí, claro.

Pero para este tipo de situaciones tenemos el apoyo y las guías proporcionadas por el Clean Code.

Cada código que creemos requerirá una convención de nombres. En algunos casos cuando seamos la única persona que ha iniciado el proyecto, podremos definir dicha convención (pet-projects principalmente). En otras situaciones, será el equipo de desarrollo el responsable de cualquier acuerdo alcanzado a tal efecto.

❓ ¿Requerirá un uso de memoria adicional mientras que el `if/else` y el `switch/case` no lo hacen?

Sí, lo hará.

Sin embargo, basándonos en los tipos de dispositivos que ejecutan nuestras aplicaciones JavaScript hoy en día así como en sus características, el incremento de memoria es prácticamente insignificante en comparación con el resto de la aplicación.

❓ ¿Sería esta opción más lenta que el `if/else` o el `switch/case` dependiendo del motor de JavaScript que se use?

Esto va a depender de cómo definamos el objeto en sí.

Por ejemplo, si definimos el objeto de mapeado de funciones dentro de una función, la cual va a ser invocada cada vez que queramos hacer uso del mapa, obviamente esta solución va a ser más lenta que las otras opciones, porque el objeto debe ser creado cada vez.

En este código podemos ver la situación donde la función mappedFunction tiene definido el objeto dentro de ella:

Codepen 👉 Speed race Switch 🐇 vs Object Lookup 🐢 v1

Aquí no importa qué motor de JavaScript estemos usando para ejecutar el código (AppleWebKit para Safari, SpiderMonkey para Firefox o V8 para Google Chrome y/o NodeJS), porque el mapeado de funciones será siempre más lento (incluso si operamos los primeros casos), debido a que el objeto se está creando ad-hoc en cada ejecución de la función.

Sin embargo, si definimos el mapeado de funciones de manera global (al módulo o a la aplicación), el objeto se cargará cuando el módulo o la aplicación lo usen. De este modo, el acceso a las funciones mapeadas será siempre más rápido que las otras dos opciones.

En este código hemos definido el mapa fuera de la función mappedFunction:

Codepen 👉 Speed race Switch 🐢 vs Object Lookup 🐇 v2

❓ ¿Qué pasa con el recolector de basura?

Hoy en día el recolector de basura es algo a lo que quienes desarrollamos con JavaScript no le prestamos mucha atención, debido a que está ampliamente cubierto por las especificaciones del lenguaje así que, una vez el mapa de funciones ya no está en uso en el proceso de ejecución actual, el objeto será gestionado por el recolector de basura automáticamente.

Para más información respecto a este tema, recomiendo echar un vistazo a esta documentación de la MDN relativa a la gestión de la memoria.

Recursos adicionales:

Garbage collection por javascript.info (2020)

👋 Conclusiones finales

Como ya he dicho al principio de este post, no es mi intención criticar de ningún modo el uso de if/else o switch/case, sino que únicamente pretendo proporcionar otra manera de realizar dichas operaciones.

Resumiendo, cuando tengamos que discriminar entre dos simples opciones, es obvio que la alternativa más sencilla es usar if/else. Además recomiendo encarecidamente que intentes usar el operador ternario allí donde sea posible.

Para aquellos casos donde tengamos que diferenciar entre tres o más opciones, sinceramente recomiendo el uso de funciones mapeadas para proporcionar una mejor legibilidad, mantenimiento y reutilización de nuestro código.

Espero que este contenido te sea útil. Si tienes cualquier pregunta, siéntete totalmente libre de contactar conmigo. Aquí están mis perfiles de Twitter, Linkedin y Github.

🙏 Reconocimientos y agradecimientos

A Lissette Luis, Adrián Ferrera e Iván Bacallado por formar parte de un equipo fantástico donde se comparte el conocimiento y especialmente, por sus propuestas sobre el tema abordado en este texto.
A Simon Høiberg por iniciar este interesantísimo hilo de Twitter que ha originado la creación de este post.
A Kenan Yildiz y Thomas Luzat por compartir una opción más simplificada de la implementación del mapa de funciones.

From if/switch to mapped functions (a.k.a. object lookup)

Dailos Rafael Díaz Lara — Mon, 14 Dec 2020 13:53:43 +0000

🇪🇸 Versión en español

🎯 Context

This text is aimed to provide an alternative to these situations where our code must be structured in order to run one or another function, depending on a bunch of possible conditions.

I don't want to criticize the use of if/else or switch/case sentences far from it. My only goal is to provide a different approach which can improve the maintenance and scalability of our code.

So... engage!!!

📚 if/else sentences

Since all of us start learning to code, the first flow control sentence that we learn is the if/else one (MDN if/else documentation). So once we have got it, it's really easy to use.

Even when the amount of possible options increases, we can chain multiple if/else.

In addition, when we have several options which must be treated in the same way (it means with the same business logic), we can use boolean operators (the OR one in this case), in order to group all these options under the same block.

That's fine but when the possible cases are upper than two or three options, the code starts to look like a little bit messy.

Pros (✅) and cons (👎)

✅ It's the easier way to control data flow.
✅ It's relatively easy to learn.
✅ It's really comfortable to discriminate between two options.

👎 For handling more than three options, the code starts to look like a little bit messy.
👎 To chain multiple options reduce the readability and maintenance of our code.
👎 To group options using boolean operators could turn on complex assertion rules for every situation.
👎 For a relatively huge amount of cases, it's slow due to every condition must be checked until getting the only one that matches.

🤓 switch/case sentence

When we want to improve the readability and maintenance of our code due to we have multiple options to be handled, is when we learn the if/else alternative, it means, the switch/case sentence (MDN switch/case documentation).

In the same way we did with the if/else sentence, with switch/case we can also group options but now, we don't need to use any boolean operator. We just need to keep joined the different cases.

As you already know, that's possible due to the switch/case execution is a sequential process, where every possible case defined in the block of options, is compared with the provided value.

If both values match, the code block included into that case is executed and, if there is not a break or return instruction at the end of the code block, the next case will be checked until the next matching or the default option is reached.

Based on that, in order to group several options which are going to be handled by the same code block, we just need to define the case for the wished value, with no business logic. This way we're able to chain multiple options for the same result.

Pros (✅) and cons (👎)

✅ It provides a better code structuring than if/else sentences.
✅ It's possible to create clearest cases grouping than if/else sentences.
✅ It's really easy to discriminate between more than two options.

👎 You have to be aware about completing all your code blocks with a break or a return instruction. If you forget it, you'll have a real nightmare.
👎 For a relatively huge amount of cases, it's slow due to every condition must be checked until getting the only one that matches.

🔥 Mapped functions

This is a little known strategy (a.k.a. object lookup) aimed to improve several aspects of if/else and switch/case sentences.

The idea is to take advantage of a JavaScript object behavior in order to use its keys as map references to access to specific business logic.

First at all, we need to have defined the possible cases which must be handled.

Every single case will be bound to a key in the literal object.

Once we have created our object, we'll use array-access style to run the code for every single case.

Pros (✅) and cons (👎)

✅ It provides a better code structuring than if/else and switch/case sentences.
✅ There is no cases grouping due to every single case has its own business logic.
✅ It's extremely easy to differentiate between multiple options.
✅ Can be reused in several parts of our application (via module export).
✅ It's faster than if/else and switch/case due to we access to the specific condition without need to check every defined case sequentially until the correct one is located.

👎 This strategy rarely appears in common trainings.
👎 If the object is not defined in the right place, it can consume a little bit more memory that it really needs.

🤔 FAQ

❓ What happen if the provided option is not defined as object key?

The short answer is that an exception will be throw due to it's not possible to run a function from undefined.

However, we can prevent it defining a default case, in the same way we do in switch/case sentences.

In order to be able to access this new case, we will check if the provided one already exists into the object and if it doesn't, we run the default option.

For these cases, the conditional (ternary) operator will be our allied.

❓ What can/must I return in the `default` case?

It'll depend on the use case we are defining but basically, we have three main options:

1 - To return the same value that you have provided:

2 - To return null or undefined:

In this case, we can even take advantage of the optional chaining and clean up the code this way:

We have to pay attention because in this last case, if there are no matching options, we are going to be returning undefined.

3 - To define a specific business logic:

We must be careful if our code, like in this example, is going to throw an error. We need to handle it in order to avoid a full blocking error.

Obviously the code that implements the error can be replaced for any other business logic which suites better with our application behavior.

❓ Do I need to define an anonymous function for every case?

No, you don't.

If we have perfectly defined the function that must be run for every case and in addition, that function receives only a single argument which matches with the provided one when you invoke the map, we can use this syntax:

Even if we want to return undefined when the provided option is not included into the map, we can use this extremely simplified syntax (Caveat ‼️: the whole functions used in order to create the mapped object keys must be defined previously):

❓ It could be possible that property name clashes with an object one?

Absolutely yes.

It's possible at all, but in order to avoid that we have to pay attention what names are we using, in the same way we never use a language reserved word as variable, function or object name.

❓ It could force a naming convention?

Yes, it could.

But for these situation we have the support and guidances of Clean Code.

Every code we create requires naming convention. Some cases when we are the only person who has started the project, we can define that convention (pet-projects mainly). In other situations, the development team will be the responsible of any agreement about that.

❓ Is it going to require additional memory meanwhile `if/else` and `switch/case` does not do it?

Yes, it will.

However, based on the kind of devices that run our JavaScript applications nowadays and its characteristics, the increment of used memory is insignificant compared with the rest of the application.

❓ Should it be slower that `if/else` or `switch/case` depending on the JavaScript engine?

It depends on where we define the object.

For instance, if we define the mapped functions object into a function which is going to be called every time we want to use the map, obviously this solution is going to be slower that the other options because the object must be created every time.

In this code we can see that situation where the mappedFunction has defined the object lookup inside:

Codepen 👉 Speed race Switch 🐇 vs Object Lookup 🐢 v1

It doesn't matter which JavaScript engine you use to run this code (AppleWebKit for Safari, SpiderMonkey for Firefox or V8 for Google Chrome and/or NodeJS), because the mapped function will be always slower (even with the first cases) due to the object is created ad-hoc for every function run.

Nevertheless, if we define the mapped functions globally (to the module or to the application), the object will be loaded just once when the module or the application is used so, this way, the mapped function access is always faster than the other two options.

In this another code we have defined the object lookup outside the mappedFunction:

Codepen 👉 Speed race Switch 🐢 vs Object Lookup 🐇 v2

❓ What about the garbage collector?

Nowadays the garbage collector is something that the JavaScript developers don't pay too much attention due to it's widely covered by the language specifications so, once the mapped functions object is not used any more by the current runtime, it will be managed by the garbage collector automatically.

For further information about that, I recommend you to take a look to this documentation of the MDN about memory management.

Additional resources:

Garbage collection by javascript.info (2020)

👋 Final words

As I said at the beginning of this post, it's not my intention to criticize the use of if/else or switch/case, but I only want to provide another way to do these operations.

Summarizing, when we've to discriminate between two single options, it's obvious that the easier alternative is to use if/else sentence. Moreover I strongly recommend you to try to use the ternary operator when it's possible.

For cases where you have to differentiate between three or more options, I sincerely recommend you to use mapped functions in order to provide a better readability, maintenance and code reuse.

I hope this tip is useful for you. If you have any question, feel free to contact me. Here there are my Twitter, Linkedin and Github profiles.

🙏 Credits and thanks

Lissette Luis, Adrián Ferrera and Iván Bacallado for being part of an awesome knowledge sharing team and specially, for their proposals about the subject covered on this post.
Simon Høiberg for starting this interesting Twitter thread that originated the creation of this post.
Kenan Yildiz and Thomas Luzat for sharing a shorter way to implement the object lookup.

Jest with global Dotenv configuration

Dailos Rafael Díaz Lara — Sat, 01 Aug 2020 18:44:34 +0000

🎯 Target

I want to have several .env files in order to define different conditions depending on the environment where my code is running. Based on that, in my testing process I want to load a global configuration once for the whole testing suites.

😅 Overview

There are some options to load environment variables in my tests, using Dotenv.

node -r dotenv/config node_modules/.bin/jest

That is one of the most usual approaches but I don't like it because this way, Dotenv literally needs a .env file defined at the root of the project so I cannot set a custom configuration file.
require(dotenv).config({ path: 'path/to/env_file' });

This option requires to type this command in every testing file where I'm going to use environment variables. It could be a solution but I don't like it at all because I have to pay attention to the relative path for the environment file location in every testing file.
setupFiles Jest configuration property.

That is fine but as the official documentation suggests, the environment is processed once per testing file. This conditions will dealy a little my tests execution and in addition, I don't want it. I want a global configuration at the very begining of the testing process.

😎 My best matching

After diving a little in the Jest documentation, I found this configuration property: globalSetup.

In order to use this property, I created the dotenv-test.js file into dotenv folder (located at the root of the project).

// dotenv-test.js file content.

const path = require('path');
const dotenv = require('dotenv');

module.exports = async () => {
    dotenv.config({ path: path.resolve(__dirname, '../env/.env.test') });
};

Following the property documentation guidelines, this file must export an asynchronous function that will be executed before the whole testing files.

When the testing framework runs at the first time, this file is executed, loading the selected environment variables and setting them globally, for the whole testing files and just once. That's all.

Finally, I have just to introduce this property into the Jest configuration file (jest.config.json) and provide the location of the Dotenv file.

{
    ...
    "globalSetup": "<rootDir>/dotenv/dotenv-test.js",
    ...
}

👋 Final words

I hope this tip is useful for you. If you have any question, feel free to contact me. Here there are my Twitter, Linkedin and Github profiles.

💾 Resources

Example code repository https://github.com/ddialar/testing.jest.global.dotenv
Jest configuration docs https://jestjs.io/docs/en/configuration.html

DEV Community: Dailos Rafael Díaz Lara

Definiendo nuestras infraestructuras para desarrollo y testing con Docker

🎯 Objetivo

💻 Configuración del sistema

🏗 Inicialización del proyecto

🐳 Definiendo la configuración de Docker

📄 Definición del archivo docker-compose.yml

⚙ Archivos .env para contenedores Docker

🤹‍♂️ Inicializando la base de datos

🧪 Configuración del entorno de testing

🛠 Configuración del entorno de desarrollo

🧩 Comando de Docker Compose

🌟 Configurando los últimos detalles para NodeJS

🤔 FAQ

👋 Conclusiones finales

🙏 Reconocimientos y agradecimientos

Mocking our development and testing infrastructures with Docker

🎯 Context

💻 System configuration

🏗 Project initialization

🐳 Setting up the Docker configuration

📄 docker-compose.yml file definition

⚙ .env files for Docker containers

🤹‍♂️ Populating the database

🧪 Testing environment configuration

🛠 Development environment configuration

🧩 Docker Compose commands

🌟 Setting the final NodeJS commands

🤔 FAQ

👋 Final words

🙏 Credits and thanks

De if/switch a mapped functions (a.k.a. object lookup)

🎯 Objetivo

📚 Instrucción if/else

Pros (✅) y contras (👎)

🤓 Instrucción switch/case

Pros (✅) y contras (👎)

🔥 Mapped functions

Pros (✅) y contras (👎)

🤔 FAQ

❓ ¿Qué sucede si proporcionamos una opción que no están entre las claves del objeto?

❓ ¿Qué puedo o debo devolver en el caso default?

❓ ¿Necesito definir una función anónima para cada caso?

❓ ¿Es posible que el nombre de una propiedad entre en conflicto con el de un objeto?

❓ ¿Esto podría formar una nueva convención de nombres?

❓ ¿Requerirá un uso de memoria adicional mientras que el if/else y el switch/case no lo hacen?

❓ ¿Sería esta opción más lenta que el if/else o el switch/case dependiendo del motor de JavaScript que se use?

❓ ¿Qué pasa con el recolector de basura?

👋 Conclusiones finales

🙏 Reconocimientos y agradecimientos

From if/switch to mapped functions (a.k.a. object lookup)

🎯 Context

📚 if/else sentences

Pros (✅) and cons (👎)

🤓 switch/case sentence

Pros (✅) and cons (👎)

🔥 Mapped functions

Pros (✅) and cons (👎)

🤔 FAQ

❓ What happen if the provided option is not defined as object key?

❓ What can/must I return in the default case?

❓ Do I need to define an anonymous function for every case?

❓ It could be possible that property name clashes with an object one?

❓ It could force a naming convention?

❓ Is it going to require additional memory meanwhile if/else and switch/case does not do it?

❓ Should it be slower that if/else or switch/case depending on the JavaScript engine?

❓ What about the garbage collector?

👋 Final words

🙏 Credits and thanks

Jest with global Dotenv configuration

🎯 Target

😅 Overview

😎 My best matching

👋 Final words

💾 Resources

📄 Definición del archivo `docker-compose.yml`

⚙ Archivos `.env` para contenedores Docker

📄 `docker-compose.yml` file definition

⚙ `.env` files for Docker containers

❓ ¿Qué puedo o debo devolver en el caso `default`?

❓ ¿Requerirá un uso de memoria adicional mientras que el `if/else` y el `switch/case` no lo hacen?

❓ ¿Sería esta opción más lenta que el `if/else` o el `switch/case` dependiendo del motor de JavaScript que se use?

❓ What can/must I return in the `default` case?

❓ Is it going to require additional memory meanwhile `if/else` and `switch/case` does not do it?

❓ Should it be slower that `if/else` or `switch/case` depending on the JavaScript engine?