When using test sites on a site with code, it is important to understand how the different versions of your site work with the following features.
When you have both a published revision and a test site revision of your site, you still only have 1 version of your site's database collections that both revisions access. That means, when you perform a data operation such as updating an item from either your published or test site revision, the change affects both of your site revisions.
While your data does not change based on the site revision, your database schema may differ from revision to revision. This means that a field that exists in the schema in the test site revision may not exist in the schema in the published revision. Because collection data itself is maintained regardless of whether a field is in the schema, this should not affect the functionality of your site revisions.
Currently your site must be published at least once for the version of the event handler in your test site to run when a backend event on your test site is triggered.
For example, let's say you have a onNewOrder event that handles new events in your store. In your published site your event handler sends an email to p@supplier.com for each order received, but in your test site the same event handler sends an email to rc@supplier.com. Whenever a site visitor places an order on your test site, an email is sent to rc@supplier.com.
If you define a backend event handler in your test site revision without ever publishing the site, messages in backend code are not logged to the browser's console and the event handler never runs.
Keep in mind that messages in backend code are not logged to the browser's console.
When you schedule jobs in your site's backend, only the jobs scheduled in your published site revision run. The jobs scheduled in your test site revision do not run.
To use service plugins in your test site revision, make sure to publish your site once after implementing the plugin. After that first initial publish, the service plugin implementation works on your test site revision.
If the site hasn't been published, the published revision's implementation runs. Neither the published revision nor the test site revision runs your latest service plugin code.
Currently the Realtime API is partially supported for test sites. Keep the following considerations in mind:
realtime_check_permissions and PermissionsRouter are not supported on test site revisions.
When publishing/subscribing to messages on a channel in both test site and published revisions, both sites receive messages from both versions. This means that the published site receives the messages from both the published site's backend and the test site's backend. Similarly, the test site receives the messages from the test site's backend and the published site's backend. It isn't possible to add new message types on the same channel with the aim to test it only in the test site revision because the published revision also receives the new message. This might cause unexpected behavior.