1

I have a service that receives a request, generates an email, saves the email to message queue (to be sent by other microservice) and returns httpStatus.Ok. I want to test that for different requests a relevant email will be generated.

According to Contract Tests vs Functional Tests my tests are functional, not contract tests. (If my service would return email content as an api response, using Pact for contract tests will certainly be appropriate).

I have an idea to use Pact infrastructure for such functional tests, in particular
1.Save request and expected generated email into Pact Broker
2. In provider Verify tests submit the request and verify generated email with expected email.

Does it make sense to use Pact in such functional tests?
Does anyone know examples of similar usage?
Any alternative technologies ( preferably in .Net Core) to have similar testing?

I am also considering https://github.com/approvals/ApprovalTests.Net, but Pact infrastructure attracts me more.

Related note: The Pact normally works with http requests/responses, but Pact V3 (not implemented by PackNet yet) Introduces messages for services that communicate via event streams and message queues. An example describes messages pact contract tests is https://dius.com.au/2017/09/22/contract-testing-serverless-and-asynchronous-applications/ referenced by Pact for MessageQueue's : Sample Provider test in case of MessageQueues

Michael Freidgeim
  • 26,542
  • 16
  • 152
  • 170

1 Answers1

1

I have a service that receives a request, generates an email, saves the email to message queue (to be sent by other microservice) and returns httpStatus.Ok.

So as you say, with Pact whilst the intent is not to be a functional testing tool in the traditional sense, it is almost unavoidable to not test functionality. The objective is really about testing the contract between the systems (this creates a small grey area in which you'll need to decide what is most appropriate for your test strategy).

What you don't want to do with Pact, is run the verification tests and then check that the email was actually sent, it was written to the queue, and that the downstream microservice could process it - that would be going beyond the bounds of a "contract test".

As an aside: what you can definitely do, is create a separate contract test between this component that publishes to the queue and the downstream component that receives from it (see this WIP branch for .NET library: https://github.com/pact-foundation/pact-net/pull/175)

I want to test that for different requests a relevant email will be generated.

If for those "different tests", the responses from the API are predictably shaped - then yes, you could definitely do that with Pact.

So rewording the above to "I have a service that receives a request, returns httpStatus.Ok and the email body sent" is an acceptable contract-testing IMO.

You could then expand upon this with various scenarios:

  1. When the user was created successfully ...
  2. When the user already exists...
  3. etc.

Hope that helps!

P.S. Might be worth jumping in to https://slack.pact.io and chatting with the community further there.

Matthew Fellows
  • 3,669
  • 1
  • 15
  • 18