[policy, no patch] Runtime Assertions Policy

Created on 3 February 2017, about 8 years ago
Updated 22 April 2025, 4 days ago

Runtime Assertions where introduced in Drupal 8.0 at the last moment without a long term plan for their phase in. I propose the following two rules moving forward:

Rule #1: If it ain't broke, don't break it.

The way Drupal 8 is currently set up adding a new assertion can cause contrib modules to fail in the dev environment until they are fixed if they made an incorrect call to the API, say by using an integer when the PHPDocs say to use a string. To avoid this I propose that moving forward the only new assertions added in the 8.x branch are those that stop the code from proceeding to a cryptic error state, such as in issue #2558079: Assertions in \Drupal\Template\TwigExtension β†’ . In that example if the code is in a state where the assertion would fail the system will crash anyway, so there will be no extant modules with the bad services configuration in question that would suddenly start failing. If they exist at all they'll already be failing, the assertion just means they fail in a more understandable way.

Rule #2: Unit Test assertions watching for bad YAML files

Under normal circumstances writing a unit test against an assertion is like writing a unit test for a unit test - redundant. For the assertions that are guarding against bad configurations though my opinion has changed to where I think it is worth the time to write a unit showing that the assertion will fire. Part of this is due to the nature of .yml files - they are sometimes edited by admin users and also get crafted as part of quick one-of modules that will likely never see rigorous unit testing.

If this sounds good to everyone I'll rewrite the pending TwigExtension assertion following this principle.

🌱 Plan
Status

Postponed: needs info

Version

11.0 πŸ”₯

Component

base system

Created by

πŸ‡ΊπŸ‡ΈUnited States Aki Tendo

Live updates comments and jobs are added and updated live.
  • Runtime assertion

    It deals with the addition of an assert() statement(s) to the code, and/or contains a test patch where one is failing indicating a need to change code or the documentation the statement was based on.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • πŸ‡³πŸ‡ΏNew Zealand quietone

    There has not been any discussion on this proposal in the 8 years it has been open.

    It is a policy statement needed for the use of assertions?

    I am setting the status to Postponed (maintainer needs more info). If we don't receive information to help with the issue, it may be closed after three months.

    Thanks!

Production build 0.71.5 2024