I am trying to write unit tests in javascript for an application made in nodejs. What I want to know is -

Say there is a class Vehicles which is dependent on another class Roads.

  1. Should I mock the Roads class and send it as a parameter to Vehicles for unit testing? OR Should I just create a new object and send it as a parameter to Vehicles?

  2. If I change the Roads class I will have to change the mocking every where?

  3. Should I use a factory to create mocked objects?


You should mock the Roads class if

  • It is expensive or difficult to create, or
  • Its operations are expensive, or
  • You need precise control over what the operations return and when they generate an error.

With expensive, I mean that it is generally consuming a lot of time (for example, communication across a network).

If you change the interface of the Roads class, then you need to update all the mocks and clients of it, but that should not be a consideration for whether or not to use a mock. If you just change the implementation without affecting how it responds to the 'outside world', then there is no need to change anything in that 'outside world'.

A factory for mock object should only be used if the class-under-test needs a factory to get (some of) the objects it needs from. Otherwise, it is just an additional complication for no gain.

  • thanks! So in case Roads is not taking time for any operations I can pass a real object? Is it really unit testing then? Since I am still dependent on the Roads object? – tusharmath May 19 '13 at 10:58
  • @TusharMathur - you're creating an instance of road in your test and injecting that into the vehicle? – JeffO May 19 '13 at 12:21
  • @Jeffo, Yes. That is what I think is the right way of doing it. – tusharmath May 19 '13 at 12:59
  • @TusharMathur: You can do that, but it is advisable to do it only with well-tested classes. Otherwise, you won't know if the test failure is due to a bug in Vehicle or in Roads. – Bart van Ingen Schenau May 19 '13 at 15:57

Technically, you need to mock everything that is accessed from your unit, otherwise you're testing your unit of code and the code that it references. Now, obviously this can be impractical in the real world, so we tend to mock only the bigger aspects of the code, eg if your roads class called a DB to get some data, we'd mock the entire interface to the DB.

Its up to you how much effort you put in to make your code mockable, sometimes it can be a real pain altering your code so it uses interfaces (subject to language that requires this, eg .net, YMMV with javascript), but also it can be good practice to do this. The trick is knowing how far down that road to travel - too much and you have unmaintainable code that's so decoupled you can take days to trace what its supposed to do.

You don't need a factory, instead use a mocking framework that will automatically replace calls to your mocked object with its own that returns a fixed result, eg from Sinon.js

Not the answer you're looking for? Browse other questions tagged or ask your own question.