Should you write unit tests for templates and frameworks?

No, do not unit test the code a project template generates or the features a framework provides. Delete the sample code, and test your own endpoints through the real framework.

Should I test functionality provided by the framework?

No, the framework's maintainers test its features in their own CI. Test how your application uses those features: send requests to your endpoints and assert the responses your clients need.

Do I need to retest the framework after an upgrade?

No, run your own suite against the new version in a pull request that contains only the upgrade. Add a test for a changed default only when your code or your clients rely on it, such as trailing slash matching in Spring Framework 6.0.

Should I test my custom middleware?

Yes, custom middleware is your own code, even though the framework runs it. Unit test its logic, and send one request through the pipeline to check that it runs before or after authentication as intended.

Should I test framework code?

Verdict

No, do not write tests of a web framework's own features, such as routing, model binding or the code a project template generates; test your own endpoints through the real framework, with requests that give each outcome a different response.

Why

No, do not test what a web framework does on its own; test your code through it. The typical case is a test that ASP.NET Core, Spring Boot or Django routing finds a controller. Blast radius is users, because a broken framework feature breaks pages, and Change frequency is rarely, because framework code changes only when you raise its version. Detectability is immediately and Reversibility is trivial: your endpoint tests send requests through the real framework, with a different expected response for each outcome, so a breaking upgrade fails them in its pull request and stays unmerged. Test cost is moderate, because a framework test needs the framework's host. Rule R8 gives Do not test.

When the decision changes
When	Decision	Why
Your tests call controller methods directly, so routing, model binding and validation run in no test	Test minimally: one request per endpoint through the real request pipeline	Detectability moves to eventually and Reversibility to with-effort: an upgrade that changes a binding default saves plausible wrong values
Installed app versions or partner systems that you cannot update call your URLs	Test minimally: one endpoint test with the exact URL and body each client sends	Detectability moves to same-day and Reversibility to with-effort: an upgrade that changes a routing default fails requests from those installed apps or partner systems until they report errors
Your team writes code that plugs into the framework, such as a middleware, a model binder or a validation attribute	Test: unit tests for its logic and one request through the real pipeline	Change frequency rises to regularly, Detectability moves to eventually and Reversibility to with-effort: no framework suite runs your code
Your configuration of the framework decides who may open a page, such as `[Authorize]` policies or a Spring Security filter chain	Test mandatory: one allowed and one denied request for each rule you configure	Blast radius rises to safety-or-legal and Detectability to never: a wrong rule lets users in without an error
ASP.NET Core model binding reads the amount a customer pays from a posted form	Test mandatory: post the amount in each format your forms send and assert the stored value	Blast radius rises to money and Reversibility to costly: form values bind with the current culture, and a wrong charge needs refunds
Your endpoint tests send one request with a required field and one without, and a separate test of `[Required]` would take two minutes	Do not write the separate framework test	Test cost falls to trivial, but Detectability stays immediately and Reversibility trivial: the endpoint tests fail on an upgrade that changes the rejection

What breaks if you don't test

Skipping tests of the framework itself breaks nothing, because its maintainers run their own suites in CI. What breaks is your use of the framework where no test sends a request: a URL that a client calls with a trailing slash, or an authorization policy left off one controller. When unit tests call controller methods directly, users find those breaks.

What you lose if you over-test

Framework tests fail on upgrades for details your application never reads, such as the wording of a default validation message. A test that the template's WeatherForecastController returns five forecasts protects sample code you should delete. Each such test adds a file to fix on every upgrade.

What to do instead

Test your endpoints through the real request pipeline: WebApplicationFactory in ASP.NET Core, MockMvc in Spring, the Django test client. Send data that gives each outcome a different response.
Test the code you plug into the framework: middleware, filters, custom validators.
Keep the exact requests of clients you cannot update as fixed tests.
Upgrade the framework in its own pull request, and read the migration guide for changed defaults.

Procedure and references

When the answer changes

No test sends a request through the framework.
Your framework configuration decides who may see a page or what a customer pays.
Your team writes code that runs inside the framework.

Real incident + Code example

The slash that stopped the scanners

On a warehouse system I worked on, we moved to Spring Boot 3.0. Our MockMvc tests posted scans to /api/scans and passed. The handheld scanners, whose firmware we could not update, posted to /api/scans/. Spring Framework 6.0 stopped matching trailing slashes by default, as the Spring Boot 3.0 migration guide notes, so every scan got a 404. The night shift called within 20 minutes; we rolled back, and staff rescanned about 600 parcels. This test now sends the scanners' exact request:

@WebMvcTest(ScanController.class)
class ScannerRequestsTest {

    @Autowired MockMvc mvc;
    @MockitoBean ScanService scans;

    // Scanner firmware 2.x posts to this exact URL, trailing slash included
    @Test
    void acceptsTheUrlTheScannersSend() throws Exception {
        mvc.perform(post("/api/scans/")
                .contentType(MediaType.APPLICATION_JSON)
                .content("{\"barcode\":\"PKG-1042\",\"dock\":\"D7\"}"))
            .andExpect(status().isCreated());
    }
}

// The fix in ScanController: @PostMapping({"/api/scans", "/api/scans/"})

Sources

FAQ

Should you write unit tests for templates and frameworks?: No, do not unit test the code a project template generates or the features a framework provides. Delete the sample code, and test your own endpoints through the real framework.
Should I test functionality provided by the framework?: No, the framework's maintainers test its features in their own CI. Test how your application uses those features: send requests to your endpoints and assert the responses your clients need.
Do I need to retest the framework after an upgrade?: No, run your own suite against the new version in a pull request that contains only the upgrade. Add a test for a changed default only when your code or your clients rely on it, such as trailing slash matching in Spring Framework 6.0.
Should I test my custom middleware?: Yes, custom middleware is your own code, even though the framework runs it. Unit test its logic, and send one request through the pipeline to check that it runs before or after authentication as intended.