I made a peek-a-boo reference last week and forgot to make this joke: Wound up in the hospital after a peek-a-boo accident. They put me in the ICU. Ha! (I remind you that this newsletter is free)
So, there is a third way of testing your AstroService which would not require you to mock anything at class level yet make your tests independent of network or availability of the web service your code talks to - mock out the http responses of the web service. There are many libraries that can do it but my favourite one is WireMock. Hopefully it’s cause it’s good and not because I personally know the creator… 🙂
So the idea is to set up a mock server with the JSON response I need, and point the gateway at it, right? I'll give that a try. I've heard really good things about WireMock, and now I have an excuse to use it. Thanks :-)
Yeah, that's exactly the idea. In bigger projects I even tend to build fixtures on top of WireMock where I would have a method like `mockAssignementsResponse(List<Assignment> assignments)` and use that in the test for comprehensibility rather than use the lower level WireMock's APIs which deal with HTTP request and response details.
I added a class called WiremockGatewayTest to the GitHub repo at https://github.com/kousen/mockitobook (under src/test/java in the com.kousenit.astro package). I could probably simplify how to load the JSON data, but I liked the excuse to use a TextBlock. :) I did have to refactor the AstroGateway to take a String url in a constructor, though I left the default as the actual restful service location. I stuck with the low-level WireMock api calls, too. The @WireMockTest annotation, however, simplified things a lot.
I think I'm doing it right, but the examples I found online were surprisingly dated and uninformative. Just as with Mockito, there seems to be a lot unsaid about the setup that is easy to miss. Still, I got it working. Feel free to have a look and let me know if it fits the right idioms.
Yeah, what you have makes perfect sense, although given you have full control of the returned json I would probably make the assertions stronger than assertTrue(data.number() >= 0) and assertEquals(data.people().size(), data.number()).
> Just as with Mockito, there seems to be a lot unsaid about the setup that is easy to miss.
IMHO, a good developer will not be deterred by that. These are all OSS tools in the end so they might even take a look at the sources if they get stuck or they cannot find a copy-pasteable snippet. ¯\_(ツ)_/¯
To be frank, your code looks super modern, JUnit5 with an extension from Wiremock and test parameter injection so that WireMock runs on a random port making your tests parallelizable, switch statement pattern matching and using assertAll(). I've only ever used WireMock with Spock and manual lifecycle management of the mock server...
So, there is a third way of testing your AstroService which would not require you to mock anything at class level yet make your tests independent of network or availability of the web service your code talks to - mock out the http responses of the web service. There are many libraries that can do it but my favourite one is WireMock. Hopefully it’s cause it’s good and not because I personally know the creator… 🙂
So the idea is to set up a mock server with the JSON response I need, and point the gateway at it, right? I'll give that a try. I've heard really good things about WireMock, and now I have an excuse to use it. Thanks :-)
Yeah, that's exactly the idea. In bigger projects I even tend to build fixtures on top of WireMock where I would have a method like `mockAssignementsResponse(List<Assignment> assignments)` and use that in the test for comprehensibility rather than use the lower level WireMock's APIs which deal with HTTP request and response details.
I added a class called WiremockGatewayTest to the GitHub repo at https://github.com/kousen/mockitobook (under src/test/java in the com.kousenit.astro package). I could probably simplify how to load the JSON data, but I liked the excuse to use a TextBlock. :) I did have to refactor the AstroGateway to take a String url in a constructor, though I left the default as the actual restful service location. I stuck with the low-level WireMock api calls, too. The @WireMockTest annotation, however, simplified things a lot.
I think I'm doing it right, but the examples I found online were surprisingly dated and uninformative. Just as with Mockito, there seems to be a lot unsaid about the setup that is easy to miss. Still, I got it working. Feel free to have a look and let me know if it fits the right idioms.
Yeah, what you have makes perfect sense, although given you have full control of the returned json I would probably make the assertions stronger than assertTrue(data.number() >= 0) and assertEquals(data.people().size(), data.number()).
> Just as with Mockito, there seems to be a lot unsaid about the setup that is easy to miss.
IMHO, a good developer will not be deterred by that. These are all OSS tools in the end so they might even take a look at the sources if they get stuck or they cannot find a copy-pasteable snippet. ¯\_(ツ)_/¯
To be frank, your code looks super modern, JUnit5 with an extension from Wiremock and test parameter injection so that WireMock runs on a random port making your tests parallelizable, switch statement pattern matching and using assertAll(). I've only ever used WireMock with Spock and manual lifecycle management of the mock server...