That custom printer was using some hacks to be able to intercept
configuration switches, reflection and other tricks to be able to
print the:
To re-run:
vendor/bin/phpunit --verbose "core_setuplib_testcase" lib/tests/setuplib_test.php
line on every failed/exceptional/skipped test. After some internal
discussion it was agreed that the normal phpunit output:
1) core_setuplib_testcase::test_localcachedir
Time is lower that allowed start value
Failed asserting that 1601976686 is equal to 1601976687 or is greater than 1601976687.
/var/www/html/lib/phpunit/classes/advanced_testcase.php:446
/var/www/html/lib/tests/setuplib_test.php:170
/var/www/html/lib/phpunit/classes/advanced_testcase.php:80
has already all the information at hand about how to rerun a test:
- vendor/bin/phpunit lib/tests/setuplib_test.php
- vendor/bin/phpunit --filter core_setuplib_testcase::test_localcachedir
- vendor/bin/phpunit --filter ::test_localcachedir
- vendor/bin/phpunit --testsuite componentname_testsuite
- vendor/bin/phpunit --config <<compoenent directory>>
- use --cache-result to get failed tests rerun with ease.
- ...
So better, let's use standard phpunit output and done. Also, note that,
with the upgrade to phpunit 8.5, the printer was not working correctly
any more, causing some switches, like --verbose ... to be ignored. Sure
it could have been fixed but, as commented above, no real need for all
that "parapheranlia" to print the rerun information.
It can be enabled if desired from CLI using the --cache-result
option (or modifying the phpunit.xml cacheResult to true).
That will create the .phpunit.result.cache files that,
later, can be used to easily repeat failed (defects) tests or
run the slow ones first and more. See the --order-by option
to know more about all the available criteria. For example:
./vendor/bin/phpunit --order-by=defects --stop-on-defect
(will run all the failed ones first, stopping on problem, useful
for TDD and other scenarios, not so much for complete runs or CI).
Also, added to .gitignore so they won't be committed ever.
This commit is part of work on Custom fields API,
to minimize commit history in moodle core the work of a team of developers was split
into several commits with different authors but the authorship of individual
lines of code may be different from the commit author.
This change also add fail-on-risky to travis to help pick these up, and
verbosity too.
We only fail on risky during Travis and not during normal output because
developers may want to debug tests.
Introducing both APIs in moodle along with:
- search_box widget to add a tiny search box
- admin settings with setup steps helper
- cache for search results
- template for a search result
- php unit stuff
Many thanks to Tomasz Muras, Prateek Sachan and Daniel Neis for their contributions, for starting this development
and for pushing for it to be completed. Also thanks to other contributors: Jonathan Harker and eugeneventer.
This commit defines the new /availability root folder, with
/availability/classes, /availability/tests, and
/availability/condition where the condition plugins will live.
Condition plugin prefix is availability_, e.g. availability_date.
Rationale for this organisation:
1. I was originally going to put this in /lib/availability but
it has been pointed out that putting even more junk in lib
is probably bad.
2. 'availability' and 'condition' are the two names used in code
to refer to this system ($CFG->enableavailability).
3. The prefix has to be short enough to allow database tables
(although in practice I assume that condition plugins will not
normally contain database tables).
The new API includes a Boolean tree structure that controls the
availability of an item.
AMOS BEGIN
CPY [availabilityconditions,core_condition],[restrictaccess,core_availability]
CPY [enableavailability,core_condition],[enableavailability,core_availability]
CPY [configenableavailability,core_condition],[enableavailability_desc,core_availability]
AMOS END
