Mocking external APIs in service ITs strategy

Hello.

Since one of the goals of this sprint is to drop the links from individual services to other services and only have OpenLMIS-blue tie them together, I wanted to bring up the topic of testing the APIs that depend on other services and to have a final decision on the strategy that we want to follow while refactoring the current tests. I know that we have discussed the possibility of using WireMock for the purpose of mocking the external APIs for a longer time and which seems like the easiest/simplest solution. However, from our recent calls and meetings I understand, that we would rather want to mock the HttpClient / RestTemplate or whatever else is used in the service to communicate with the other service.

My question is, do we have any specific reason to avoid WireMock or other similar library for mocking external APIs and doing it kind of manually, by mocking the http client? I also want to make sure that we agree on one strategy, so we don't end up having some tests mocking APIs one way and other mocking them another way.

Thanks!
Sebastian Brudzinski.

Hey Sebastian,

Shalom,

Chongsun

– ​

There are 10 kinds of people in this world; those who understand binary, and those who don’t.

Chongsun Ahn | chongsun.ahn@villagereach.org

Software Development Engineer

Village****Reach* ** Starting at the Last Mile*

2900 Eastlake Ave. E, Suite 230, Seattle, WA 98102, USA

DIRECT: 1.206.512.1536 **CELL: **1.206.910.0973 FAX: 1.206.860.6972

SKYPE: chongsun.ahn.vr

www.villagereach.org

Connect on Facebook****, Twitter** ** and our Blog

···

From my understanding, after talking with Josh and Darius, is that we could do it either way, but have chosen to mock the HttpClient/RestTemplate instead of using something like WireMock to create a mock web server. The WireMock strategy is a bit more complete, since that testing would include the “wire,” but it would also make the integration/component tests slower, since we would have to bring up another web server to run the tests. I don’t think we have a need to test the wire at this point, so it seems like mocking the HttpClient is preferable.

On Sep 21, 2016, at 4:28 AM, Sebastian Brudziński sbrudzinski@soldevelo.com wrote:

Hello.

Since one of the goals of this sprint is to drop the links from individual services to other services and only have OpenLMIS-blue tie them together, I wanted to bring up the topic of testing the APIs that depend on other services and to have a final decision on the strategy that we want to follow while refactoring the current tests. I know that we have discussed the possibility of using WireMock for the purpose of mocking the external APIs for a longer time and which seems like the easiest/simplest solution. However, from our recent calls and meetings I understand, that we would rather want to mock the HttpClient / RestTemplate or whatever else is used in the service to communicate with the other service.

My question is, do we have any specific reason to avoid WireMock or other similar library for mocking external APIs and doing it kind of manually, by mocking the http client? I also want to make sure that we agree on one strategy, so we don’t end up having some tests mocking APIs one way and other mocking them another way.

Thanks!

Sebastian Brudzinski.

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis-dev@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/57E26EEE.1040902%40soldevelo.com
.

For more options, visit https://groups.google.com/d/optout.

Hey Sebastian,

Shalom,

Chongsun

– ​

There are 10 kinds of people in this world; those who understand binary, and those who don’t.

Chongsun Ahn | chongsun.ahn@villagereach.org

Software Development Engineer

Village****Reach* ** Starting at the Last Mile*

2900 Eastlake Ave. E, Suite 230, Seattle, WA 98102, USA

DIRECT: 1.206.512.1536 **CELL: **1.206.910.0973 FAX: 1.206.860.6972

SKYPE: chongsun.ahn.vr

www.villagereach.org

Connect on Facebook****, Twitter** ** and our Blog

···

From my understanding, after talking with Josh and Darius, is that we could do it either way, but have chosen to mock the HttpClient/RestTemplate instead of using something like WireMock to create a mock web server. The WireMock strategy is a bit more complete, since that testing would include the “wire,” but it would also make the integration/component tests slower, since we would have to bring up another web server to run the tests. I don’t think we have a need to test the wire at this point, so it seems like mocking the HttpClient is preferable.

On Sep 21, 2016, at 4:28 AM, Sebastian Brudziński sbrudzinski@soldevelo.com wrote:

Hello.

Since one of the goals of this sprint is to drop the links from individual services to other services and only have OpenLMIS-blue tie them together, I wanted to bring up the topic of testing the APIs that depend on other services and to have a final decision on the strategy that we want to follow while refactoring the current tests. I know that we have discussed the possibility of using WireMock for the purpose of mocking the external APIs for a longer time and which seems like the easiest/simplest solution. However, from our recent calls and meetings I understand, that we would rather want to mock the HttpClient / RestTemplate or whatever else is used in the service to communicate with the other service.

My question is, do we have any specific reason to avoid WireMock or other similar library for mocking external APIs and doing it kind of manually, by mocking the http client? I also want to make sure that we agree on one strategy, so we don’t end up having some tests mocking APIs one way and other mocking them another way.

Thanks!

Sebastian Brudzinski.

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis-dev@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/57E26EEE.1040902%40soldevelo.com
.

For more options, visit https://groups.google.com/d/optout.

Hey all,

I have an update to this thread about choosing an approach. So I started working on this mocking strategy by mocking the http client and have run into roadblocks getting a good test application context to come up with a mocked http client, for our integration/component tests. Because of that, I tried using the other approach in using WireMock to mock out the wire with an auth test double, and it was much easier to implement. I suggest we change our decision to use WireMock. I will add some code and refactor some test cases in the reference data and requisition services to show the pattern. This work is being done in OLMIS-1017, if you want to follow the progress.

Shalom,

Chongsun

– ​

There are 10 kinds of people in this world; those who understand binary, and those who don’t.

Chongsun Ahn | chongsun.ahn@villagereach.org

Software Development Engineer

Village****Reach* ** Starting at the Last Mile*

2900 Eastlake Ave. E, Suite 230, Seattle, WA 98102, USA

DIRECT: 1.206.512.1536 **CELL: **1.206.910.0973 FAX: 1.206.860.6972

SKYPE: chongsun.ahn.vr

www.villagereach.org

Connect on Facebook****, Twitter** ** and our Blog

···

On Sep 21, 2016, at 10:56 AM, Chongsun Ahn chongsun.ahn@villagereach.org wrote:

Hey Sebastian,

From my understanding, after talking with Josh and Darius, is that we could do it either way, but have chosen to mock the HttpClient/RestTemplate instead of using something like WireMock to create a mock web server. The WireMock strategy is a bit more complete, since that testing would include the “wire,” but it would also make the integration/component tests slower, since we would have to bring up another web server to run the tests. I don’t think we have a need to test the wire at this point, so it seems like mocking the HttpClient is preferable.

Shalom,

Chongsun

– ​

There are 10 kinds of people in this world; those who understand binary, and those who don’t.

Chongsun Ahn | chongsun.ahn@villagereach.org

Software Development Engineer

Village****Reach* ** Starting at the Last Mile*

2900 Eastlake Ave. E, Suite 230, Seattle, WA 98102, USA

DIRECT: 1.206.512.1536 **CELL: **1.206.910.0973 FAX: 1.206.860.6972

SKYPE: chongsun.ahn.vr

www.villagereach.org

Connect on Facebook****, Twitter** ** and our Blog

On Sep 21, 2016, at 4:28 AM, Sebastian Brudziński sbrudzinski@soldevelo.com wrote:

Hello.

Since one of the goals of this sprint is to drop the links from individual services to other services and only have OpenLMIS-blue tie them together, I wanted to bring up the topic of testing the APIs that depend on other services and to have a final decision on the strategy that we want to follow while refactoring the current tests. I know that we have discussed the possibility of using WireMock for the purpose of mocking the external APIs for a longer time and which seems like the easiest/simplest solution. However, from our recent calls and meetings I understand, that we would rather want to mock the HttpClient / RestTemplate or whatever else is used in the service to communicate with the other service.

My question is, do we have any specific reason to avoid WireMock or other similar library for mocking external APIs and doing it kind of manually, by mocking the http client? I also want to make sure that we agree on one strategy, so we don’t end up having some tests mocking APIs one way and other mocking them another way.

Thanks!

Sebastian Brudzinski.

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis-dev@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/57E26EEE.1040902%40soldevelo.com
.

For more options, visit https://groups.google.com/d/optout.

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis-dev@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/430FC102-7031-4A9C-9DA1-EF95EF75967E%40villagereach.org
.

For more options, visit https://groups.google.com/d/optout.