The hardest thing I find with tests is understanding errors. Every time I think I’ve got debugging output sorted, I find a new layer where it doesn’t work, I’ve got nothing, and I’m in the dark with something that’s crashing and I don’t know why.
The first layer is simple: errors in your test code itself. For example, make a typo in your tests/src/Functional/MyTest.php and PHPUnit crashes and you see the error in the terminal.
But when it’s site code that’s crashing, you’re dealing with a system that is being driven by code, and therefore, you can’t see it. And that’s a major obstacle to figuring out a problem.
So we need to see logs. When a real site has an AJAX crash, with a human being-controlled web browser making the request, you can go and look in the logs. With a test site, the log table is zapped when the test is completed.
Fortunately, Drupal 8’s pluggable logging means there are other ways of getting hold of them, more permanent ways.
I first tried log_stdout module. This outputs log errors to STDOUT. If you’re running on Docksal, as I am, you have an extra layer to get though to see that. You can monitor the cli container with
fin logs -f cli, and with that module add a
| ag WATCHDOG to filter.
However, I wasn’t seeing backtrace in this output, and I gave up figuring out why.
So I tried filelog module instead, which as the name implies, writes log to a simple text file. This needs a little bit more work, as by default it writes to ‘public://logs’. This means that each run of the test gets its own log file, which is perhaps what you want, but for my own uses I wanted a single log file I could
tail -f in a terminal window and have continual monitoring.
A quick bit of config setting in the test’s setUp() does the trick:
$this->config('filelog.settings') ->set('location', '/var/www/docroot/sites/simpletest/logs') ->save();
And I think that’s me at last sorted.