Implementing Karate Generic Mock Server with Callbacks and Predicates. #2655
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
This is an attempt to isolate Karate Mock Rule matching from the protocol implementation itself. Currently the Karate Mock Core handler has tight integration with http protocol. It certainly gives a lot of advantage for Http request mocking. So I didnt wanted to touch that as it works quite well.
But to work with different protocols, or to work with custom protocols, where Karate's powerful rule matching capabilities and Feature+Scenario based mock capabilities can be used with other protocols, we need to isolate the protocol implementation and how the Mock is invoked from the core. This is where I tried to use an interface called KarateMockCallback which will be implemented by the Handler, to receive the request for matching.
Advantage is that the Mock engine is isolated from protocol implementation. Can theoretically work with any protocol. Http/ Async/ MQ/ Fix Server (TCP+Wire). Mock server is invoked externally on the event where the mock should happen. Hence its to the protocol implementers to use this callback to define where the MockEvent should be called.
But to make it generic there should be also capability to test any MockEvent and a generic message passing capability. This needed 2 enhancements. A generic message which should define the most wire events there can be. For that I defined a class "KarateMessage" which has currently a very basic skeleton, Properties, Headers and a Generics Body. This should theoretically handle most of the wire events for Application Protocol implementation needs.
2nd Enhancement: Predicates. Predicate is a generic match function which takes another function as argument and tests whether the KarateMessage matches certain condition to invoke the rule. Because there needed to be a generic way to let the custom MockEvent to be matched.
This is currently just a POC. I have provided a sample test with MQ mock implementation of a TextMessage which gets mocked by the Karate matcher to respond as different text message. But I am open to inputs and enhancement.
Next Steps: Enhance with a Plugin architecture with SPI so that popular protocols like MQ can be defined as a mock plugins that defines the mock events+Predicates needed for the said protocol.