DEV Community

Cover image for Restful API Testing (my way) with Express, Maria DB, Docker Compose and Github Action
SeongKuk Han
SeongKuk Han

Posted on • Updated on

Restful API Testing (my way) with Express, Maria DB, Docker Compose and Github Action

A few weeks ago, I took a short cyber security course on Udemy. SQL injection was a section of the course. I knew about the concept though, I hadn't tried it. I was planning to make a Restful API server and tried SQL injection using a tool sqlmap, which was introduced in the course. While I could have used existing server code, I decided to build one from scratch. It's been a while since I worked on a Restful API server, and I wanted to refresh my knowledge for learning purposes.

I developed a basic Restful API server, and to ensure its APIs would function correctly, I wrote test code using supertest. While I tested the server, I encountered two challenges. First, I needed to run a database before testing. Second, I had to manage the data generated during testing. To address these issues, I considered two options: mocking the database and creating a database for testing. I opted for the second option. I believed it would provide more accurate results, and I implemented it using Docker.

What I did may be not the best approach. This is why there is my way in the title. As I have mainly been working on React projects, I don't have much practical experience with it. I faced several problems. Do you remember when you first started to code? you just made it work what you wanted to do, even though it was not a good way. I approached it this way. My goal was dockerizing the testing process and integrating it into Github Actions. My hope is that this article will be helpful to others.

Table of contents:

Since the implementation of the server is not the point of this article, I won't show the all codes. You can check the code the respotiory.

This picture may be helpful to understand the process better.

Test Process

Server Code


import express from 'express';
import { loadEnv } from './configs/env';
import { initDatabase } from './configs/db';
import routes from './routes';


const app = express();
const PORT = process.env.PORT ?? 3000;

app.use(express.urlencoded({ extended: true }));

