End-to-end (E2E) testing is a powerful tool for automated quality assurance. Ideally you want to be able to catch potential errors and bugs already on the unit testing level, but doing so can sometimes be both time-consuming and difficult. Unit testing also relies heavily on mocking out dependencies by nature, so we cannot necessarily guarantee the same behaviour as in our live application. E2E tests are on the other hand often very straightforward to set up and write, and enables us to construct very realistic testing scenarios.
Frontman is a very light-weight NGINX reverse proxy that is deployed using Docker. Its purpose is to act as the entry point to your server. It will redirect incoming traffic to one out of many Docker-based applications running on the same server, based on the hostname in the incoming request.
The rationale behind this is that it enables you to host as many services as you want on the same server, while still only keeping ports 80 and 443 open to the outside world.
In this blog post I will describe how I set up my own web server using just a single Raspberry Pi at home. This is a cheap and fun solution to hosting your own applications, in my case using Docker.
Setting up the Raspberry Pi Install the Raspbian OS on your Raspberry Pi’s SD card.
In order to connect wirelessly to the Raspberry without having it connect to a monitor, you need to set up headless SSH.
In this blog post I will describe how you can deploy services on the same server. The server will be fronted by an NGINX instance acting as a reverse proxy responsible for forwarding incoming traffic to the right service.
I will use an EC2 instance on AWS since it has a low monthly cost and I don’t have to worry about hardware maintenance at all, but you can use the same approach for any kind of server.
In this post I am going to give you an overview of different approaches to use when unit testing your backend code and database calls.
Background In my current project, we have a backend written in Go and a PostgreSQL database. We have for a long time been writing unit tests for the backend to be able to guarantee that the code is working as intended. In order to not have to rely on a database connection and be dependent on the state of the data in that database, we chose to mock away all database calls using a tool called go-sqlmock in the unit tests.