Testing verticles that make external call using HTTP client

[Igor Nikolaev]

Hi everyone,

I'm curios how do you test verticles which make calls to external services?

It's doesn't look like there's an easy way to add mock responses globally.

For now I tried two approaches:

1. Start a mock HTTP server which will return mock response

2. Create a separate service class which would receive a configured HTTP client. This service class then can be instantiated or somehow injected into a verticle which creates an instance of HTTP client. That way during test I can mock HTTP client and pass it to the service.

Though I'm not very satisfied with this approaches. Are there any other ideas?

Ideally I think I would to be able to avoid mocking and be able to intercept HTTP calls and return preconfigured response.

Thanks,

Igor

[Julien Viet]

how is that different from mocking functionally speaking ?

Thanks,

Igor

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
Visit this group at https://groups.google.com/group/vertx.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/ea6f0355-ce6f-4f09-b309-171620f9bdb8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Igor Nikolaev]

The difference is that it could be built into the framework itself and easier to use.

Right now I'm kind of lost - if I create a verticle and want to test then I have to create Vertx instance and do a lot of additional work to setup tests.

When using Mockito for mocking in some cases I had troubles to create mocks since it couldn't mock some classes at all due to them being final or something like that (don't have that exception at hand right now). If I remember correctly I tried to mock RoutingContext.

It feels like I would like to have a parallel implementation of Vertx interface which would be easy to configure. 

But maybe it's too much to ask or goes against how you see it should be done.

Not saying that this idea is better, but I would to see how others do tests.

Thanks,

Igor

[Doug Galligan]

We do option 1. above.  We call them "simulators".  They optionally deploy on the configured port for the service, but in the unit tests we set the configuration to a random port.  We use them for more than supporting our vertx unit tests.  They listen on the event bus to be dynamically brought up or down, or to introduce various latencies to responses.  This has allowed us to test recovery modes, and to run load testing at various dynamic latencies for all our external dependencies without impacting other systesm (most are Weblogic SOAP or Spring Boot).  Right now the database is the only one we don't do, and even have a simple tcp simulator for our mail system.

It's proven to be a versatile and valuable exercise, with not much effort.  It has allowed for parallel development with external teams, some of which have manual testing procedures that require way too much hand holding.

Kind regards,

Doug

[Julien Viet]

it’s very nice tool you are describing, perhaps you could open source it ?

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/8e05ae20-5a39-4851-b905-cfd164835dec%40googlegroups.com.

[Doug Galligan]

I can certainly check with my client, or gen something similar on my own.