Re: Proposal to run all tests with and without strict_types enabled

> > 2018-02-11 20:34 GMT-03:00 Christoph M. Becker <cmbecker69@gmx.de>: >> >>> Umm, I wonder whether a magic constant (say, >>> __STRICT_TYPES__) would >>> be more appropriate. >> >> Implement __STRICT_TYPES__ was a breeze, very hackable codebase. A magic constant indeed sounds more appropriate. Hi Stanislav, 2018-02-12 2:18 GMT-03:00 Stanislav Malyshev <smalyshev@gmail.com>: > I am not sure what would be the advantage of this. Beyond testing > strict_types functionality itself (which of course should have its own > unit tests), the tests that test standard functioning of any function > would either supply correct arguments and then strict_types would be > irrelevant (provided it works as supposed to, which is tested by its own > tests) or provide incorrect arguments, and then strict_type tests should > be different from regular ones since the errors would be different, so > we'd have to write separate tests. > So it's a lot less useful than what I thought. > The only class of errors that could be found this way would be if we > somehow made such a mistake in defining the arguments of certain > function that strict_type version of it doesn't work but regular version > works fine. Which I guess is possible but does it worth the effort to > convert all tests? Not sure. > But it's still useful, I just fixed a bug exactly about it. Given that there is very few tests that use strict_types, to "convert" all tests with run-test -t is not too hard. Anyway all tests other than for incorrect arguments should run correctly with -t, so it may be a default for testing. The problem than is to know wich tests mus be runned without it. https://github.com/php/php-src/commit/fddd7e38bd01bc6dbc473166dd6f92 e9f81a6eab Besides testing, may or may not be valuable expose a __STRICT_TYPES__ constant. https://github.com/php/php-src/compare/master... pslacerda:experimental/strict_testing?diff=split -- Atenciosamente, Pedro Lacerda