-1

I intend to write integration tests with Cucumber for a GemFire cache client application using Spring Boot and deployed in an Apache Geode client/server topology. I referred to the question - How to start Spring Boot app without depending on Pivotal GemFire cache which was answered in 2018 and also referred to the integration test documentation here - Integration Testing with STDG. The link to an example concrete client/server Integration Test extending STDG’s ForkingClientServerIntegrationTestsSupprt class appears to be broken.

The purpose of my integration tests would be to:

  • run an embedded locator and a server during the integration test phase
  • define the regions for the servers using cluster.xml
  • create, read, update and delete cache entries and verify the different use cases

Any help regarding the ideal approach to write integration tests (probably using an embedded GemFire locator and server) will be very helpful.

Tried an embedded GemFire CacheServer instance for integration tests using @CacheServerApplication annotation but not sure on how to create ClientCache objects to use the embedded GemFire or whether this is the right way to write the integration tests.

Edit: Also came across this - Is it possible to start a PIvotal GemFire Server, Locator and Client in one JVM? where it is mentioned as - In short, NO, you cannot have a peer Cache instance (with embedded Locator) and a ClientCache instance in the same JVM (or Java application process).

John Blum
  • 7,381
  • 1
  • 20
  • 30
pradhan
  • 1
  • 3
  • If you are using Maven you can use the `pre-integration-test ` phase to start one or more applications. Then test against them with `failsafe`. – M.P. Korstanje Dec 25 '22 at 12:22

1 Answers1

0

DISCLAIMER: I do not have experience with Apache Cucumber...

However, it is not difficult to spin up multiple GemFire or Geode server-side processes, such as 1 or more Locator and [multiple] CacheServers in a single test class. The Locators can be standalone JVM processes or embedded, as part of the servers.

In this typical test configuration arrangement the GemFire or Geode server-side processes are forked, yet coordinated, and the test class itself acts as the ClientCache instance.

You can see 1 such test configuration in the SBDG Multi-site Caching sample, here.

The key to this test configuration is the extension of the ForkingClientServerIntegrationTests class from STDG, as well as the forking of the 2 clusters (and specifically), in the test class setup method.

The configuration for each cluster is handled by Spring config and the coordination is all handled using GemFire/Geode properties (specifically) combined with some Spring Profiles (for example, then see here) to control which configuration gets applied for each GemFire/Geode JVM process.

Of course, this example and test configuration is quite complex given the fact that the test also employs GemFire/Geode's WAN capabilities, hence the "multi-site" caching reference, but serves to demonstrate that Spring and SBDG/SDG/STDG supports as complex or as simple of a setup as your testing needs require.

You can start any number of GemFire/Geode processes (Locators, CacheServers, etc). And, in nearly all cases, the test class (JVM) itself is the cache client (ClientCache instance).

Here are a couple more examples from the Spring Data for Apache Geode (SDG) codebase and test suite: here and here.

I am certain I have another test class or example (somewhere) that for a single Locator, then joined 2 CacheServer instances, and then the test (JVM process) proceeded as ClientCache instance, but I cannot seem to find it at the moment.

In any case, I hope this gives you some ideas.

John Blum
  • 7,381
  • 1
  • 20
  • 30