[wp-trac] [WordPress Trac] #42282: Provide means of executing PHPUnit continuously over watched files in local environments

[WordPress Trac]

#42282: Provide means of executing PHPUnit continuously over watched files in local
environments
-------------------------------+-----------------------
 Reporter:  iandunn            |       Owner:  iandunn
     Type:  enhancement        |      Status:  assigned
 Priority:  normal             |   Milestone:  5.0
Component:  Build/Test Tools   |     Version:  4.9
 Severity:  normal             |  Resolution:
 Keywords:  needs-docs commit  |     Focuses:
-------------------------------+-----------------------

Comment (by iandunn):

 Replying to [comment:14 pento]:
 > This seems fairly annoying to remember to run the right tests and watch
 the right files

 Agreed. I just tested the feasibility of watching the entire repo, rather
 than specifying `--files`. To my surprise, it doesn't seem to introduce a
 noticeable performance issue. That was on a 2013 MacBook Pro (2.7 GHz i7,
 16GB RAM).

 So, I think we can make the `--files` parameter optional, or just remove
 it entirely and always watch the whole repo. I'm leaning towards just
 removing it, since we can always add it back if we discover a need.
 [[br]]


 > [...] have a test group header at the top of each source file, that
 tells the watch job what tests should be run when that file changes

 I really like that idea, and would like to explore it more. If it works,
 that would definitely be more convenient than having to manually specify
 the group. Combined with removing `--files` (or making it optional), I
 think that would solve the problem.

 I think we'd still need to be able to specify `--group` manually, though.
 There may be situations where a file is associated with multiple groups;
 the user may only want to target a specific one, rather than waiting on
 all of them to run each time.
 [[br]]


 > Still not ideal, and would require a significant up-front effort. But
 maybe easier to work with long term.

 Were you thinking of the group header as a blocker for v1, or a future
 iteration? To me, it seems like the latter is more appropriate, since
 introducing that would be a simple addition to what's already in
 [attachment:42282.6.diff], rather than requiring any refactoring, or
 forcing users to learn new parameters, etc.

 I'm particularly concerned about it being a blocker, since I don't think
 I'll have time to do all the up-front work in the near/mid-future, and
 I've already found [attachment:42282.6.diff] to be very useful when
 working on other patches. (So much so that I've been manually merging it
 into every branch I work on, then removing it from the diffs I generate.)

--
Ticket URL: <https://core.trac.wordpress.org/ticket/42282#comment:15>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform