Today I wanted to talk about something that's really important in integration testing - stub and mock.
For those who may not be familiar, stub and mock are tools used to test the interactions between different components of a system. In integration testing, this means testing how different parts of a system work together.
Depending on the software that is being tested, there are multiple things that can be mocked:
- Environment and context. To assert a list of user's purchases you can mock the user already being authenticated, instead of going through the authentication in the unrelated test suite.
- API communication. When testing a checkout process you don't want to make an actual purchase and be charged for it.
- External dependencies. When testing how our system reacts to various payloads from an external library or SDK you may emulate what the latter return.
- When we work with Integration testing the technology which helps us to achieve it is MOCKING.
- Wiremock is one of the best to use mocking, stubbing for your API.
- A core feature of WireMock is the ability to return canned HTTP responses for requests matching criteria.
- The following code will configure a response with a status of 200 to be returned when the relative URL exactly matches
/some/thing (Including query parameters). The body of the response will be “Hello world!” and aContent-TypeThe header will be sent with a value totext-plain.
Click link here for the code on Pojo Class creation
@Test
public void exactUrlOnly() {
stubFor(get(urlEqualTo("/some/thing"))
.willReturn(aResponse()
.withHeader("Content-Type", "text/plain")
.withBody("Hello world!")));
assertThat(testClient.get("/some/thing").statusCode(), is(200));
assertThat(testClient.get("/some/thing/else").statusCode(), is(404));
}
In addition to the status code, the status message can optionally also be set.
@Test
public void statusMessage() {
stubFor(get(urlEqualTo("/some/thing"))
.willReturn(aResponse()
.withStatus(200)
.withStatusMessage("Everything was just fine!")
.withHeader("Content-Type", "text/plain")));
assertThat(testClient.get("/some/thing").statusCode(), is(200));
assertThat(testClient.get("/some/thing/else").statusCode(), is(404));
}
Click Here For Test Scenarios On API Testing
In addition to matching on request headers, it’s also possible to send response headers.
stubFor(get(urlEqualTo("/whatever")) .willReturn(aResponse() .withStatus(200) .withHeader("Content-Type", "application/json") .withHeader("Set-Cookie", "session_id=91837492837") .withHeader("Set-Cookie", "split_test_group=B") // You can call withHeader more than once for the same header if multiple values are required .withHeader("Cache-Control", "no-cache")));
- The simplest way to specify a response body is as a string literal:
stubFor(get(urlEqualTo("/body")) .willReturn(aResponse() .withBody("Literal text to put in the body")));To read the body content from a file, place the file under the__filesdirectory. By default this is expected to be undersrc/test/resourceswhen running from the JUnit rule. When running standalone it will be under the current directory in which the server was started. To make your stub use the file, simply callbodyFile()on the response builder with the file’s path relative to__files:stubFor(get(urlEqualTo("/body-file")) .willReturn(aResponse() .withBodyFile("path/to/myfile.xml")));So why are stub and mock so important?
Well, here are a few reasons:
They allow for isolated testing: By using stub and mock, you can isolate the component you're testing from other components. This means you can test the component in question without worrying about the behavior of other components in the system.
They save time: If you had to test every component of a system together, it would take a lot of time. By using stub and mock, you can test individual components faster and more efficiently.
They help with debugging: When something goes wrong in an integration test, it can be hard to figure out where the problem is. By using stub and mock, you can narrow down the possible sources of the problem, making it easier to debug.
So if you're not already using stub and mock in your integration testing, I highly recommend giving it a try. It can save you time and make your testing more efficient and effective.
Happy testing!
No comments:
Post a Comment