Support given state for service testing

[erip]

When testing services (as opposed to persistent entities), it's currently necessary to do a lot of expensive setup to set up state against which to make assertions.

Consider the case where you want to test GET /api/foos/:id. In order to test this, you must first necessarily add a foo, then use the returned ID to test this endpoint. This has a few problems:

1. The test is doing too much
2. The test implicitly relies on an ID generated within the test
3. The setup could fail
4. The test becomes unscalable as the complexity of the state grows

Lagom should support some way to provide a golden state in TestServer. One approach might to be to play a series of events against a clean DB (similar to PE tests).

---

One workaround would be to support a callback which supports issuing a series of "setup" invocations againt a FooClient and maintains a map between a "gold state" artifacts (e.g., some given foo ID) and the test-generated artifacts (e.g., returned foo ID from a create call). This is quite cumbersome and slow, but doesn't require a huge amount of work, I think.

[ignasi35]

I'm 100% onboard when discussing improvements on testkit.

---

For the particular case you described would a small refactor suffice?

• make your service depend on an interface (instead of the PersistentEntityRegistry)
• inject an in-mem implementation of the interface so tests can be run without a DB or even have some hardcoded responses to ID's, etc...

[erip]

@ignasi35 I think it would be nice if that interface were provided by Lagom. PersistentEntityRegistry could implement it, and the testkit might include an in-mem impl. It seems weird to change an arbitrary lagom service to work with the testkit instead of the other way around.

What do you think?

[ignasi35]

Are you thinking about a InMemPersistenceComponents which provides an InMemPersistentRegistry?

(I was thinking about business-aware interfaces that completely abstract the ServiceImpl from the PersistentEntityRegistry).

[erip]

I think my idea was a combination of the two. 😄The in-memoryness would allow for more control over the API (and less dependence on what the backing store is), but it would still be business-aware since the service would interact with it the same way. Maybe there's a better way to do this, though.