Event Scripts

You can now write tests for parts of the file-system monitor using JSON to describe the events that you expect to see. Both file system events and monitor events can be described. This is kind of interesting because these events nominally live on different timelines and normally we can't really know much about exactly when they occur. By merging the time streams into a single event sequence, however, we can replay scenarios that express any kind of timing relationship that we like.

The following diagram illustrates a case of interest. The idea is that we want to suppose that a file is modified and then renamed. We can express this sequence of operations using the following script:

[
  { "type": "write", "name": "{0}/f1", "content": "Hello world" },
  {  "type": "rename",  "from": "{0}/f1",  "to": "{0}/f2" }
]

The FileWatcher would give the following events to the monitor as a result of these changes:

[
  {
    "type": "watch-event",
    "event": {
      "root": "{0}",
      "create_path": "f1", "delete_path": null, "modify_path": null
    }
  },
  {
    "type": "watch-event",
    "event": {
      "root": "{0}",
      "create_path": "f1", "delete_path": null, "modify_path": null
    }
  },
  {
    "type": "watch-event",
    "event": {
      "root": "{0}",
      "create_path": null, "delete_path": null, "modify_path": "f1"
    }
  },
  {
    "type": "watch-event",
    "event": {
      "root": "{0}",
      "create_path": "f2", "delete_path": null, "modify_path": null
    }
  },
]

At this point, can build a real test by interleaving these two scripts. Different interleaving could give us different test cases. For instance, the Monitor may receive the notification of the modification of f1 before or after the file system sees the rename event. Getting the event before the rename is no problem (the solid line), but getting it after makes the test considerably harder (the dashed line).

More details on event scripting can be found [here](Event Scripting).