Mocks usage

[mamdouni]

Hello,

I would like to know more about how to mock an api call.
In my case i have to test a service (called A for example). The service A makes a call to an external api service (called B). In my tests, i would like to mock all the calls to the service B as it will not be availabed when i build my app on jenkins for example.
I tried examples from the doc by it doesn't work :
Given that calling "https://service-B" will return a status OK_200 and:
"""
some data here
"""
When a user send on "/service-A":
"""
method: POST
body:
payload:
some data here
"""
Then it receives a status CREATED_201

This doesn't work me at first because the service B is called by my service A and not directly in the tests as this example :

tzatziki/tzatziki-http/src/test/resources/com/decathlon/tzatziki/steps/http.feature

Line 3 in 6e0b97d

Scenario: we can setup a mock and call it

To resolve the issue, in my steps initializer class , i added this system env :
System.setProperty("ENDPOINT", MockFaster.url());
this variable is used by my code to make the call to B (in application-test.yaml as i'm using spring boot) :
host-service-B: ${ENDPOINT}/service-B-resource
and in the gherkin, i'm not using urls prefixed with http and https. So in the last test we have to change just the first line :
Given that calling "/service-B" will return a status OK_200 and:
Using this, all the api calls will be intercepted by the MockFaster.url() and mocked.

I don't know if this is the good way to use the library ?
If so, i think that this part have to be added to the documentation ?

[brian-mulier]

Hello !

What you said is correct. In fact most of the times you will want to have an environment-dependant endpoint which is why this is not that much of an issue. What you can do is consider MockFaster.url() as an API Portal. If you are not using such portal, you can simply specify the whole endpoint as an environment variable which will allow you to :

• on production side, always specify the whole endpoint (including http(s)) into the environment variable
• on test side, specify MockFaster.url() + a relative endpoint into the environment variable

When it comes to understanding why it is working like that, MockFaster is keeping a memory of host-based relative paths. To match against those path, the only way is to make an HTTP call against MockFaster, else you will end up calling the real internet :)

The steps to call an endpoint are mapping an host-based path to a MockFaster URL if it is matching a mocked path, else it is reaching out Internet as shown below :

It is effectively unclear in the documentation and should be added, although technically an understandable mechanism.
Feel free to add the documentation through a PR if you want. Else I'll do it later.

[mamdouni]

thanks for the explanation @brian-mulier 🥇 it helps me to understand how the library works internally
i'll take in charge the PR

[mimfgg]

super explanation :)

But yes, it is true that the urls starting with http:// will be automatically remapped to their local mocks starting with MockFaster.url() so it could be a bit ambiguous as a feature ... maybe we could remove this to make it more intuitive ...

It is currently not really possible to mock a random url since we don't control the http client used by your application. This would be possible though ... we could encapsulate the RestTemplate or WebFlux builders in the spring module ... maybe a nice feature to implement!

[mamdouni]

yes, i agree with you. but it will be difficult as there is a lot of http clients. In my case, we are using the third part library that uses apache http client ❗

[mimfgg]

I have a PR for the RestTemplate and WebClient #19 but it should be easy to apply the same logic on your custom client.

[mamdouni]

Thank you for the response, i have another question in the same context and i don't know if it needs a new discussion ?
Actually, when calling internet (without using mocks) i get a timeout exception. Here is my test case :

Doing the same test on a new project without the spring module works perfectly :

The first test fails (timeout) after calling the RestAssured.request method :

This method calls the host using the RestAssured.port which is -1 by default -> reach out the internet
This configuration will be overriden after lauching the test by Before method in SpringSteps :

So when calling google.com, the request will be redirected to google.com:{Spring_Random_Port} and not to google.com:80.
Is this a bug in the library ? or a manner to say, during unit tests we cannot do external calls ?

[brian-mulier]

I may be wrong since I can't check the code until Monday but I think the RestAssured port is used only in case of specifying a relative path in order to be able to reach out your app's controllers. This way you can call and test your own API. I can't get why the test is wrong there. Is there any dependency difference around Tzatziki between your fresh project and the old one ?

I will try to reproduce it on Monday if you aren't able to figure out what's wrong. @mimfgg may have an idea about what's going on ?

[brian-mulier]

And just to make it clear : you can reach out internet through Tzatziki. I'm actually doing it for my integration tests on a pre-production environment.

[mimfgg]

that might be a bug ... because reaching out to the internet should work, like @brian-mulier said, we do it. I will find why it doesn't behave like it should and add that to the other PR :)

[mimfgg]

you were right, the RestAssured port was interferring with the network call. I have fixed it in the PR!
Thanks for debugging and reporting it!

[mimfgg]

I have released the version 1.0.5 fixing all the problems raised in this thread!

[mamdouni]

good news,
Thank you guys for your reactivity and for fixing the bug. I'll test the new version.

[mimfgg]

try the version 1.0.8 then :)

[mamdouni]

yep, i tested it with 1.0.8 and it works like a charm 👌