Problem/Motivation
Sometimes, a system will log an error and carry on functioning, because that's the best thing to do in normal operation.
But in a test, the logged error is invisible, and we might want a test to either a) fail on an error, because something's gone wrong in the test, or b) expect the error, because we want to actually test the conditions that cause an error.
Examples of this include:
- The cron service catches exceptions thrown by hook_cron() implementations, logs them, and then continues as normal
- The queue runner catches exceptions thrown by queue workers, logs them, and then continues as normal
Proposed resolution
Add a way for tests to react to logged errors. It should be up to individual tests:
- whether to opt in to being aware of logs
- to fail a test if a log of specified type, of specified or greater severity, is generated
- to fail a test if a log of specified type is not generated
1. To keep the scope tight, this issue is focused on kernel tests as exceptions in the SUT in functional tests are significantly more complex to handle.
2. We create a new AssertableLogger class and register this as a logger, intead of registering the test itself as a logger, to reduce the surface area of KernelTestBase.
3. We created a LoggingTrait to use in KernelTestBase to facilitate future use in other kinds of tests, like functional tests or contrib ExistingSite tests.
4. We don't throw an expection immediately when a log is generated, as this might be swallowed by th SUT. Instead we store logs and evaluate them at the end of a test's execution.
5. To keep the scope tight, we do not opt in to expecting no logged errors in KernelTestBase, this will be explored in a follow-up issue.
User interface changes
None.
API changes
None.
Data model changes
None.