The interface you're suggesting ("a list of job events to trigger...you could add more params to event specs, like a time (in ms offset from job creation) to trigger them") sounds like the interface that's exposed by `MockJob`, e.g.:

```coffee
job = new MockJob().delayEmit('data', 1000, 1).delayEmit('data', 2000, 2).delayEmit('complete', 3000)
```

Maybe the example here should use the base MockJob class instead of the child classes (`CompleteJob` and `DataJob`) that have more behavior built in.

The reason that we use a set of class objects is so that we can have things like CompleteJob and DataJob, that have a lot of the behavior you want in the majority use case predefined, so you don't have duplicate as much code. Otherwise, everywhere you wanted to mock "a job that sends back data", you'd need something like

```coffee
client.registerTask 'worker_name', [
  event: 'data', args: data_args[0]
  event: 'data', args: data_args[1]
  event: 'data', args: data_args[2]
  event: 'complete'
]
```

I think `new DataJob data_args` compares favorably to that.