Remove all @deprecated code in test base classes

We cannot remove PhpunitCompatibilityTrait yet because the assertEquals override implemented in the PhpunitVersionDependentTestCompatibilityTraits is still needed.

I see 3 options:

• Do #3082340: Replace assertEquals() overrides in PHPUnit Kernel, Functional and FunctionalJavascript tests with a MarkupInterfaceComparator implementation first and then remove
• Remove the deprecated methods on PhpunitCompatibilityTrait and PhpunitVersionDependentTestCompatibilityTraits still leaving an empty PhpunitCompatibilityTrait that just uses PhpunitVersionDependentTestCompatibilityTrait
• Remove PhpunitCompatibilityTrait and make tests use PhpunitVersionDependentTestCompatibilityTrait directly when needed

#5 +1

Edit: actually there is #3063182: Remove PHPUnit 4.8 class aliasing BC layer for that

On this.

More removals / fixes.

Some more leftovers.

Aha so those are needed for running Simpletest tests... I guess we need to remove the trigger_errors for now, then, to avoid such confusion. Bad chance it was not done in the other issue.

edit - we need to remove the expected deprecation in tests, too

Doing #14 or whatever it needs there can be controversial, so I propose to tackle that separately. Re-uploading #11, which is good to go IMO

> Aha so those are needed for running Simpletest tests...

No, not for simpletest tests. For tests that have been converted from simpletest to phpunit without updating all those asserts. It was decided to push the deprecation back to D10 as the cost if keeping it is low and the amount of calls to those is massive.

Bunch of comments below, but nothing actionable, just some notes, so I think this is ready. Kind of expected this to remove old simpletest base classes in modules, but this is just about the testing component, makes sense.

1. +++ b/core/modules/system/tests/src/Functional/Entity/Update/SqlContentEntityStorageSchemaConverterTestBase.php
   @@ -124,7 +124,7 @@ public function testMakeRevisionable() {
    
          // Check that the correct initial value was provided for the
          // 'revision_translation_affected' field.
   -      $this->assertTrue($revision->revision_translation_affected->value);
   +      $this->assertTrue((bool) $revision->revision_translation_affected->value);
   

   Ah, these are legacy tests, that's why our @trigger_error() was ignored.

2. +++ b/core/modules/workspaces/tests/src/Functional/Update/WorkspacesUpdateTest.php
   @@ -55,15 +55,15 @@ public function testWorkspaceAssociationRemoval() {
        // Check that the 'workspace' field has been installed for an entity type
        // that was workspace-supported before Drupal 8.7.0.
   -    $this->assertTrue($entity_definition_update_manager->getFieldStorageDefinition('workspace', 'node'));
   +    $this->assertNotEmpty($entity_definition_update_manager->getFieldStorageDefinition('workspace', 'node'));
    
        // Check that the 'workspace' field has been installed for an entity type
        // which became workspace-supported as part of an entity schema update.
   -    $this->assertTrue($entity_definition_update_manager->getFieldStorageDefinition('workspace', 'taxonomy_term'));
   +    $this->assertNotEmpty($entity_definition_update_manager->getFieldStorageDefinition('workspace', 'taxonomy_term'));
    
        // Check that the 'workspace' field has been installed for an entity type
        // that has been added in an update function.
   -    $this->assertTrue($entity_definition_update_manager->getFieldStorageDefinition('workspace', 'path_alias'));
   +    $this->assertNotEmpty($entity_definition_update_manager->getFieldStorageDefinition('workspace', 'path_alias'));
    
   

   Thought about using assertInstanceOf but this will go away anyway in #3087644: Remove Drupal 8 updates up to and including 88**

3. +++ b/core/tests/Drupal/KernelTests/KernelTestBase.php
   @@ -781,12 +774,6 @@ protected function installEntitySchema($entity_type_id) {
      protected function enableModules(array $modules) {
   -    $trace = debug_backtrace(DEBUG_BACKTRACE_IGNORE_ARGS);
   -    if ($trace[1]['function'] === 'setUp') {
   -      trigger_error('KernelTestBase::enableModules() should not be called from setUp(). Use the $modules property instead.', E_USER_DEPRECATED);
   -    }
   -    unset($trace);
   -
   

   I've been wondering about this, I still don't get what will happen exactly now as we just remove the deprecation message without any actual BC code? I have a case in a project with a very complex kernel test where I need to install config before enabling another module, I guess I'll see what will happen.

4. +++ b/core/tests/Drupal/KernelTests/KernelTestBase.php
   @@ -913,10 +900,6 @@ protected function render(array &$elements) {
       */
      protected function setSetting($name, $value) {
   -    if ($name === 'install_profile') {
   -      @trigger_error('Use \Drupal\KernelTests\KernelTestBase::setInstallProfile() to set the install profile in kernel tests. See https://www.drupal.org/node/2538996', E_USER_DEPRECATED);
   -      $this->setInstallProfile($value);
   -    }
        $settings = Settings::getInstance() ? Settings::getAll() : [];
   

   not sure if this should be removed together with the other install profile stuff instead in #2831065: Remove BC layer from \Drupal\Core\DrupalKernel::getInstallProfile() but I guess here is fine too, unless other parts of that, this isn't blocked.

Filed #3104372: Fix Drupal\FunctionalTests\AssertLegacyTrait inconsistent deprecation messages.

Random test failure

Do we have an issue for removing \Drupal\system\Tests\Update\UpdatePathTestBase?

Applied this patch locally, and grepped for 'deprecated' and 'trigger_error' in classes matching *TestBase in /core/tests and only found the javascript deprecation handling in WebDriverTestBase, which is not legacy.

Adding issue credits

Fixed on commit

diff --git a/core/modules/file/tests/src/Functional/FileFieldTestBase.php b/core/modules/file/tests/src/Functional/FileFieldTestBase.php
index 66aad2265f..ec85536792 100644
--- a/core/modules/file/tests/src/Functional/FileFieldTestBase.php
+++ b/core/modules/file/tests/src/Functional/FileFieldTestBase.php
@@ -3,7 +3,6 @@
 namespace Drupal\Tests\file\Functional;

 use Drupal\Component\Render\FormattableMarkup;
-use Drupal\TestTools\PhpUnitCompatibility\RunnerVersion;
 use Drupal\field\Entity\FieldStorageConfig;
 use Drupal\field\Entity\FieldConfig;
 use Drupal\file\FileInterface;

Committed 62afe77 and pushed to 9.0.x. Thanks!

So \Drupal\Tests\PhpunitCompatibilityTrait as a whole did not have a deprecation and the comments in the methods that WERE deprecated said to use the same trait but with the createMock method. Which, ironically, doesn't exist.

This caused my contrib module tests to break in 9.0.x. I think because the traits themselves didn't have @deprecated so these wouldn't have been caught by deprecated warnings.

This should have a Change record to mention the removed traits and what should be done instead.

The change record at https://www.drupal.org/node/2907725 doesn't mention this.

Here's a draft change record: https://www.drupal.org/node/3112189

I linked to the change records for the @deprecated methods.

What brought me here and what was most confusing is that the PhpunitCompatibilityTrait deprecation is wrong and suggests that there is a createMock method available on that trait. It's not. It's on PHPUnit\Framework\TestCase directly. It may have existed, but I haven't dug that far into git history.

I'll update the change record related to PhpunitCompatibilityTrait::createMock once I dig into the history to find the issue that removed createMock or if it never existed at all.

Removing tag because this has a change record.