Vows: Testing Asynchronous Interleaving

Question

Is there a methodology to test (potential) interleaving of asynchronous functions with vows?

For example:

// Topic portion
var user = new User('jacob')
user.set('email,'foo@bar.com')
user.save() // a
user.set('email',derp@cherp.com')
user.save() // b
user.refresh(this.callback) // Reload from database

// Callback
assert.equals(user.email,'derp@cherp.com')

There is could be a race condition between the two saves. When writing my tests I want to ensure that my API is ensuring that b finishes last (and that we have the correct final value for the email). With the way that's it written, the test will pass coincidentally some of the time.

Is there a callback for the `save()` function? – fent Dec 25 '11 at 10:48 — fent, Dec 25 '11 at 10:48

score 1 · Answer 1 · answered Dec 25 '11 at 04:59

1

Heres the example from the vows docs:

The nested contexts act as nested callbacks and pass the return arguments to the next context.

Docs: http://vowsjs.org/

{ topic: function () {
    fs.stat('~/FILE', this.callback);
  },
  'after a successful `fs.stat`': {
    topic: function (stat) {
      fs.open('~/FILE', "r", stat.mode, this.callback);
    },
    'after a successful `fs.open`': {
      topic: function (fd, stat) {
        fs.read(fd, stat.size, 0, "utf8", this.callback);
      },
      'we can `fs.read` to get the file contents': function (data) {
        assert.isString (data);
      }
    }
  }
}

answered Dec 25 '11 at 04:59

Chris Biscardi

3,148
2
20
19

This is actually the opposite of what I want. I actually want to test and make sure my race conditions don't occur without explicitly forcing the test code to be written in a synchronous manner - the goal is to make the api transparent. But perhaps this is going against the grain of node anyway. The gist is, I want to queue saves() behind the scenes. – Koobz Dec 25 '11 at 05:06
This eliminates your race condition. The undesirable timing of sequences is eliminated by the use of callbacks. I could post the parallel code that would potentially execute in a non-sequential manner. – Chris Biscardi Dec 25 '11 at 05:12
It sounds like you want to force your server to rectify race conditions in your client side code, which would be impossible due to the nature of latency between client and server. Is this correct? – Chris Biscardi Dec 25 '11 at 05:18
It's all server-side at the moment. The goal was to be able to write the commands in a manner that looks like synchronous code (none of the commands block the topic portion of the code, though they must wait for each other to complete e.g. by queuing up so `save b` wouldn't run until `save a` had completed). The hope is to get some syntactic sugar and to make it somewhat transparent. E.g. the save operation doesn't issue a request immediately to the database, it instead queues that request. If the queue is empty it'll be executed immediately, otherwise it's deferred. – Koobz Dec 25 '11 at 22:46

Vows: Testing Asynchronous Interleaving

1 Answers1