What it does is save you the hassle of writing cleanup code to revert any configuration changes your test makes. It saves a snapshot of the xml config before your test runs and then when the test class is done reloads the server using that snapshot. Voila, all config changes magically gone!

But like all dark magic, there's a hidden cost.

The problem is reloading to an earlier snapshot is not the same thing as executing management ops to reverse out changes. Management ops don't just change the model, they change runtime resources, and those runtime resource may persist state outside the xml file, e.g. in the data dir. A management op like a 'remove' may result in that persisted state being cleaned up, but a simple reload to a snapshot will not. And that leftover state may have mysterious side effects later.

The messaging-activemq subsystem seems like a place to be particularly careful.
--