#44240 closed enhancement (fixed)
Avoid running full PHPUnit test suite for every PHP file change
Reported by: | jeremyfelt | Owned by: | jeremyfelt |
---|---|---|---|
Milestone: | 5.1 | 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)
Change History (11)
#2
@
7 years 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 thephpunit
_watch
task target will run. (existing behavior)
This ticket was mentioned in Slack in #core by jeremyfelt. View the logs.
7 years ago
This ticket was mentioned in Slack in #core by jeremyfelt. View the logs.
7 years ago
This ticket was mentioned in Slack in #core-privacy by birgire. View the logs.
7 years ago
#6
@
7 years 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:
↓ 8
@
7 years 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
@
7 years 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 checkinggrunt.cli.tasks[ 0 ]
?
I tested
grunt
without tasks and it doesn't seem to mind skipping such a check. Thegrunt.cli.tasks[ 0 ]
is also used elsewhere inGruntfile.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.
Makes sense 👍🏼