mongodb-memory-server VS Docker Compose

In the case of MongoDB there's jest-mongodb that use mongodb-memory-server; for other DBMS, I don't know if it's possible to run an instance in memory.

The only thing really messing is tests. At work we use https://github.com/nodkz/mongodb-memory-server

The final method tries to combine both methods, 1 and 2. It uses an external package MongoDB In-Memory Server for our MongoDB.

The above test is clear and easy to understand, but the reality is that, while this can be applied to a lot of cases, things get very complicated when you have to start to mock things like dependencies, API calls, etc... And one very tricky case is when you have to test a function that invoke some models from an ODM like Mongoose, like doing some CRUD operations against a database. In some cases a solution could be to use an actual test database, so you don't mock anything but you use real data. The only problem with that is that is assuming that you must have a database at your disposal to run unit tests, and that's not always possible, plus you have to clean the database, and a pletora of other problems. Another solution could be to use a database that lives only in memory and only for the duration of your tests, like the excellent mongodb-memory-server package. But while this will work most of the times, if you deploy your code on any CI/CD you might encounter problems (and I did!). Also a key factor of unit testing, is that you shouldn't rely on external services run them, unlike E2E tests for example. What you should do is to mock most of the dependencies you need, as your goal is to just test the function and no deeper than that.

I've been working on creating an application using Node.js and Mongoose where all data stored in the cloud MongoDB Atlas. My goal was to test API endpoints and write some unit tests, for that I found this package called mongodb-memory-server, which allows me to create a connection to the MongoDB server from my cache folder without a need to use cloud test database or installing mongodb client.

In both articles, the authors refer to nodkz's mongodb-memory-server package.

mongodb-memory-server package by @nodkz

There are a whole lot of configuration options for you to explore with this package here -> https://github.com/nodkz/mongodb-memory-server

Using Docker Compose to run Postgres and any third-party services locally provides a streamlined and consistent development environment. Developers can define services in a docker-compose.yml file, which enables them to configure and launch an entire stack with a single command. In this case, Postgres is encapsulated within a container with predefined configurations. Docker Compose also facilitates easy scaling, updates, and isolation of services, enhancing development efficiency and reducing the setup time for new team members or transitioning between projects. It encapsulates complex configurations, such as Postgres' performance monitoring and logging settings, in a manageable, version-controlled file, simplifying and replicating the service setup across different environments.

“Compose simplifies the control of your entire application stack, making it easy to manage services, networks, and volumes in a single, comprehensible YAML configuration file. Then, with a single command, you create and start all the services from your configuration file.” - Docker documentation

curl -fsSL https://get.docker.com -o get-docker.sh sudo sh get-docker.sh # Install docker compose sudo curl -L "https://github.com/docker/compose/releases/download/1.29.2/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose # Apply executable permissions to the binary sudo chmod +x /usr/local/bin/docker-compose # Run Project docker-compose up -d

Docker,

This foundation now opens the door to even more powerful concepts. You can explore more advanced concepts such as container networking, streamlining the management of complex applications with Docker Compose, and how to make your application data persistent using volumes.

In many projects that are containerized, especially in cases where development is also done locally with docker-compose, teams often have two Dockerfiles, 1 for Development, the other for Production. If you happen to have multiple environments like pre-prod, staging and so on, some teams could have different Dockerfiles for these environments.

sudo curl -L "https://github.com/docker/compose/releases/latest/download/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose

You can also use Docker Compose to deploy the cluster, without having to write all the previous commands.

[ec2-user]$ sudo yum update -y [ec2-user]$ sudo yum install -y docker [ec2-user]$ sudo service docker start [ec2-user]$ sudo curl -L https://github.com/docker/compose/releases/latest/download/docker-compose-$(uname -s)-$(uname -m) -o /usr/local/bin/docker-compose [ec2-user]$ sudo chmod +x /usr/local/bin/docker-compose [ec2-user]$ docker --version Docker version 20.10.23, build 7155243 [ec2-user]$ docker-compose --version Docker Compose version v2.18.1