add serverside testing

[timmyichen]

• I have read Chapter's contributing guidelines.
• My pull request has a descriptive title (not a vague title like Update README.md).
• My pull request targets the master branch of Chapter.

Adds serverside testing:

• Adds custom App class with all the setup/takedown for tests
• Adds tests for the three routes defined in exampleRouter.ts
• Pulls out jest config from package.json into external jest.config.js since it was getting quite long
• Uses docker-compose for testing since we will need it once the database is integrated

I'm not sure what best practices are for this so let me know how this pattern looks and any feedback you might have. Thanks!

TODOS:

• fix client tests
• update docs

[vaibhavsingh97]

The PR looks good to me

[timmyichen]

Gonna wait to rebase with #146 before continuing

[vaibhavsingh97]

@timmyichen I think you forgot about this PR 😛, pinging you so that we can merge once you update this PR 😃

[timmyichen]

@vaibhavsingh97 still waiting on #146 🙃

[QuincyLarson]

In summary: this is blocked by NodeMailer. Once we include NodeMailer we will be able to return to QA'ing this.

[vaibhavsingh97]

LGTM 🔥 , just a minor concern

[vaibhavsingh97]

Env variables will grow in the future, shouldn't we maintain separate .env

[timmyichen]

for the most part, there's no functional difference between having a long list of env variables in the docker-compose file and a long list of env variables in .env. With a separate .env file, you are requiring people to copy/rename a file before running it whereas this will be set up when you run docker-compose up.

[Zeko369]

For the sake of simplicity I think that for now we should stick with env vars in docker-compose, but maybe later when we have a lot of them we could extract them.

[vaibhavsingh97]

@timmyichen can you please resolve merge conflicts

[timmyichen]

sorry about the delay - done!