Messaging pacts - guidelines to provide real message to verifier #538
Comments
|
Would you be able to expand on your concern that the test messages may differ from the "real" ones? I'd expect that they were exactly the same, as in if the real message creates an i.e. I'd expect the real message and the test message to both be instances of exactly the same class/record, so there's no way they can diverge. If you're concerned about some fields not being set or something then you could always use an auto generation framework like AutoFixture, although I prefer not to do that otherwise the pact changes every run and needs to be verified again. If it stays the same (with fixed values) then verification can be implicit instead of needing to run again. |
|
The thing is "you expect that they were exactly the same.". PactNet is all about not expecting but asserting. In the sample, the message is published for real in And then, manually craft, pact-net/samples/OrdersApi/Provider.Tests/ProviderTests.cs Lines 69 to 77 in b3c2fe1 How do you ensure that the message created in OrderRepository within this scenario is exactly the same as the one used in the test? I have a dozen scenarios where the content varies because each input scenario is different. For example, in the sample, an order might be created in a "Pending" state due to a payment failure, and this specific scenario would be relevant to the payment domain. Maintaining both integration tests and canned message tests would be burdensome. What I would like to do is running the application like its done with http interaction. Have in some way a listener to the message that will be published and populate scenarios to be verified. Then, for each scenario, I would trigger what will produce the message. |
|
Ah, I see the issue now. Pact is not an end-to-end testing framework like Cypress or Playwright, and as such it's not supposed to be used for testing behaviour. You're only supposed to test the "shape" of the data, not that the contents make semantic sense. In your scenario above, you would have a matcher which ensures that the order status can be one of a number of defined strings, perhaps something like You can find more info in the docs at https://docs.pact.io and particularly this section: https://docs.pact.io/consumer/contract_tests_not_functional_tests |
I'm working on implementing the messaging verifier.
In my case, the provider sends messages to an Azure Service Bus in response to certain interactions. I want to verify that these messages conform to the consumer pact.
Looking at the examples, it seems that messages are manually constructed in the tests. #459 call them canned message. IMHO, this introduces a risk of divergence between the actual messages sent by the application and the ones defined in the test.
What I’ve done instead is configure the provider to send messages to a Service Bus Testcontainer during integration tests. A MessageProcessor dequeues the messages and transforms them into Pact scenarios. Once all integration tests have passed, I use the collected scenarios with the message pact verifier.
What do you think of this approach?
The text was updated successfully, but these errors were encountered: