Sample Test

auth.test.js

import chai from 'chai';
import chaiHttp from 'chai-http';
import app from '../server';

// configure chai to use expect
chai.use(chaiHttp);
const { expect } = chai;


describe('Authentication tests', () => {
  context('POST /', () => {
    
    /*
    ** Testing Account Logout
    */
    
    it('/api/v1/auth/logout should respond with status code 200 and log user out', (done) => {
      chai.request(app)
        .post('/api/v1/auth/logout')
        .set('x-access-token', authTokenAdmin)
        .end((err, res) => {
          expect(res.status).to.equal(200);
          expect(res.body).to.be.a('object');
          expect(res.body.auth).eql(false);
          expect(res.body.token).eql(null);
          done();
        });
    });
  });
});

@NedyUdombat, nice work!

• On your file naming convention, in my opinion, when this application gets large, it may become difficult to pick out your test files with a script, compared to when you use auth.spec.js or auth.test.js. However, you may have a better reason. I will be happy to know.
• Usually, I will have an outermost describe block where I put the after() function to close the server, when my testing is done. This way, unplanned errors like two ports trying to read from the same port is avoided.

I think you have a comprehensive test. Well done!

@nwamugo Thank you for the feedbacks,
I will promptly reflect and implement these feedbacks as soon as possible

However I have to point out that chai-http listens for when 'app' is passed to a request and opens up the server and closes it once the request has been made. here. This is the reason for not using the after() function

@NedyUdombat, nice work!

• On your file naming convention, in my opinion, when this application gets large, it may become difficult to pick out your test files with a script, compared to when you use auth.spec.js or auth.test.js. However, you may have a better reason. I will be happy to know.
• Usually, I will have an outermost describe block where I put the after() function to close the server, when my testing is done. This way, unplanned errors like two ports trying to read from the same port is avoided.

I think you have a comprehensive test. Well done!

@nwamugo Thank you for the feedbacks,
I will promptly reflect and implement these feedbacks as soon as possible

However I have to point out that chai-http listens for when 'app' is passed to a request and opens up the server and closes it once the request has been made. here. This is the reason for not using the after() function

This thing on chai-http, I am just learning it today. Thank you for enlightening.

I know I have given some feedback already, however I observe that considering our airbnb style, your code has not allowed for an extra line after the last line of code.

Thank you for the insights. It's a huge learn for me today. Cheers

@NedyUdombat, nice work!

• On your file naming convention, in my opinion, when this application gets large, it may become difficult to pick out your test files with a script, compared to when you use auth.spec.js or auth.test.js. However, you may have a better reason. I will be happy to know.
• Usually, I will have an outermost describe block where I put the after() function to close the server, when my testing is done. This way, unplanned errors like two ports trying to read from the same port is avoided.

I think you have a comprehensive test. Well done!

@nwamugo Thank you for the feedbacks,
I will promptly reflect and implement these feedbacks as soon as possible

However I have to point out that chai-http listens for when 'app' is passed to a request and opens up the server and closes it once the request has been made. here. This is the reason for not using the after() function

Equally, I think that's also the essence of using done() at the end of each test. It signifies the end of the test. One thing I think about though is putting the done() call into the afterEach hook so one doesn't have to do it at the end of each test.