// routes
for (const [key, value] of Object.entries(routes)) {
  app.use(key, value);

  .then(() => {
    app.listen(PORT, () => {
      console.log(`Server is listening on ${PORT}`);
  .catch((err) => {
Enter fullscreen mode Exit fullscreen mode

It imports routes and runs the server. Keep it mind that the server starts after database initialization.


import mariadb, { Pool, PoolConnection } from 'mariadb';
import { loadEnv } from './env';
import { createUserTable } from '../models/user.model';
import { createTodoTable } from '../models/todo.model';


let pool: Pool;

const initPool = async () => {
  try {
    const dbConnectionData = {
      host: process.env.MARIADB_HOST,
      user: process.env.MARIADB_USER,
      password: process.env.MARIADB_PASSWORD,
      connectionLimit: Number(process.env.MARIADB_CONNECTION_LIMIT) ?? 0,
      connectTimeout: Number(process.env.MARIADB_INIT_TIMEOUT) ?? 0,

    const dbConn = await mariadb.createConnection(dbConnectionData);

    const createSqlmapDemoDatabase = async () => {
      await dbConn.execute(
      await dbConn.end();

    await createSqlmapDemoDatabase();

    pool = await mariadb.createPool({
      database: process.env.MARIADB_DATABASE,
  } catch {
    await initPool();

export const getConnection = async <RT>(
  cb: (conn: PoolConnection) => Promise<RT> | RT
): Promise<RT> => {
  let conn;
  let res;

  try {
    conn = await pool.getConnection();
    res = await cb(conn);
  } catch (err) {
    throw err;
  } finally {
  return res;

export const initDatabase = async () => {
  await initPool();
Enter fullscreen mode Exit fullscreen mode

The initDatabase function calls the initPool function and creates tables in the database.

The initPool function creates a database if it doesn't exist. In the catch block, it calls itself to retry to connect the database. In the docker-compose.yml, which will be introduced in a later section, a web server container is connected with a database container with depends_on option, but since it doesn't mean the database is ready, reconnection logic was needed to ensure the web server is executed with connection the database. In a real project, it would be better to specify the error when a connection is failed.

Test Code

import supertest from 'supertest';

const request = supertest(process.env.TEST_URL ?? '');

describe('Sign Up', () => {
  const user = {
    username: 'test',
    password: 'test',

  test('should return BadRequest', (done) => {'/auth/sign-up').expect(400, done);

  test('should create a user', (done) => {'/auth/sign-up').send(user).expect(201, done);

  test('should have an existing username', async () => {
    const res = await'/auth/sign-up').send(user).expect(400);

    expect(res.body.message).toBe('username exists');

describe('Sign In', () => {
  const user = {
    username: 'signin',
    password: 'signin',

  beforeAll((done) => {'/auth/sign-up').send(user).expect(201, done);

  test('should be sucessfully signed in', (done) => {'/auth/sign-in').send(user).expect(200, done);

  test('should fail to sign in with wrong username', async () => {
    const res = await request
        username: 'wrongusername',

    expect(res.body.message).toBe('user does not exist');

  test('should fail to sign in with wrong password', async () => {
    const res = await request
        password: 'wrongpassword',

    expect(res.body.message).toBe('incorrect password');
Enter fullscreen mode Exit fullscreen mode

There are two APIs auth and todo. Test code retrieves the environment TEST_URL and requests to the URL.



In the root directory of the server, I created a Dockerfile file.

FROM node:18-alpine3.18


COPY . .

RUN npm install

CMD ["npm", "run", "dev:once"]
Enter fullscreen mode Exit fullscreen mode

The dev:once command is written in package.json like this

"dev:once": "ts-node src/app.ts",
Enter fullscreen mode Exit fullscreen mode

It executes the app.ts file using ts-code, and I used CMD to make it replaceable instead of ENTRYPOINT. It will also be used to execute another script.


version: '3.8'

    image: mariadb:11.2
    build: ../..
    env_file: ../../.env.test
      - mariadb
    build: ../..
    env_file: ../../.env.test
      - backend
    command: ['node', 'runTest.js']
Enter fullscreen mode Exit fullscreen mode

There are three services.

  • mariadb: It needs the admin password, I wanted to use the database password written in .env file because .env file contains the database password required for the connection. I didn't solve the problem, but now I think it could've been resolved by writing a script.

  • backend: It uses the Dockerfile located in the root path of the server. It depends on the maria-db service as a database is needed to run the server.

  • test: It needs the API server to test, it depends on the backend service. As I already mentioned, it doesn't mean that it waits until the web server is ready. So, I wrote a script to execute the test code when the server is available.

The services interact with each other using their names. For instance, the backend container accesses the database via db:3306.

By default, any service can reach any other service at that service's name.


const { spawn } = require('child_process');

const INTERVAL = 1000;

const runTestScriptIfServerIsReady = async () => {
  try {
    await fetch(process.env.TEST_URL);

    const test = spawn('npm', ['run', 'test']);

    const printAndCheckAllTestPass = (data) => console.log(data);

    test.stdout.on('data', printAndCheckAllTestPass);

    test.stderr.on('data', printAndCheckAllTestPass);

    test.on('exit', (code) => process.exit(code));
  } catch {
    setTimeout(runTestScriptIfServerIsReady, INTERVAL);

setTimeout(runTestScriptIfServerIsReady, INTERVAL);
Enter fullscreen mode Exit fullscreen mode

The logic checking if the server is ready is kind of straightforward. It figures the server is ready if the request, which fetches the test URL has no error.

It executes npm run test, then prints all output to the console and returns the exit code of the command. Therefore, we can see all the output on Github and if there is an error, the workflow will throw an error.

Github Action

name: Test

    branches: ['main']

  contents: read

    runs-on: ubuntu-latest
      - name: Checkout
        uses: actions/checkout@v4
      - name: Run test files
        uses: isbang/compose-action@v1.5.1
          compose-file: './server/docker/test/docker-compose.yml'
          up-flags: '--build --abort-on-container-exit'
Enter fullscreen mode Exit fullscreen mode

I selected isbang/compose-action after some research to run Docker Compose. I give the action the path of docker-compose and we need to give a close look at the --abort-on-container-exit flag. It stops all containers if any container was stopped.

With the flag, all the containers will be stopped when the test is done.

Github Action

Run Test task


It wasn't the purpose of the project though, it was a fun experience, Implementing what I wanted.

Things I struggled the most with are the following:

  • Using environment docker-compose.yml: I haven't resolved this issue yet. Initially, I believed the env_file could also be utilized within the docker-compose file itself. However, I later realized that environment variables can only be used within a container.
  • Delay executing a command until a specific container is ready: Since there are lots of frameworks and libraries out there, at some point, I started to google to find third parties that work perfectly for my cases and not even give it a try by myself, like a person who is finding a piece to my puzzle. But I realized that being aware of that we can make it work ourselves, of course, we can replace it with a better way later.

Thanks for reading this article. I hope you found it helpful!

You can check the full code here - Github.

Happy Coding!

Top comments (0)