I was thinking about making some improvements to our venerable test runner,
however I wasn't feeling confident about improving the present code base.
Instead, I decided to attempt to refactor it.
Here's my work in progress: https://github.com/MaxSem/run-tests
It requires Composer only for development, and has a script to make a
single-file distribution, functionally identical to what we presently have.
When it comes to integration with php-src, it could be moved to a
subdirectory there or be kept in a separate repository and be used to
generate a new run-tests.php whenever needed.
Is there interest in this, should I continue? Any suggestions?
--
Best regards,
Max Semenik
I was thinking about making some improvements to our venerable test runner,
however I wasn't feeling confident about improving the present code base.
Instead, I decided to attempt to refactor it.This is a perennial topic and I don't want to discourage you,BUT...
run-tests.php has a disturbing number of modes and edgecases, and the
preference has traditionally been for small movements which are easily
understandable individually. That's not to say a full-refactor won't get
support, but it's a big undertaking and has defeated many brave souls.
-Sara
I was thinking about making some improvements to our venerable test runner,
however I wasn't feeling confident about improving the present code base.
Instead, I decided to attempt to refactor it.Here's my work in progress: https://github.com/MaxSem/run-tests
It requires Composer only for development, and has a script to make a
single-file distribution, functionally identical to what we presently have.When it comes to integration with php-src, it could be moved to a
subdirectory there or be kept in a separate repository and be used to
generate a new run-tests.php whenever needed.Is there interest in this, should I continue? Any suggestions?
Happy to accept run-tests refactorings in general (there is a lot of global
state to eradicate!), but please keep it single-file. We definitely need it
single-file for distribution purposes, and I don't particularly want to
have a "run-tests build system" for what I perceive to be little benefit.
I'm not sure why PHP developers in particular seem to be so hung up about
this issue, but: There really is no need to split every class into a
separate file. This is how we develop in non-PHP, non-Java languages
(C/C++/Rust/...) all the time.
Regards,
Nikita
This is a perennial topic and I don't want to discourage you,BUT...
run-tests.php has a disturbing number of modes and edgecases, and the
preference has traditionally been for small movements which are easily
understandable individually.
That's why it's being done in a separate repository and every commit is
tested to work. But yeah, once I get around to adding tests, suggestions of
more things to test for will be appreciated.
Happy to accept run-tests refactorings in general (there is a lot of
global state to eradicate!), but please keep it single-file. We definitely
need it single-file for distribution purposes, and I don't particularly
want to have a "run-tests build system" for what I perceive to be little
benefit.
Once I add tests, it will just not be a single-file project anymore.
I'm not sure why PHP developers in particular seem to be so hung up about
this issue, but: There really is no need to split every class into a
separate file. This is how we develop in non-PHP, non-Java languages
(C/C++/Rust/...) all the time.
<philosophy>Because PHP taught them to: can't have a serious project
without the autoloader, can't have a sane autoloader without per-class
files (PSR-4 is as it is not due to its developers' preferences, but
because it was the most reasonable thing to do). If only there was a way
for classes to be automatically and seamlessly located from PHP core
itself...</philosophy>
My split into multiple files wasn't dogmatic, but purely pragmatic: a 3722
line file is too big for my liking (as in, it's too hard to find my way
through it, even if the code is organized neatly into classes), and the
number of lines will only grow. Also, it's way easier to have one tab per
class. =)
--
Best regards,
Max Semenik
Happy to accept run-tests refactorings in general (there is a lot of
global state to eradicate!), but please keep it single-file. We
definitely need it single-file for distribution purposes, and I
don't particularly want to have a "run-tests build system" for what
I perceive to be little benefit.Once I add tests, it will just not be a single-file project anymore.
I don't think tests are the relevant issue here. Nikita is asking to
keep it a single file project for the test runner. I agree with that
position.
I'm not sure why PHP developers in particular seem to be so hung up about
this issue, but: There really is no need to split every class into a
separate file. This is how we develop in non-PHP, non-Java languages
(C/C++/Rust/...) all the time.<philosophy>Because PHP taught them to: can't have a serious project
without the autoloader
You don't need an autoloader if it's all in the same file. ;-)
cheers,
Derick
I was thinking about making some improvements to our venerable test
runner, however I wasn't feeling confident about improving the present code
base. Instead, I decided to attempt to refactor it.Here's my work in progress: https://github.com/MaxSem/run-tests
Aaand, here's first step: https://github.com/php/php-src/pull/6671
As requested, I'll submit changes in small chunks and keep everything in
one file. Note: the plans of making a perfect refactor in a separate
repository were definitely a mistake on my part due to the constant need to
stay up to date with php-src. I'm thus backporting my changes there and
will continue new changes as they're ready.
--
Best regards,
Max Semenik