Added more docs for messaging
This commit is contained in:
@@ -578,6 +578,8 @@ Accurest will also generate tests with guaranteed order of execution.
|
||||
|
||||
include::stubrunner.adoc[]
|
||||
|
||||
include::stubrunner_msg.adoc[]
|
||||
|
||||
== Migration Guide
|
||||
|
||||
=== Migration to 0.4.7
|
||||
|
||||
@@ -43,4 +43,10 @@ You have to provide as a dependency the `accurest-messaging-core` module. Exampl
|
||||
[source,groovy,indent=0]
|
||||
----
|
||||
testCompile "io.codearte.accurest:accurest-messaging-core:${accurestVersion}"
|
||||
----
|
||||
----
|
||||
|
||||
=== Publisher side test generation
|
||||
|
||||
Having the `input` or `outputMessage` sections in your DSL will result in creation of tests on the publisher's side.
|
||||
|
||||
//TODO: add examples from MessaginMethodBodyBuilderSpec
|
||||
@@ -1,4 +1,4 @@
|
||||
== Accurest REST
|
||||
== Accurest HTTP
|
||||
|
||||
=== Gradle Project
|
||||
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
== Stub Runner
|
||||
== Stub Runner for HTTP
|
||||
|
||||
One of the issues that you could have encountered while using Accurest was to pass the generated WireMock JSON stubs from the server side to the client side (or various clients).
|
||||
The same takes place in terms of client side generation for messaging.
|
||||
|
||||
53
docs/src/docs/asciidoc/stubrunner_msg.adoc
Normal file
53
docs/src/docs/asciidoc/stubrunner_msg.adoc
Normal file
@@ -0,0 +1,53 @@
|
||||
== Stub Runner for Messaging
|
||||
|
||||
WARNING: Feature available since 1.0.7
|
||||
|
||||
Stub Runner has the functionality to run the published stubs in memory. It can integrate with the following frameworks out of the box
|
||||
|
||||
- Spring Integration
|
||||
- Spring Cloud Stream
|
||||
- Apache Camel
|
||||
|
||||
It also provides points of entry to integrate with any other solution on the market.
|
||||
|
||||
=== DSL
|
||||
|
||||
The DSL for messaging looks a little bit different than the one that focuses on HTTP.
|
||||
|
||||
==== Output triggered by a method
|
||||
|
||||
The output message can be triggered by calling a method (e.g. a Scheduler was started and a message was sent)
|
||||
|
||||
[source,groovy]
|
||||
----
|
||||
include::../../../../samples/messaging-integration/src/test/groovy/io/codearte/accurest/samples/messaging/IntegrationMessagingApplicationSpec.groovy[tags=method_trigger,indent=0]
|
||||
----
|
||||
|
||||
In this case the output message will be sent to `output` if a method called `bookReturnedTriggered` will be executed. In the message *publisher's* side
|
||||
we will generate a test that will call that method to trigger the message. On the *consumer* side you can use the `some_label` to trigger the message.
|
||||
|
||||
==== Output triggered by a message
|
||||
|
||||
The output message can be triggered by receiving a message.
|
||||
|
||||
[source,groovy]
|
||||
----
|
||||
include::../../../../samples/messaging-integration/src/test/groovy/io/codearte/accurest/samples/messaging/IntegrationMessagingApplicationSpec.groovy[tags=message_trigger,indent=0]
|
||||
----
|
||||
|
||||
In this case the output message will be sent to `output` if a proper message will be received on the `input` destination. In the message *publisher's* side
|
||||
we will generate a test that will send the input message to the defined destination. On the *consumer* side you can either send a message to the input
|
||||
destination or use the `some_label` to trigger the message.
|
||||
|
||||
=== Stub triggering
|
||||
|
||||
To trigger a message it's enough to use the `StubTiggerer` interface:
|
||||
|
||||
[source,groovy]
|
||||
----
|
||||
include::../../stub-runner/src/main/groovy/io/codearte/accurest/stubrunner/StubTriggerer.groovy[]
|
||||
----
|
||||
|
||||
For convenience the `StubFinder` interface extends `StubTrigger` so it's enough to use only one in your tests.
|
||||
|
||||
include::../../../../stub-runner/stub-runner-messaging/stub-runner-messaging-camel/README.adoc[]
|
||||
Reference in New Issue
Block a user