Problem/Motivation
JSON:API has extensive test coverage, but when a test fails, debugging and identifying the root cause can be extremely complicated and time-consuming. One of the challenges arises when the Dynamic Page Cache headers do not match the expected values. Currently, the JSON:API test suite contains numerous hardcoded header values (likely intended as an extra safety measure). However, many parts of the tests rely on other expectations, such as the expected response, cache tags, contexts, and max ages.
I propose leveraging the expected cache contexts to auto-generate the expected Dynamic Page Cache header values. This approach would help prevent unexpected test failures that occur when refactoring or modifying the codebase, thereby improving test reliability and maintainability.
The MR in this issue was forked out and contains the work I did in #3278759: Access cacheability is not correct when "view own unpublished content" is in use, where I personally encountered the difficulties caused by the current system. Additionally, I realized today that the tests in #2998824: MediaAccessControlHandler update/delete access caching is not correct are most likely failing for similar reasons to those I faced in my previous issue.
Why now?
You might wonder why these improvements have become necessary now and whether they are purely code enhancements or something more. They are indeed more significant. The changes in #3278759: Access cacheability is not correct when "view own unpublished content" is in use introduced variability in node access per user in certain cases, resulting in an UNCACHEABLE state. However, fixing Node's JSON:API tests to account for this caused other tests to break. What becomes UNCACHEABLE in the context of Node remains MISS in the context of Media, Block Content, or other entities. While many of the asserted values could be overridden in ResourceTestBase subclasses, the Dynamic Page Cache headers could not be overridden until now.