Skip to main content
Gutenberg contains both PHP and JavaScript code and encourages comprehensive testing for both.

Why Test?

Tests are important because they:
  • Help ensure the application behaves as expected
  • Provide concise examples of how to use code
  • Prevent regressions when making changes
  • Document expected behavior
When writing tests, consider:
  • What behavior(s) are we testing?
  • What errors are likely to occur?
  • Does the test actually test what we think it does?
  • Is it readable and maintainable?

JavaScript Testing

Test Framework

Gutenberg uses Jest as the test runner with:

Running JavaScript Tests

Code Linting

Test File Structure

Keep tests in a test folder alongside your code:

User Interactions

Use @testing-library/user-event for simulating user interactions:

Integration Testing for Blocks

Test blocks within a special block editor instance:

Snapshot Testing

Snapshots capture component output:
Updating Snapshots:

Debugging Tests

Debug tests using Node inspector:
Then connect a debugger:
  1. Open chrome://inspect in Chrome
  2. Click “inspect” under Remote Target
  3. Set breakpoints and debug

End-to-End (E2E) Testing

Running E2E Tests

E2E tests require wp-env to be running:

Playwright Tests

New E2E tests should use Playwright:

PHP Testing

Running PHP Tests

PHP tests use PHPUnit and require wp-env:

PHP Code Standards

Testing Prefixed Functions

Gutenberg’s build system prefixes PHP functions with gutenberg_. Always test the built (prefixed) versions:

Performance Testing

Run performance tests to monitor editor metrics:
Metrics tracked:
  • Editor load time
  • Typing response time
  • Block selection time

Mobile Testing

React Native Unit Tests

Mobile E2E Tests

Mobile E2E tests run in CI on Android and iOS. See the React Native Integration Test Guide for details.

Test Quality Guidelines

Write Readable Tests

Describe expected behavior from a user perspective:

Setup and Teardown

Use Jest lifecycle methods:

Mocking Dependencies

CI and Flaky Tests

Tests that pass and fail without code changes are considered flaky. The CI system:
  • Auto-retries failed tests up to twice
  • Reports flaky tests to GitHub issues under the [Type] Flaky Test label

Next Steps