Test Spring RestClient on a socket without claiming a remote service

Last updated: 30 Sept 20264 min read

tutorial

A loopback HTTP server checks the configured client transport more directly than a stubbed response but still leaves deployment behavior open.

Download Spring source kit

What four tests establish

RestClientBoundaryTest uses a random 127.0.0.1 port and an explicit SimpleClientHttpRequestFactory. It checks one 200 body, a single request for 503, a read timeout after the server accepts the request, and a write committed by the local handler before the caller times out. The last test replays the same key and checks two requests against one modeled mutation.

These checks run through a real socket. They can catch a missing URI, wrong HTTP method, unexpected status mapping or missing read deadline in this factory. MockMvc instead targets a server-side MVC handler without making this outbound network exchange.

What the fixture cannot establish

The handler and client live in one JVM. There is no TLS handshake, DNS, proxy, connection pool, remote provider, packet loss, process crash or database-backed replay table. The 80ms deadline is chosen for a short test and should not be used as a performance benchmark.

Before release, run the packaged artifact with the chosen transport against a dedicated test service that can delay headers, stream partial bodies, close sockets and return status sequences. Test key retention and concurrent first use against the real upstream contract. The release test plan separates these layers.

Checked source

mvn -q -Dtest=RestClientBoundaryTest test

Verification boundary

RestClientBoundaryTest has four passing loopback tests.

Costs and limits

No remote infrastructure, alternate request factory or process restart is covered.

Common Mistakes

Do not call a mock response a transport test.
Do not call a loopback socket a distributed-system test.
Do not infer concurrency safety from sequential key replay.