All TestBase derived tests now enforce strict configuration schema adherence by default

Configuration schema was originally introduced to help describe configuration for translations. Then it expanded considerably and is now used to export configuration entities automatically for example (unless you want to write code to manually define what to export). Configuration schema is also used to automatically typecast values to their expected types. This ensures that although PHP and web forms in general favour strings over all other types, the right types are used when saving configuration. That is important so when deploying configuration, only actual changes will show up in the difference, no random type changes. Schema enforces certain rules and best practices of configuration on its users, for example that each piece in the active configuration should have an owner. Finally configuration schema based configuration validation helps find several types of bugs in code that is otherwise not or incorrectly tested.

Therefore after a month+ of work to make all core tests pass strict configuration schema checking, we are making TestBase default to strictly check all configuration against configuration schemas. There are only a few tests exempt from this in the testing of the configuration system itself. This affects all contributed module developers writing TestBase (WebTestBase, KernelTestBase, etc.) extending tests. This may result in new test failures which indicate either issues in your schema, your configuration, your tests, migrations, etc. Either way it indicates that in some cases unexpected data structures are generated.

We suggest you work on fixing the fails not to work around them. Configuration schema helps enforce/understand deployment related best practices (configuration ownership) and enables you to integrate with automated solutions (eg. config entity persistence) as well as configuration translation. So not having a correct schema will come back to bite you. We found so many core bugs while doing this effort at #2183983: Find hidden configuration schema issues (in sub-issues). See #2381973: View wizard creates 'invalid' views out of the box, missing plugin_ids, insecure permissions or #2358269: Migration bugs in block visibility, field overrides, cron, maintenance settings and form modes found by configuration schema checking for examples.

If you really need to opt out of this default for now, set $strictConfigSchema to FALSE in your test while you work on fixing the schema/tests/code.

class NotPassingConfigSchemaYet extends WebTestBase {

  /**
   * Disabled config schema checking temporarily until all errors are resolved.
   */
  protected $strictConfigSchema = FALSE;

}

The documentation of configuration schemas has more details with examples.

Check out the cheat sheet at https://www.drupal.org/files/ConfigSchemaCheatSheet1.5.pdf, you'll find it useful.