Problem/Motivation

There doesn't appear to be an easy or consistent way for tests to assert that a message has been logged (via a logger channel, not to the screen).

The workaround is to enable the dblog module for any test needing to assert that a message is logged, but this seems overly complicated.

Proposed resolution

Add a test logger channel for kernel and browser tests, and a method assertLog() to the base classes (via a trait). Since log messages need to persist past page requests (for Browser tests anyway), either the state backend, or a cache backend, can be used to store the logs for the duration of the test.

Remaining tasks

User interface changes

API changes

Data model changes

Comments

jhedstrom created an issue. See original summary.

dagmar’s picture

dagmar
Primary language Spanish
Location Argentina
commented

I like this idea. I will allow to isolate a lot of tests.

There are fundamentally 3 operations regarding tests that I have seen while working on the dblog.module issue queue:

  1. Find the last log.
  2. Find a log by a message
  3. Ensure there are no logs for a given type, message, etc

I will post others use cases if I found them.

There is a plan to swap the storage backend for dblog here: #2458191: Provide a storage backend for dblog module it would be nice to have the same (or at least most of the) functionality that implements the LogStorageInterface

jhedstrom’s picture

jhedstrom
Primary language English
Location Portland, OR
commented

it would be nice to have the same (or at least most of the) functionality that implements the LogStorageInterface

I'd like to see this be independent of the dblog module, but if we moved that storage interface into core, we could use it here. However, that might be overkill here, as I'm thinking this would work more similarly to the AssertMailTrait used for tests (this just captures emails in an array).

I'm going to work on a proof-of-concept.

jhedstrom’s picture

jhedstrom
Primary language English
Location Portland, OR
commented
Title: Add an in-memory logger channel for test bases classes to use » Add an test logger channel for test bases classes to use
Issue summary: View changes

I realized we can't use in-memory (except for kernel tests), since log messages will be generated on page requests. We can use the state backend (that's what email testing system uses) , or perhaps just the cache backend system...

cilefen’s picture

cilefen commented
Category: Feature request » Task
dagmar’s picture

dagmar
Primary language Spanish
Location Argentina
commented

We can use the state backend

Well, in that case we just need to wait until #2458191: Provide a storage backend for dblog module provide the consistent way to fetch a log. I don't see the need to re-create the dblog functionality using another table. @jhedstrom do you see any other benefit of doing this that I'm not seeing?

jhedstrom’s picture

jhedstrom
Primary language English
Location Portland, OR
commented

@dagmar that makes sense to me. My proof-of-concept stalled out because re-creating dblog in a php-backend (eg, memory, or cache table) was non-trivial.

claudiu.cristea’s picture

claudiu.cristea
Primary language Romanian
Location Arad 🇷🇴
commented

I think this should be available also for KernelTestBase. Often we do workarounds to test logged messages in kernel tests.

dawehner’s picture

dawehner
Primary language German
commented

Well, in that case we just need to wait until #2458191: dblog is SQL bound provide the consistent way to fetch a log. I don't see the need to re-create the dblog functionality using another table. @jhedstrom do you see any other benefit of doing this that I'm not seeing?

The only way we have to ensure is that you don't have to install the dblog modue to use this piece of functionality ...

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

mile23’s picture

mile23
Primary language English
Location Seattle, WA
commented
Title: Add an test logger channel for test bases classes to use » Add a test logger channel for test base classes to use

It seems like the solution here would be to create a test logging service that keeps the log in memory. Then you assert on its accessors.

Given that, we'd need to add it to the container in CoreServiceProvider::registerTest().

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

joachim’s picture

joachim commented

Similar issue with a wider scope: #2903456: Allow kernel tests to fail or expect logged errors.

Part of the plan there is to add a logger that logs to site state, which would work for the use cases here.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

joachim’s picture

joachim commented
Status: Active » Closed (duplicate)

Given the lack of feedback, I'm closing this as a duplicate.

mile23’s picture

mile23
Primary language English
Location Seattle, WA
commented

FTR: drupal/core-dev now requires colinodell/psr-testlogger, which meets these needs.

mile23’s picture

mile23
Primary language English
Location Seattle, WA
commented
Related issues: +#3321905: Add colinodell/psr-test-logger to core's dev dependencies