Every console block quoted in the article came out of docs/output/. These are real mvn test and curl transcripts, not retyped output — including four real, captured failures (two different ways to get TestRestTemplate wrong, one way to get RestTestClient wrong, and a javap dump proving a real API gap) that are as much the point of the post as the passing tests are.

There is deliberately no docs/NN-topic.md chapter folder: the deeper material lives in collapsible "going deeper" sections inside the article itself, next to the paragraph each one extends. docs/output/ (captured transcripts) is the one thing that still lives under docs/.

Versions


Spring Boot	4.1.1
Spring Framework	7.0.9 (GA 2025-11-13)
JDK	25 (GraalVM CE 25.4.4.1.1)
Maven	3.9

Quickstart

export JAVA_HOME=/path/to/jdk-25
mvn test    # runs everything below; no Docker, no running server required to start it

What's demonstrated

Area	Where
`bindToController`: the fastest binding mode, no Spring context at all	`PersonControllerUnitTest.java`
`bindTo(mockMvc)` inside `@WebMvcTest`: real MVC dispatch, mocked collaborator	`PersonMockMvcSliceTest.java`
`bindToApplicationContext`: the full context, no server, plus the AssertJ-style `RestTestClientResponse`	`PersonApplicationContextTest.java`
`bindToServer` with `@AutoConfigureRestTestClient`: a real embedded Tomcat on a real port	`PersonEndToEndTest.java`
`RestTestClient`, `TestRestTemplate`, and `@WebMvcTest` all moved into new Spring Boot 4 modules — confirmed by unzipping the real jars	`pom.xml`, `docs/output/02`, `docs/output/03`, `docs/output/04`
`TestRestTemplate` is not deprecated, just relocated and no longer free: `@AutoConfigureTestRestTemplate` migrates existing tests unchanged	`TestRestTemplateMigrationTest.java`
The default HTTP client Boot detects for `bindToServer` (`java.net.http.HttpClient`) transparently decodes gzip and hides `Content-Encoding` from you — a real surprise, verified against `curl` and against the older `SimpleClientHttpRequestFactory`	`PersonEndToEndTest.java`, `HttpClientChoiceComparisonTest.java`
`RestTestClient` genuinely has no multipart support yet — confirmed with `javap` against the real class files, not a blog post's claim	`docs/output/08-no-multipart-method-javap.txt`

Captured output

File	What it shows
`01-full-test-run-passing.txt`	the real, full `mvn clean test` run: all 11 tests passing across 6 classes
`02-testresttemplate-missing-restclient-dependency.txt`	`@AutoConfigureTestRestTemplate` present, but `spring-boot-starter-restclient` missing: a `NoClassDefFoundError` on `RestTemplateBuilder`, not a clean "bean not found"
`03-resttestclient-not-autoconfigured.txt`	`@AutoConfigureRestTestClient` removed: a clean `NoSuchBeanDefinitionException` for `RestTestClient`
`04-testresttemplate-not-autoconfigured.txt`	`@AutoConfigureTestRestTemplate` removed (with the restclient starter present this time): the same clean failure shape, for `TestRestTemplate`
`05-curl-sees-real-gzip.txt`	direct `curl` against the running app: Tomcat really does send `Content-Encoding: gzip`
`06-resttestclient-hides-the-gzip.txt`	the same request through `RestTestClient.bindToServer()`: no `Content-Encoding` header at all
`07-simplefactory-shows-the-real-header.txt`	the same request again, through the older `SimpleClientHttpRequestFactory`: `Content-Encoding: gzip` is visible
`08-no-multipart-method-javap.txt`	`javap` against the real `RestTestClient` class files: no `multipart()` method anywhere in the chain

Nothing here needs Docker or a pre-running server — mvn test starts and stops everything it needs, including the one test class that opens a real socket.