Oracle Coherence is an in memory Data Grid framework, data replication and distributed services.In fact Coherence is a sort of  data store. To test or debug data access code can be quite complicated. You need to set up test data, perform the test, and then clean up after each test, in order to ensure that it does not influence the outcome of another test.
There are no real tools for Coherence to use, but in fact they are not necessary .
Setting up test data can be as simple as creating a bunch of  files and using the Coherence CacheLoader to import them into the coherence cache.
Clearing data from the cache between the tests is even simpler—just call the clear command from the Coherence commandline ( to be started with coherence.sh or coherence.cmd).
Coherence is not only a data store, but a distributed processing engine aswel. When you execute a query or an aggregator ( like in Oracle Service Bus), it executes across all the nodes in the cluster. When you execute an entry processor, it might execute on all nodes in parallel, depending on how it was invoked.
For the most part, you can test the code that executes within the cluster the same way you test more conventional data access code, by having each test case start a
one-node cluster. This makes debugging quite simple, as it ensures that all the code, from test, to Coherence, to your custom processing code executing within Coherence
runs in the same process.
You should be aware that this way of testing won’t be in a repesentable environment. All kinds of things change internally when you move from a one-node cluster to two-node cluster. For example, Coherence will not create backups in a single-node setup, but it will as soon as the 2nd node is added to the cluster.
In some cases you might have to test and debug your code in a true distributed environment, because it depends on things that are only true if you are in clustered mode.
Debugging in a distributed environment can be quite trivial. You will need to enable remote debugging on a cache server node by adding the following JVM arguments to DefaultCacheServer run configuration( to be set in the coherence-cache-config.xml):
-Xdebug
-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005
Also you need to ensure that all the data is stored on a cache server node where remote debugging is enabled. That will ensure that the code you need
to debug within the cluster, such as the entry processor mentioned earlier, is guaranteed to execute on that node.
Even though you will only be able to start one DefaultCacheServer now ( the remote debug port it is set to it), as soon as your test invokes any
CacheFactory method it will join the cluster as a second node. By default, the data is balanced automatically across all the nodes in the cluster, which will make it
impossible to ensure that your processor executes where you want.
If you’d like to disable one node of storing cache data, you simply I add the following JVM argument to your configuration( also again in the coherence-cache-config.xml):
-Dtangosol.coherence.distributed.localstorage=false
In this picture you can see 2 JVM are not writing cache locally ,so it’s easier to test and debug because you configured them to false
