Main Servirtium site: https://servirtium.dev
You're going to need a Recorder (to the markdown format), a replayer (from the markdown format), a server that can listen on a socket and work with the recorder or replayer. In the case of the recorder ("man in the middle"), the incoming requests are sent to the 'real' service too.
In the case of the replayer, the "real service" is not involved.
This is the suggested way of building Servirtium for a new language as it is methodical. That's useful because you may have to pause your development of this and restart later. So we're going to this in many small steps. The first isn't even about Servirtium at all.
Methodical is the idea here. This is all pausable/resumable as an activity. Indeed Fred and Wilma can pair on step 1, get busy on other important things, then Betty and Barney can pick up step 2 (from what was checked in) and continue.
Steps:
- Write a simple API class with tests
- Implement a rudimentary "playback" for the same test cases
- Adding "record" mode to what you have
- Make the recording of a test fail if it is different to what it was previously
- Add second and subsequent interaction handling
- Extract the library from the climate demo, to its own repo
- Other HTTP verbs other than 'GET'
- Mutation operations (Redaction, Mask, Delete)
- Add a capability for a "Note"
- Fail a playback step if the request is not as previously recorded
- Have a raw-serve (GET) capability for static content)
- Optional Markdown Settings
- Publish to package/module-land for your language family
- Proxy Server mode of operation
- Pass the compatibility suite
- Ensure compatibility with other language implentations
If you're making a new impl, you don't actually have to understand the architecture of previous implementations. Indeed, your impl may be better for not being educated on prior implementations.
- Here's the Kotlin API of step 1, and the JUnit5 tests for that.