1

Generally speaking, the basic flow is:

  1. http triggered service method puts request on service bus
  2. service bus triggered method executes request

and in this specific scenario:

  1. method from 2) sends request to external service with callback url
  2. external service sends confirmation to callback url

Full disclosure: another layer I didn't include above, because it's redundant for the sake of this post, is that the above service also receives a callback url to which it forwards the confirmation it receives.

Currently, we have integration tests using Playwright that send requests to the service in 1) and verify that the response is as expected. However, this only really verifies that the request was received for processing.

My question is, how do I create integration tests for subsequent steps to verify the request was actually processed? Playwright obviously is not a server that can receive a callback request. I feel like there is a simple answer here where I'm going to say "oh, duh" when I hear it, but I have already searched the web without success, and I have asked this question to a couple of people whose job titles might suggest they should be more qualified than me to answer this question. So here I am.

2 Answers 2

2

Here is a "slow" integration test:

(1.) Http [playwright] triggered service method puts request on service bus; [stuff happens] ...

(4.) External service sends confirmation to callback url [which writes to a file]

(5.) Playwright detects the callback side effect by reading the file.

Substitute logging, redis, or your favorite form of IPC instead of communicating via a file, as desired.

Playwright should wait for only a limited timeout, and declare Failure if the side effect doesn't happen within the expected interval.

The key change here to the target code is that the final link in the chain, the callback endpoint, must be observable by test code.


Suppose you have several slow integration tests in your automated test suite.

Choose either empty-set or a single random (or round-robin) test. If we chose a test, then run it to completion, in isolation. Now we know it ran without interference from other tests.

Now choose all pending tests that remain, and either run them in an unchanging fixed order, or in a randomly shuffled order. Run them in parallel with one another. They should have been designed to be non-interfering, but hey, we test because nothing is certain, right?

Running in parallel is a small compromise, with the goal of obtaining helpful test results quickly. The faster developers see Green or Red bar results, the faster they can move the PR merge process along.

2
  • I had a thought to do something like this, where I setup a service to listen for the response which is exposed to playwright. But the overhead of it really made me question whether I wasn't overlooking a much simpler solution though... or whether it meant my approach is somehow flawed. Glad to hear this seems reasonable to someone else.
    – BVernon
    Feb 20 at 22:24
  • 1
    "4. external service sends confirmation to callback url" If you want to do E2E integration testing (a worthy goal!), then you fundamentally have to have something listening for the external service's response. I assumed you'd just run another instance of whatever code is listening in production, and that likely it would be running "all the time". As far as being "simple" -- well, I figured that snooping on "logging" would probably be the least invasive test code to write. If there's no logging in production ATM, there should be, so it's a good feature request to implement.
    – J_H
    Feb 20 at 22:30
2

You're going to have to think about how to replicate the action of the third party - either stub it, or come up with a simple API that effectively mocks the response.

If I was doing this, I'd look at using Docker (or the container software of your choice) - you can spin up your services, an instance of say RabbitMQ and your 'external' service quickly and easily, then run your integration tests against that. It disappears again as soon as you're done with it, so you don't have to pay/maintain the environment beyond those tests.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.