How can i use sinon to stub functions for neo4j Thingdom module

I am having some issues writing some unit tests where i would like to stub out the functionality of the neo4j Thingdom module.

After a few hours of failed attempts i have been searching around the web and the only point of reference i found was a sample project which used to sinon.createStubInstance(neo4j.GraphDatabase); to stub out the entire object. For me, and becuase this seemed to a be a throw away project i wanted a more fine grained approach so i can test that for instance as the Thingdom API outlines when saving a node you create it (non persisted) persist it and then you can index it if you wish which are three calls and could be outlined in multiple specific tests, which i am not sure can be achieved with the createStubInstance setup (i.e. found out if a function was called once).

Example "create node" function (this is just to illustrate the function, i am trying to build it out using the tests)

User.create = function(data, next){
    var node = db.createNode(data);

    node.save(function(err, node){
        next(null,node);
    });
};

I am able to stub functions of the top level object (neo4j.GraphDatabase) so this works:

    it('should create a node for persistence', function(){
        var stub = sinon.stub(neo4j.GraphDatabase.prototype, 'createNode');

        User.create({}, res);

        stub.calledOnce.should.be.ok;
        stub.restore();
    });   

The issue comes with the next set of test i wish to run which tests if the call to persist the node to the database is called (the node,save) method:

I am not sure if this is possible or it can be achieved but i have tried several variations of the stub and non seem to work (on neo4j.Node, neo4j.Node.prototype) and they all come back with varying errors such as can't wrap undefined etc. and this is probably due to the createNode function generating the node and not my code directly.

Is there something i am glaringly doing wrong, am i missing the trick or can you just not do this? if not what are the best tactics to deal with stuff like this?

A possible solution is to return a stubbed or mocked object, giving you control on what happens after the node is created:

it('should create a node for persistence and call save', function () {
    var stubbedNode = {
        save: sinon.stub().yields(undefined, stubbedNode)
    };

    var stub = sinon.stub(neo4j.GraphDatabase.prototype, 'createNode').returns(stubbedNode);

    User.create({}, res);

    stub.calledOnce.should.be.ok;
    stub.restore();
    stubbedNode.save.calledOnce.should.be.ok;
});

We couldn't do it directly, the way the module is setup it doesn't work to well with Sinon. What we are doing is simply abstracting the module away and wrapping it in a simple facade/adapter which we are able to stub on our unit tests.

As we are not doing anything bar calling the neo4j module in that class we are integration (and will validate when regression testing) testing that part to make sure we are hitting the neo4j database.