docs: add more details to unit test section

Author: jescalada

website/docs/development/testing.mdx

@@ -85,3 +85,102 @@ describe('auth methods', async () => {
 ```
 
 Core concepts to keep in mind when unit testing JS/TS modules with Chai:
+
+#### Stub internal methods to make tests predictable
+
+Functions often make use of internal libraries such as `fs` for reading files and performing operations that are dependent on the overall state of the app (or database/filesystem). Since we're only testing that the given function behaves the way we want, we **stub** these libraries.
+
+For example, here we stub the `fs` library so that "reading" the `proxy.config.json` file returns our mock config file:
+
+```js
+// Define the mock config file
+const newConfig = JSON.stringify({
+  authentication: [
+    { type: 'local', enabled: true },
+    { type: 'ActiveDirectory', enabled: true },
+    { type: 'openidconnect', enabled: true },
+  ],
+});
+
+// Create the stub for `fs.existsSync` and `fs.readFileSync`
+const fsStub = {
+  existsSync: sinon.stub().returns(true),
+  readFileSync: sinon.stub().returns(newConfig),
+};
+```
+
+This stub will make all calls to `fs.existsSync` to return `true` and all calls to `readFileSync` to return the `newConfig` mock file.
+
+Then, we use `proxyquire` to plug in the stub to the library that we're testing:
+
+```js
+const config = proxyquire('../src/config', {
+  fs: fsStub,
+});
+
+// Initialize the user config after proxyquiring to load the stubbed config
+config.initUserConfig();
+```
+
+Finally, when calling the function we're trying to test, the internal calls will automatically resolve to the values we chose.
+
+#### Setup and cleanup
+
+`before` and `beforeEach`, `after` and `afterEach` are testing constructs that allow executing code before and after each test. This allows setting up stubs before each test, making API calls, setting up the database - or otherwise cleaning up the database after test execution.
+
+This is an example from another test file (`test/addRepoTest.test.js`):
+
+```js
+before(async function () {
+  app = await service.start();
+
+  await db.deleteRepo('test-repo');
+  await db.deleteUser('u1');
+  await db.deleteUser('u2');
+  await db.createUser('u1', 'abc', 'test@test.com', 'test', true);
+  await db.createUser('u2', 'abc', 'test2@test.com', 'test', true);
+});
+
+// Tests go here
+
+after(async function () {
+  await service.httpServer.close();
+
+  await db.deleteRepo('test-repo');
+  await db.deleteUser('u1');
+  await db.deleteUser('u2');
+});
+```
+
+#### Focus on expected behaviour
+
+Mocha and Chai make it easy to write tests in plain English. It's a good idea to write the expected behaviour in plain English and then prove it by writing the test:
+
+```js
+describe('auth methods', async () => {
+  it('should return a local auth method by default', async function () {
+    // Test goes here
+  });
+
+  it('should return an error if no auth methods are enabled', async function () {
+    // Test goes here
+  });
+
+  it('should return an array of enabled auth methods when overridden', async function () {
+    // Test goes here
+  });
+});
+```
+
+Assertions can also be done similarly to plain English:
+
+```js
+expect(authMethods).to.have.lengthOf(3);
+expect(authMethods[0].type).to.equal('local');
+```
+
+#### Unit testing coverage requirement
+
+**All new lines of code introduced in a PR, must have over 80% coverage** (patch coverage). This is enforced by our CI, and generally a PR will not be merged unless this coverage requirement is met. Please make sure to write thorough unit tests to increase GitProxy's code quality!
+
+If test coverage is still insufficient after writing your tests, check out the [CodeCov report](https://app.codecov.io/gh/finos/git-proxy) after making the PR and take a look at which lines are missing coverage.