WordPress.org

Make WordPress Core

Opened 4 weeks ago

Closed 2 weeks ago

#44240 closed enhancement (fixed)

Avoid running full PHPUnit test suite for every PHP file change

Reported by: jeremyfelt Owned by: jeremyfelt
Milestone: 5.0 Priority: normal
Severity: normal Version:
Component: Build/Test Tools Keywords: has-patch
Focuses: Cc:

Description

In current trunk, when using grunt watch to ensure that changed PHP files are copied from src/ to build/, the full PHPUnit test suite runs for every change. This takes somewhere around 4 minutes (on my local, non-VM config).

In #42282, a grunt watch:phpunit was introduced. This makes it possible to run a specific set of tests whenever working with PHP files. To work, this requires specifying a group - grunt watch:phpunit --group=testgroup.

That change, [42760], also added a phpunit grouping under the _watch config. At that time, a grunt watch command first fired webpack:dev. The webpack:dev task provided its own watch configuration through Webpack, and the core _watch command never fired. Whether intentional or not, the default PHPUnit suite did not run for every change.

With [43309], which refactored the build process for core, the webpack:dev task was changed to build. The _watch task is no longer blocked from running, and the full PHPUnit test suite runs.

If I remove the phpunit config from _watch, the current grunt watch takes 1-2 seconds rather than several minutes.

I think the idea behind #42282 is still right, but with the requirement that PHP files are copied to build/ before anything on the front end can be previewed, I don't think it should be mandatory.

I'd like to see grunt watch not run any PHPUnit tests by default, since PHP files don't historically require a "build" for their changes to be previewed.

It would be nice instead to see something like grunt watch --phpunit --group=testgroup for when you do want to run a select number of tests immediately on file change.

Attachments (1)

44240.diff (673 bytes) - added by jeremyfelt 4 weeks ago.

Download all attachments as: .zip

Change History (10)

#1 @netweb
4 weeks ago

  • Milestone changed from Awaiting Review to 5.0

Makes sense 👍🏼

@jeremyfelt
4 weeks ago

#2 @jeremyfelt
4 weeks ago

  • Keywords has-patch added; needs-patch removed
  • Type changed from defect (bug) to enhancement

44240.diff adds phpunit as a _watch task target when requested on the command line.

  • If grunt watch, PHP files are copied, all other _watch task targets will run.
  • If grunt watch --phpunit --group=testgroup, all _watch task targets will run, including PHPUnit, which will test against the specified groups.
  • If grunt watch:phpunit --group=testgroup, only the phpunit _watch task target will run. (existing behavior)

This ticket was mentioned in Slack in #core by jeremyfelt. View the logs.


4 weeks ago

This ticket was mentioned in Slack in #core by jeremyfelt. View the logs.


3 weeks ago

This ticket was mentioned in Slack in #core-privacy by birgire. View the logs.


2 weeks ago

#6 @birgire
2 weeks ago

Thanks for the patch @jeremyfelt

I tested it on a Linux node with:

1) $ grunt watch
2) $ grunt watch --phpunit --group=privacy
3) $ grunt watch:phpunit --group=privacy

and it seems to work as expected.

I tested to change the PHP file /src/wp-admin/includes/user.php, saved it and then:

  • The first and second copied the file to the /build/wp-admin/includes/user.php, but not when running the third one, as expected.
  • The first one runs now without PHPUnit tests, as expected.
  • The second and third activate the corresponding PHPUnit test group where the tests/phpunit/build/logs/junit.xml file is created or updated with relevant <testsuites> info, as expected.

Not related to this ticket, but I noticed that when I ran the second one on a clean dev trunk, I had to resume the (visual) process by pressing Enter, might have worked by pressing any key as well? This did not happen again, when I tried to replicate.

#7 follow-up: @birgire
2 weeks ago

I guess I'm too influenced by PHP array item checks, but should we check e.g. if grunt.cli.tasks.length > 0 since we are checking grunt.cli.tasks[ 0 ] ?

I tested grunt without tasks and it doesn't seem to mind skipping such a check. The grunt.cli.tasks[ 0 ] is also used elsewhere in Gruntfile.js without such a check.

#8 in reply to: ↑ 7 @jeremyfelt
2 weeks ago

Thanks for testing this!

Replying to birgire:

I guess I'm too influenced by PHP array item checks, but should we check e.g. if grunt.cli.tasks.length > 0 since we are checking grunt.cli.tasks[ 0 ] ?

I tested grunt without tasks and it doesn't seem to mind skipping such a check. The grunt.cli.tasks[ 0 ] is also used elsewhere in Gruntfile.js without such a check.

I think we're okay here as the only way to reach this area of code should by by specifying a task.

#9 @jeremyfelt
2 weeks ago

  • Owner set to jeremyfelt
  • Resolution set to fixed
  • Status changed from new to closed

In 43335:

Build/Test Tools: Avoid running full PHPUnit test suite for every PHP file change.

Use grunt watch --phpunit --group={testgroup} to start grunt watch with a specific test group so that PHP file changes trigger a limited number of tests.

Props jeremyfelt, birgire for testing.
Fixes #44240.

Note: See TracTickets for help on using tickets.