Personally I wouldn't enable that by default in phpunit.xml.dist. If you want that locally, you can simply create a phpunit.xml that contains it. Imho seeing which tests are running is only a useful information while debugging. In all other cases you only need to know which tests are failing - and that is also available without testdox. Having it enabled also makes the output very very long, which also makes it slower to load the travis output in the browser.

Personally I wouldn't enable that by default in phpunit.xml.dist. If you want that locally, you can simply create a phpunit.xml that contains it. Imho seeing which tests are running is only a useful information while debugging. In all other cases you only need to know which tests are failing - and that is also available without testdox. Having it enabled also makes the output very very long, which also makes it slower to load the travis output in the browser.

In my case was different, I wanted to know where it failed on Travis because failed differently, but anytime we can just commit it when needed (probably or hopefully very rare) and when we fixed it, modify it back. This is what I did. I just wanted to know the team thinks about it :)

Personally finding it quite useful because it'll be there when you need it, and doesn't really cause too much harm when it's not needed. For me it loads as fast, the scrolling to the end takes a second though but that's it. Finding it also quite good to see how long each test took etc. The timings are not ongoing information you need every time though. Other people might not know how and where to set this flag when tests are not executing so it working instantly could be quite good. Especially also for community contributors etc. Luckily, we don't really have much problems anymore with builds timing out otherwise it would have been useful. I can also see though that it does add noise and we could enable it on demand but then ideally there be some output in travis run like this (could even include a link to an FAQ where we explain how to do it)

Overall no big preference and not seeing too much harm with adding it but ok either way if we at least add such a message.

@diosmosis any thoughts?

Not really, either way is fine for me.

@tsteur I don't think that "trigger another test run by doing...". if you modify the phunit.xml.dist to set the testdox to true, that will trigger the new test run anyway. Or I miss something?

And for me it wasn't an issue either, the result was longer on travis.

@tsteur @sgiehl @diosmosis
Do we want to merge this or I can close it?

@flamisz @sgiehl @diosmosis I would say let's just merge it and disable it again (and then instead print a message on how to activate this feature to troubleshoot when needed) should we find it not useful. Be good to simply give it a try for a while and if we find it a problem then change. In UI tests we've always been doing this and it never was an issue. @sgiehl @diosmosis @flamisz be important to mention if/when it becomes annoying (eg with heaps of other test failures or so) and then we change it again. Be also useful if it ever helps you to mention eg in slack channel or so "Hey this just helped me save time or find xyz".

It makes sense to try it first.

Let's simply merge then. We can later remove again if it might get annoying