For background, you should at least skim-read the paper Transient Astronomy with ACP Scheduler (PDF).
The VOEvent Receiver Utility menu has items for generating test events. You can use these to test your filter and observing templates together with the simulation mode of the Scheduler, with ACP in simulation mode, or with ACP in live mode. This provides lots of ways you can check out your VOEvent observing setup.
The menu provides for generating test events for Swift, INTEGRAL, Catalina, and two user-specified event types. For each type, there are sub-options for generating events which are observable now, not observable now but observable soon, and with a time stamp 2 hours in the past. Each of these provides an event that checks out a different aspect of the system. The "observable now" is the most commonly used. It generates an event of the selected type which has coordinates which describe a point in the sky that is observable now. The "not yet observable" option generates an event which has coordinates 5 degrees below the horizon (as set in the scheduler simulator or ACP), so it will become observable "soon". The "2 hours old" option generates an event with a time stamp 2 hours in the past. The latter two are primarily useful in verifying the operation of the VOEvent receiver, but can also be useful if your filter pays attention to position and/or the event time.
Making test event templates requires detailed knowledge of the XML VOEvent message format. You should probably have a tool such as Liquid XML Studio (which is free) to make sure your messages conform to the VOEvent Schema.
As you might expect, the test events are constructed using templates. For each event type, there is a template VOEvent message in the ReceiverData folder. They are named after the three-letter code of the event type (SWF, INT, CAT, US1, and US2). For example the template for Swift (SWF) is FakeEventTemplateSWF.xml. To generate the test event, the receiver reads the selected template then performs the following substitutions:
Then, if Digital Signatures are enabled, the newly constructed test event is digitally signed.
Once constructed, the test event is inserted into the "incoming event queue" of the receiver. At this point, the receiver cannot tell the difference between an event received from the network and the test events. The event message flows through the normal process of pre-patching, parsing, filtering, etc.