![]() Matching Sub-Sets of JSON Keys and Arrays.Managing Headers, SSL, Timeouts and HTTP Proxy.Keywords that set multiple key-value pairs in one step.The retrieve account test follows a similar format to that described above. For more information take a look at their documentation. JsonPath is like an JSON equivalent to XPath that allows you to query JSON using path expressions. The final 3 lines use jsonPath to check that the JSON response is as expected. We then check for the existence of a HTTP header ‘Location’ that contains the request URL for retrieving the created account. We begin by checking that the response code returned is HTTP 200 ‘Created’ and that the content type is indeed JSON. Lines 10 to 15 use statically imported methods from MockMvcResultMatchers to perform assertions on the response. Finally an accept header is set to tell the server that the client expects a JSON response. The request content type is JSON and the request body contains a JSON definition of the Account to be created. Lines 6 to 9 uses mockMvc to define a HTTP POST request to the URI /api/account. We tell the mock that upon receiving any Account instance it should return a 12345. On line 4 we use mockito to define the expected behaviour of the mock AccountService which was injected into the AccountController. ![]() andExpect(jsonPath("$.accountType").value("SAVINGS")) andExpect(content().contentType(MediaType.APPLICATION_JSON_UTF8)) ![]() The AccountController defined below exposes 2 endpoints, one to create an Account and one to retrieve an Account. Defining a Controllerīefore we can put MockMvc through its paces we need a REST endpoint to test. This is a great feature as your tests will pretty much read like English, making life easier for developers coming behind you. MockMvc provides a fluent API, allowing you to write tests that are self descriptive. It stands up the Dispatcher Servlet and all required MVC components, allowing us to test an endpoint in a proper web environment, but without the overhead of running a server. Thankfully that’s exactly what MockMvc allows us to do. The ability to test a fully functional REST controller but without the overhead of deploying the entire application to a server. What we’d really like is the best of both worlds. The problem is that by manually instantiating the Controller we’re bypassing Springs Dispatcher Servlet, and as a result missing out on core features like While such a test will run much faster than a full integration test, its of limited value. We’re forced to wait while the entire application is stood up, just to test a single endpoint.Īn alternative approach is to unit test by manually instantiating the Controller and mocking out any required dependencies. While this is an effective way to test an endpoint, it isn’t particularly fast. This involved spinning up a test server like Tomcat or Jetty, deploying the application, calling the test endpoint, running some assertions and then terminating the server. In the past, full integration tests were the only meaningful way to test a Spring REST endpoint. In this post I’m going to show you how to test a Spring MVC Rest endpoint without deploying your application to a server.
0 Comments
Leave a Reply. |