Implement Record Types

[lordofthejars]

Currently Hoverfly-java only supports to recording modes simulate or capture. The problem is that you use one or other, so for example the first time you run a test to capture the traffic against real service you do HoverflyRule.inCaptureMode. Then when you don't want to touch the real traffic you need to do HoverflyRule.inSimulateMode. So as you can see you need to effectively modify the test to adapt the test lifecycle, first run by instantiating Hoverfly in capture and next times for simulate mode.

To avoid this change an aggregation of both modes so you can do something like:

HoverflyRule.inDualMode(SimulationSource, HoverflyConfig, Type)

where Type can be:

• READ: it always behaves like inSimulate
• WRITE: it always behaves like inCapture
• READ_WRITE: if file exists then behave as READ (simulate), if not as WRITE (capture).

I can provide a PR about this.

[JohnFDavenport]

This seems like a useful feature. Since we want to support polyglot developments we think we should implement some of this in Hoverfly.

[lordofthejars]

ok, but you want I submit a PR or you're going to implement? I mention @mogronalol because I started conversation with him as well. WDYT?

[mogronalol]

@lordofthejars We are talking about this internally and I think it makes sense to be implemented here, not in Hoverfly.

This is because the high level logic is hoverfly.setMode(file.exists ? simulate : capture). Very simple and there wouldn't really be a way of doing this in Hoverfly synonymously.

I think your abstraction makes. I would suggest getting rid of the third parameter, and just have it always READ_WRITE - what was the use case for it?

Also the name dualMode implies to me that Hoverfly has a mode called dual, technically it doesn't, you're just telling it to run in either capture or simulate mode based on the presence of a file. So maybe a different name. What do you think?

Feel free to fork and do a PR. Thanks :)

[lordofthejars]

Ah ok, sorry at the end I was confused between Hoverfly Go and Hoverfly Java since for me Hoverfly is Hoverfly-Java :D

Ok then I am going to provide a PR on this project and let's discuss with code :)

[mogronalol]

@lordofthejars Brilliant, thanks.

Yes, there's always the issue of whether something should be implemented directly in Hoverfly, or in one of the language bindings. Generally anything to do with orchestration would go in this project, anything to do with core functionality in Hoverfly directly.

[lordofthejars]

@mogronalol PR done #55 I have updated README but not docs. Just when we agreed on the names, then I can update the docs in separate commit in same PR.

[tommysitu]

@lordofthejars Thanks for your contribution, will let you know when it is released.