Content Guidelines: Add frontend test coverage by im3dabasia · Pull Request #76676 · WordPress/gutenberg

im3dabasia · 2026-03-19T11:42:54Z

Work in Progress

What?

Closes #76390
Parent issue: #76384

Adds the tests mentioned in the issue.

Use of AI Tools

Claude

dhruvikpatel18 · 2026-04-01T06:36:03Z

@im3dabasia, Can I work on Revision history interactions tests as it's not seem included in this PR. If you're open to that, please invite me to the collaboration for your branch.

github-actions · 2026-04-13T12:06:55Z

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: im3dabasia <[email protected]>
Co-authored-by: dhruvikpatel18 <[email protected]>
Co-authored-by: aswasif007 <[email protected]>
Co-authored-by: aagam-shah <[email protected]>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

im3dabasia · 2026-04-13T12:11:47Z

@andrewserong, @aagam-shah would appreciate your review on this PR when you get a chance

Copilot

Pull request overview

Adds Jest unit/integration-style tests to improve frontend coverage for the Content Guidelines feature, targeting store behavior and import/export and revision-history flows (per #76390 / tracking #76384).

Changes:

Added store unit tests covering selectors, action creators, and basic reducer immutability checks.
Added CRUD-oriented store tests validating category + block guideline updates and hydration from REST responses.
Added API import/export tests covering valid imports, partial imports, invalid input handling, rollback on save failures, and export JSON structure.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.

File	Description
routes/content-guidelines/tests/store.test.ts	Unit tests for store selectors/actions/reducer edge cases.
routes/content-guidelines/tests/guidelines-crud.test.ts	Store CRUD-style tests validating read/write/update “flows” via reducer+selectors.
routes/content-guidelines/tests/api-import-export.test.ts	Tests for `importContentGuidelines` / `exportContentGuidelines` behavior and rollback/export structure.
routes/content-guidelines/tests/revision-history.test.ts	Intended revision history coverage, but currently mocks the API module and doesn’t exercise the component logic.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Copilot · 2026-04-13T12:11:50Z

+// Mock dependencies
+jest.mock( '@wordpress/data' );
+jest.mock( '@wordpress/notices' );
+jest.mock( '../api' );
+


jest.mock( '../api' ) turns the API functions into mocks, but the tests then call fetchContentGuidelinesRevisions / restoreContentGuidelinesRevision directly. This makes the suite assert only that the mocked functions were called with the same args the test passed in, rather than exercising the real revision-history flow (the RevisionHistory component’s useEffect/handleRestore logic). Consider rendering components/revision-history.tsx with React Testing Library (mocking useSelect/useDispatch and the API module), or alternatively remove the API mock and unit-test the real api.ts functions by mocking @wordpress/api-fetch.

Copilot · 2026-04-13T12:11:51Z

+		test( 'should handle fetch error and dispatch error notice', async () => {
+			mockSelect.getId.mockReturnValue( 123 );
+
+			mockFetchContentGuidelinesRevisions.mockRejectedValue(
+				new Error( 'API Error' )
+			);
+
+			const noticesDispatch = ( dispatch as jest.Mock )( noticesStore );
+
+			await fetchContentGuidelinesRevisions( {
+				guidelinesId: 123,
+				perPage: 100,
+			} ).catch( () => {
+				noticesDispatch.createErrorNotice(
+					'Could not load revision history. Please try again.',
+					{ type: 'snackbar' }
+				);
+			} );
+
+			expect( mockDispatch.createErrorNotice ).toHaveBeenCalledWith(
+				'Could not load revision history. Please try again.',
+				{ type: 'snackbar' }
+			);


Several tests manually call noticesDispatch.createErrorNotice(...) / createSuccessNotice(...) inside the test itself (e.g. in .catch blocks) instead of asserting that production code dispatched these notices. This can pass even if the app never shows notices. Adjust the tests to trigger the actual code paths (render the RevisionHistory component and interact with it, or call a real implementation function) and assert the notice dispatches happen as a result.

Suggested change

test( 'should handle fetch error and dispatch error notice', async () => {

mockSelect.getId.mockReturnValue( 123 );

mockFetchContentGuidelinesRevisions.mockRejectedValue(

new Error( 'API Error' )

);

const noticesDispatch = ( dispatch as jest.Mock )( noticesStore );

await fetchContentGuidelinesRevisions( {

guidelinesId: 123,

perPage: 100,

} ).catch( () => {

noticesDispatch.createErrorNotice(

'Could not load revision history. Please try again.',

{ type: 'snackbar' }

);

} );

expect( mockDispatch.createErrorNotice ).toHaveBeenCalledWith(

'Could not load revision history. Please try again.',

{ type: 'snackbar' }

);

test( 'should reject when fetching revisions fails', async () => {

mockSelect.getId.mockReturnValue( 123 );

mockFetchContentGuidelinesRevisions.mockRejectedValue(

new Error( 'API Error' )

);

await expect(

fetchContentGuidelinesRevisions( {

guidelinesId: 123,

perPage: 100,

} )

).rejects.toThrow( 'API Error' );

Copilot · 2026-04-13T12:11:51Z

+			let state = createInitialState();
+			state.categories = {
+				site: 'Site',
+				copy: 'Copy',
+				images: 'Images',
+				additional: 'Additional',
+				blocks: {},


createInitialState() returns the store's DEFAULT_STATE object by reference (via reducer(undefined, ...)). This test then mutates state.categories directly, which can leak state across tests within this file and also hides potential immutability issues. Prefer constructing a new state object (e.g. shallow-clone createInitialState() and override categories) instead of mutating the returned state in-place.

Suggested change

let state = createInitialState();

state.categories = {

site: 'Site',

copy: 'Copy',

images: 'Images',

additional: 'Additional',

blocks: {},

let state = {

...createInitialState(),

categories: {

site: 'Site',

copy: 'Copy',

images: 'Images',

additional: 'Additional',

blocks: {},

},

aswasif007

Thanks for working on this!

Mostly good, but I've requested some improvements.

aswasif007 · 2026-04-14T08:05:18Z

+			await expect( importContentGuidelines( file ) ).rejects.toThrow(
+				'Save failed'
+			);
+
+			// Verify rollback was called
+			expect( mockDispatch.setGuideline ).toHaveBeenCalledWith(
+				'site',
+				'Original site'
+			);
+			expect( mockDispatch.setGuideline ).toHaveBeenCalledWith(
+				'copy',
+				'Original copy'
+			);
+		} );


Rollback tests can pass even if rollback is incomplete or out of order.
That's because The rollback assertions here only check that original values were called at least once, not that they are the final state after failure. If code regresses (e.g., writes original values and then overwrites again), these tests could still pass.

aswasif007 · 2026-04-14T08:06:51Z

+			// Verify rollback for block guidelines
+			expect( mockDispatch.setBlockGuideline ).toHaveBeenCalledWith(
+				'core/paragraph',
+				'Original paragraph'
+			);
+			expect( mockDispatch.setBlockGuideline ).toHaveBeenCalledWith(
+				'core/heading',
+				'Original heading'
+			);
+		} );


The implementation explicitly clears current blocks before restoring previous ones; this is important when import introduces new block keys. The test does not assert that clear step happened, so a regression in that path would be undetected

aswasif007 · 2026-04-14T08:08:32Z

+			expect( mockDispatch.setGuideline ).toHaveBeenCalledWith(
+				'site',
+				'Site guidelines'
+			);
+			expect( mockDispatch.setGuideline ).toHaveBeenCalledWith(
+				'copy',
+				'Copy guidelines'
+			);


Let's also assert the presence of the images and additional guidelines.

aswasif007 · 2026-04-14T08:15:21Z

+			const result = await fetchContentGuidelinesRevisions( {
+				guidelinesId,
+				perPage: 100,
+			} );
+
+			expect( mockFetchContentGuidelinesRevisions ).toHaveBeenCalledWith(
+				{
+					guidelinesId: 123,
+					perPage: 100,
+				}
+			);


I think we are calling the mocked function then asserting the test's own invocation.

aswasif007 · 2026-04-14T08:15:58Z

+		test( 'should handle fetch error and dispatch error notice', async () => {
+			mockSelect.getId.mockReturnValue( 123 );
+
+			mockFetchContentGuidelinesRevisions.mockRejectedValue(
+				new Error( 'API Error' )
+			);
+
+			const noticesDispatch = ( dispatch as jest.Mock )( noticesStore );
+
+			await fetchContentGuidelinesRevisions( {
+				guidelinesId: 123,
+				perPage: 100,
+			} ).catch( () => {
+				noticesDispatch.createErrorNotice(
+					'Could not load revision history. Please try again.',
+					{ type: 'snackbar' }
+				);
+			} );
+
+			expect( mockDispatch.createErrorNotice ).toHaveBeenCalledWith(
+				'Could not load revision history. Please try again.',
+				{ type: 'snackbar' }
+			);


aswasif007 · 2026-04-14T08:18:12Z

+			await restoreContentGuidelinesRevision(
+				guidelinesId,
+				initial.revisions[ 0 ].id
+			);
+
+			expect( mockRestoreContentGuidelinesRevision ).toHaveBeenCalledWith(
+				123,
+				1
+			);


same as above - we are calling a mocked function, then asserting that invocation.

aswasif007 · 2026-04-14T08:20:06Z

+			test( 'creates action with response payload', () => {
+				const response: RestGuidelinesResponse = {
+					id: 5,
+					status: 'draft',
+					guideline_categories: {
+						site: { guidelines: 'Site' },
+						copy: { guidelines: 'Copy' },
+						images: { guidelines: 'Images' },
+						additional: { guidelines: 'Additional' },
+					},
+				};
+
+				const action = actions.setFromResponse( response );
+
+				expect( action.type ).toBe( 'SET_FROM_RESPONSE' );
+				expect( action.response ).toBe( response );


The file validates the action shape, but not reducer output after parsing API responses, which is where most complexity lives (blocks handling, fallback defaults, nullable fields). A bug in response parsing could pass this suite.

…workflow

im3dabasia self-assigned this Mar 19, 2026

im3dabasia added [Type] Enhancement A suggestion for improvement. [Feature] Guidelines An experimental feature for adding site-wide editorial rules. labels Mar 19, 2026

im3dabasia marked this pull request as ready for review April 13, 2026 12:06

im3dabasia requested a review from Copilot April 13, 2026 12:06

Copilot started reviewing on behalf of im3dabasia April 13, 2026 12:07 View session

im3dabasia requested a review from andrewserong April 13, 2026 12:10

Copilot AI reviewed Apr 13, 2026

View reviewed changes

aswasif007 self-requested a review April 14, 2026 07:57

aswasif007 requested changes Apr 14, 2026

View reviewed changes

im3dabasia and others added 5 commits April 17, 2026 11:50

Content Guidelines: Add unit tests for CRUD operations

ebecca4

Content Guidelines: Add unit and integration tests for import/export …

05518b1

…workflow

feat: Add tests for store actions and selectors

c416697

test: Add unit tests for revision history interactions

aad171d

test: Add integration tests for full revision history flow

ab56bac

dhruvikpatel18 force-pushed the try/add-tests-76384 branch from 89e668b to ab56bac Compare April 17, 2026 06:21

Conversation

im3dabasia commented Mar 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Work in Progress

What?

Use of AI Tools

Uh oh!

dhruvikpatel18 commented Apr 1, 2026

Uh oh!

github-actions Bot commented Apr 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

im3dabasia commented Apr 13, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Copilot AI Apr 13, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 13, 2026

Choose a reason for hiding this comment

Uh oh!

aswasif007 Apr 14, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 13, 2026

Choose a reason for hiding this comment

Uh oh!

aswasif007 left a comment

Choose a reason for hiding this comment

Uh oh!

aswasif007 Apr 14, 2026

Choose a reason for hiding this comment

Uh oh!

aswasif007 Apr 14, 2026

Choose a reason for hiding this comment

Uh oh!

aswasif007 Apr 14, 2026

Choose a reason for hiding this comment

Uh oh!

aswasif007 Apr 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

aswasif007 Apr 14, 2026

Choose a reason for hiding this comment

Uh oh!

aswasif007 Apr 14, 2026

Choose a reason for hiding this comment

Uh oh!

aswasif007 Apr 14, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

im3dabasia commented Mar 19, 2026 •

edited

Loading

github-actions Bot commented Apr 13, 2026 •

edited

Loading

aswasif007 Apr 14, 2026 •

edited

Loading