chore: setup scaffolding for backend tests

[miazima]

Setup base scaffolding for backend tests.

The main testing framework used is jest. I considered using mocha and chai as alternative, but concluded on jest so that we use a common testing framework across frontend and backend.

Testing related frameworks/libraries used:

• Jest
• SuperTest (facilitates testing HTTP endpoints)
• redis-mock

Addresses #880

Mocking database queries
sequelize-mock does not actually carry out db queries. Instead we mock query results by queuing the expected results e.g. UserMock.$queueResult()

Database queries
In the previous implementation, I had used sequelize-mock to mock sequelize query return values. After discussion with the team, we decided that database queries were a essential part and it would be better to test them with real queries instead.

Mocking user session
A valid user session is introduced by intercepting the request and modifying req.session object. This is used for all routes that require authentication.

• This may not be the ideal solution is it doesn't allow us to write tests with the presence and absence of a valid user session as needed.
• The auth routes does not have a user session mocked which makes testing auth/userinfo difficult as it is not possible to test with and without an user session

Improvements:

• include tests folder in tsconfig.json and exclude from build files
• move all tests to tests folder
• add tests for authentication and campaign routes endpoints

Tests

Run all tests npm test

Deploy Notes

New dev dependencies:

• supertest
• redis-mock
• @types/redis-mock
• @types/supertest

[lamkeewei]

When running the tests, the following warning is raised:

A worker process has failed to exit gracefully and has been force exited. This is likely caused by tests leaking due to improper teardown. Try running with --runInBand --detectOpenHandles to find leaks.

We might want to look into this.

Another thing to note is that jest runs tests in different files in parallel unless --runInBand is set. This might be an issue if we have tests in each file interfering with each other. E.g. Test in auth deletes a user with email test@test.com while another test in campaign tries to create a campaign belonging to test@test.com.

One way this can be solved is to ensure that each test suite runs in a separate namespace-ed db (e.g. postmangovsg_test_auth) by passing an argument to seqeulizeLoader. This db can be torn down at the end of each test suite. We want to avoid setting --runInBand due to the performance hit to tests since all test suite are now run serially.

Found this link that might be useful. They namespace-ed the test database based on the Jest worker ID.

[miazima]

I am manually creating test databases here instead of generating them dynamically, I also restricted the number of jest workers to be the same number of test dbs created

[lamkeewei]

Would it make sense to do this initialisation and the subsequent teardown in the globalSetup and the globalTeardown step? Just thinking along of lines of making it easier when running in dev so that he/she wouldn't have to remember to create/drop the two test db.

[lamkeewei]

lgtm! Left a minor remark about the creation of the test databases. Noted that this is just the scaffold, so I didn't check if all the required flows were addressed.

[miazima]

I've refactored the initial setup to include a globalSetup file, however environmental variables are not loaded during globalSetup so I defined them within the file.

[miazima]

@lamkeewei made some changes to the db setup, could you have a final look before we merge this

[lamkeewei]

@lamkeewei made some changes to the db setup, could you have a final look before we merge this

lgtm! Tested the creation of test database in global setup function and works as expected.