I don't think we need a test for this. The supportsPagination is a "static" value; as long as taxonomies load from the server, it will be there.

I guess the value in this test is to make sure no one deletes the prop by accident! 😄

Exactly, the reason to test the configuration is that I spent a lot of time trying to understand why taxonomies didn't explicitly support pagination, whether it was an oversight or there was a specific reason. Testing it makes it explicit, but I don't feel too strongly, we have the original PR as history/context.

We could just mock the full return value here, instead of running loadEntities in setup.

Do you mean something like

		const resolveSelect = {
			getEntitiesConfig: jest.fn().mockResolvedValue( [
				{
					baseURL: '/wp/v2/categories',
					baseURLParams: { context: 'edit' },
					kind: 'taxonomy',
					name: 'category',
					supportsPagination: true,
				},
			] ),
		};

Depends on what we're testing. If the "unit" is testing the getEntityRecord's resolver's pagination logic (&per_page=2&page=1), then yeah that makes sense to me in terms of test isolation and clearer intent.

There's less integration coverage, by which I mean, we're not testing the full flow from entity loading to pagination, but is that the intent of the test?

If not, then entity loading could have its own separate tests later on. I see this PR has already started in entities.js.

Another reason to isolate is if the entity loading logic ever has bugs, it could affect these tests. Pretty edge case. No blocker though from me.

I think we're just testing getEntityRecord's pagination logic, and not entity loading.

I'm not sure I follow; if we mock the entity config and set supportsPagination: true, we will not be testing that taxonomies are indeed paginated after #71302. We would test that pagination works when setting supportsPagination to true, but not verify that the settings are correct. 🤔