Adds a test mode for convenience in test suites

[patbenatar]

@behrad First pass at implementing something for #560. See README change for details on use. Thoughts?

[behrad]

thank you for this @patbenatar
couldn't it be

mock = require('kue').createMock(); // or createMockQueue
// mock contains all Queue methods...

adding a test mode to existing Queue singleton complicates things... I prefer to have a mock and a queue object side by side :)

[patbenatar]

@behrad My intention was for the code under test to not have to change in order to support this test mode—it continues to use the queue as it would at actual runtime. Adding the ability to create mock queues would work well if the system under test uses dependency injection everywhere, but how would it handle the case where you don't control the queue object that a system is using?

Consider this contrived example:

// thing.js
var queue = require('kue').createQueue();

module.exports = function() {
  queue.createJob('myJob');
};

// thing_test.js
var thing = require('./thing');

it('enqueues myJob', function() {
  thing();
  // expect job to be queued by inspecting the queue singleton
});

Compared to the dependency injected version:

// thing.js
module.exports = function(queue) {
  return function() {
    queue.createJob('myJob');
  };
};

// thing_test.js
var queue = require('kue').createMockQueue();
var thing = require('./thing')(queue);

it('enqueues myJob', function() {
  thing();
  // expect job to be queued by inspecting mock queue
});

The DI version would be pretty easy to inject a mock without any support from kue library, perhaps using something like sinon.

The non-DI version needs some manipulation of the queue singleton so that both the test suite and code under test are operating on the same object.

I hope that sheds some light into why I went this route.. in my current use case, the system under test is an existing system that does not use DI in a way that would accommodate injecting a mock queue. I tried to isolate all of the test stuff under queue.testMode and by providing enter and exit, test cases can individually decide to turn on/off the test mode, restoring the queue to its natural non-test state after the case completes.

[jdwolk]

@patbenatar 👍 super handy!

[behrad]

@patbenatar got your point, will return to this in days...

[patbenatar]

@behrad Sounds good. We're using my fork in the meantime and I'll post back if we run into issues or improvements.

[behrad]

👍 @patbenatar