1/ 'phpunit' collides with admin/tool/phpunit, 'unittests' collides with current simpeltest UI, 'test' could collide with modules, the only reasonable name I found is 'tests' which seems matching to current special purpose db, pix, lang directories. Also in future we may need to add more test files - we could create subdirectories in /tests/ which would prevent more reserved directory names.
2/ table prefix length is database dependant - the limit is 2 chars for Oracle only and non-empty for all databases, longer prefixes are valid for MySQL and PostreSQL; the DML driver tells you when the prefix is not supported or it fails during install.
3/ web runner UIs can be done later in admin/tool/phpunit - I am not going to work on it now, the TODOs reflect what I am going to do before 2.3 release; feel free to work on that
4/ phpunit is not PHP library - it is command line tool, PHPUnit is not required to run Moodle, author of PHPUnit encourages to always use PEAR (I can not find the exact page now where he said that), the size of all required and recommended libs is relatively big and it needs some extra PHP extensions we do not require in moodle - I try really hard to get rid of as much PEAR as possible from Moodle distribution, adding non-essential libs would soon lead to redistribution of all PEAR libs; sorry I strongly disagree here
5/ dataroot should be imo completely separate - it uses different owner and permissions; standard temp may be purged at any time; I want to separate production sites as much as possible
- phpunit_manager - I agree, it evolved over time and the name lost its meaning - changing
- basic_testcase - it does not do much, no idea how to call it
- advanced_testcase - I do not know what is it going to do, pretty much everything else basic does not, what name woudl you propose?
7/ the testcase are distinct from stock PHPUnit classes, theoretically they would not even have to use phpunit, I do not think the "phpunit_" prefix is actually helpful, but I agree we need something that can not collide with the rest of moodle and libraries
8/ PHPUNIT constant will be in more places over time, in any case it can be changed later because the tests do not use it directly, only the bootstrap process and core
9/ I did not manage to allow custom file name pattern when executing phpunit on one specific directory (and believe me I tries very hard). I do not see any major problem in that, I never liked our camel_case rules. If we find a way to support "*test.php" we can change it before release - changing case in future will not be possible (it creates very nasty problems in case-insensitive filesystems).
10/ I discussed all details with Eloy. Apart from the naming rules there is not much to discuss I think. The code is self-contained and even if it gets integrated on Monday it can be changed easily before release (still a few months away) and even then it will be semi-experimental. Martin wants to get this integrated asap, it was already delayed 2 months thanks to my illness and now by one week thanks to releasing, sorry.
- I will rename phpunit_manager to phpunit_util
- I will add forgotten functional DB tests to readme.md TODO
- we need to decide basic_testcase naming - does not seem right, but I have no idea how to improve it (I do not like phpunit_ prefix)
- I will remove advanced_testcase for now until we know more about it
- somebody needs to double check if it is not possible to have *test.php file name pattern when running phpunit with directory parameter (by reading the PHPUnit source code)
Thanks very much for all your valuable feedback, you have highlighted the same area I was myself not sure about. If you agree with my arguments above I would add more FAQs to the readme file, if we do not agree I guess it would be safer to delay the integration by one week.
To integrators: please do not integrate before regular meeting on Monday