Mocking with Sinon against a service module

before I try, I would like to suggest to drop the try/catch blocks everywhere, I will assume you're using expressJs in your Node application, and for such, take a look at express-promise-router as using that Router (instead the default one) will automatically catch anything it was thrown and you just need to focus on the code...

taking your example, you would write:

const { addUserToDb } = require('../database/user.db');

const createUser = async (user) => addUserToDb(user);

module.exports = {
  createUser,
};

and

const { createUser } = require('../services/user.service');

const apiResponse = require('../helpers/apiResponse');

const postUser = async (req, res) => {
    const { id: account_id, status } = res.body;
    const result = await createUser({ account_id, status }); // set the date in the fn
    return apiResponse.successResponseWithData(res, 'User added.', result.affectedRows);
};

module.exports = {
  postUser,
};

if there's an error and in some place on the route an error is thrown, you will get a nice message back in the response with the error

regarding the code it self, seems a lot cleaner to read - keep in mind that code is for humans, the machine does not even care how you name your variables

Now, regarding the tests ... I do tend to split things into 3 parts

• unit tests: the functions itself, single one, like validation, helpers, etc
• integration tests: when you call your API endpoint what should be returned
• GUI tests (or end-to-end/e2e): applied when a GUI exists, will skip this for now

so in your case, the first thing to make sure of is what are you testing... and taking that, start from the small blocks (unit tests) and move up to the blocks that make sure all is glued together (e2e)

So all it really does is validate, and then creates a user object with the req and pass that to a service class. This services class does nothing more than pass the data to a database class.

Seems a great way to start, so it "validates" ... let's test our validation, let's pass null, undefined, string when all you want is int and so on, until we get a pretty good idea that whatever it passes, we will reply correctly with and without an error

Note I tend to use OpenAPI specs, which makes things easier for me as it provides 2 things

• documentation of the endpoints
• validation of the endpoints with a nice error message to the consumer

and yes, I always test some validation just to make sure it's working as expected, even though I trust the tool 100%

So from what I understand, I should be testing functions.

well, an application is a group of functions, so all good there

If a function makes an external call, I should spy, mock, stub that call?

I'll try to explain as best as I can what spies, stubs and mocks in Sinon are, please be gentle

Spies

they tell us information about functions calls, like, number of times called, arguments, return value, and more - they have two types, anonymous spies or spies that wrap methods in our code

function testMyCallback(callback) { callback(); }

describe('testMyCallback fn', function() {
  it('should call the callback', function() {
    const callbackSpy = sinon.spy(); // anonymous spy - no arguments
    testMyCallback(callbackSpy);
    expect(callbackSpy).to.have.been.calledOnce;
  });
});

const user = {
  setNname: function(name) {
    this.name = name;
  }
}

describe('setname fn', function() {
  it('should be called with name', function() {
    const setNameSpy = sinon.spy(user, 'setName'); // wrap method spy
    user.setName('Katie');
    expect(setNameSpy).to.have.been.calledOnce;
    expect(setNameSpy).to.have.been.valledWith('Katie');

    setNameSpy.restore(); // to remove the Spy and prevent future errors
  });
});

Stubs

are power-spies, as they have all the functionality of Spies, but they replace the target function, they have methods that can return a specific value or throw a specific exception and a bit more

they are great to be used with your question regarding external calls, as they replace calls (so you can mock the call behavior and never use the original call)

the simplest of the examples is:

function isAdult(age) {
  return age > 21;
}

describe('Sinon Stub Example', () => {
  it('should pass', (done) => {
    const isAdult = sinon.stub().returns('something');
    isAdult(0).should.eql('something');
    isAdult(0).should.not.eql(false);
    done();
  });
});

we've STUB'ed our function, and explicitly said it's a "function" that returns a string something... and for now on, we will never need to go to the function itself, as we have STUB it, we've replaced the real behavior with our own

another example of using STUBs when calling our API application in our integration tests

describe('when we stub our API call', () => {
  beforeEach(() => {
    this.get = sinon.stub(request, 'get'); // stub "request.get" function
  });

  afterEach(() => {
    request.get.restore(); // remove our power-spy
  });

  describe('GET /api/v1/accounts', () => {

    const responseObject = {
      status: 200,
      headers: {
        'content-type': 'application/json'
      }
    };
    const responseBody = {
      status: 'success',
      data: [
        {
          accountId: 1,
          status: 'active'
        },
        {
          accountId: 2,
          status: 'disabled'
        }
      ]
    };

    it('should return all accounts', (done) => {
      // the 3 objects of our callback (err, res, body)
      this.get.yields(null, responseObject, JSON.stringify(responseBody));

      request.get(`${base}/api/v1/movies`, (err, res, body) => {
        expect(res.statusCode).to.be.eql(200);
        expect(res.headers['content-type']).to.contain('application/json');

        body = JSON.parse(body);
        expect(body).to.be.an('array').that.includes(2);
        done();
      });
    });
  });
});

you can also stub axios, but you will need a new library, either moxios, or proxyquire or more...

Mocks

are a bit similar to Stubs (our Power-Spies) but they can be used to replace whole objects and alter their behavior, they are mostly used when you need to stub more than one function from a single object - if all you need is to replace a single function, a stub is easier to use

Mocks can make things oversimplify and you could break your application without even knowing, so be aware...

a normally use is, for example

function setupNewAccount(info, callback) {
  const account = {
    account_id: info.id,
    status: info.status,
    created_at: new Date(),
    updated_at: new Date()
  };
  try { Database.save(account, callback); }
  catch (err) { callback(err); }
}

describe('setupNewAccount', function() {
  it('', function() {
    const account = { account_id: 1, status: 'active' };
    const expectedAccount = {
       account_id: account.id, status: account.status
    };
    const database = sinon.mock(Database);

    database.expectes('save').once().withArgs(expectedAccount);

    setupNewAccount(account, function() {});

    database.verify();
    database.restore();
  });
});

something that we will keep forgetting is the .restore() part, and for that, there's a package (one more...) called sinon-test that will auto cleanup at the end of a test

I just hope it helped you with some of your questions and it's a bit clearer now

BTW, for stubbing HTTP requests, I use nock as I think it's much easier to read and use than Sinon, especially for anyone that is reading code for the first time and has no experience in either Sinon or Nock...