Problem/Motivation

#2866894: Component tests should not use Drupal\Tests\UnitTestCase but PHPUnit\Framework\TestCase Made use of UnitTestCase outside of Core test invalid but didn't explicitly move UnitTestCase into the Core namespace where it effectively lives.

Proposed resolution

While its completely OK for contrib to use UnitTestCase we can help Core along by making its location more explicit and move it into the core namespace. We might even be able to get rid of the listener because the Core namespace will already be invalid.

Provide deprecated shell testcase for contrib BC.

Remaining tasks

Agreement
Decide on where removal happens. 9?
Patch
Review approach

User interface changes

N/A

API changes

Deprecates \Drupal\Tests\UnitTestCase

Data model changes

N/A

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

neclimdul created an issue. See original summary.

neclimdul’s picture

neclimdul’s picture

Status: Active » Needs review

bah, my comment got eaten. Patch for review and discussion.

Mile23’s picture

Title: Move UnitTestCase to Core namespace » Move UnitTestCase to Core namespace, deprecate old
Status: Needs review » Needs work
Issue tags: +phpunit initiative

+1 on normalizing test base classes to where they really belong. We should have a similar issue for BrowserTestBase.

We should do a deprecation process, though, so that we leave the deprecated stub and add a new class in one issue and then do replacements in another.

neclimdul’s picture

Right on.

There where a lot of changes in this, more then I expected, so I left BrowserCase for its own issue. It could be rolled in here it will just make rerolls a bit more unweidly until its committed.

Definitely on the stub. Its actually in the patch and it is marked @deprecated. Missing though is the required message pending the remaining task from IS of deciding when it gets removed so that definitely needs to work.

dawehner’s picture

@neclimdul
I think @Mile23 is talking about @trigger_error, see https://www.drupal.org/core/deprecation

neclimdul’s picture

Status: Needs work » Needs review
FileSize
741 bytes
291.13 KB

Made assumptions we'll deprecate in 8.5.x and remove in 9 and put trigger and deprecated message in. Thoughts?

dawehner’s picture

Do you mind creating a change notice and link it inside the code?

borisson_’s picture

Issue tags: +Needs change record
dawehner’s picture

+++ b/core/tests/Drupal/Tests/UnitTestCase.php
@@ -2,274 +2,14 @@
+
+@trigger_error('The '. __NAMESPACE__ . '\UnitTestCase is deprecated in Drupal 8.5.0 and will be removed before Drupal 9.0.0. Instead, use \Drupal\Tests\Core\UnitTestCase', E_USER_DEPRECATED);
 

The most recent discussion in #2607260: [meta] Core deprecation message introduction, contrib testing etc. seems to suggest that we should introduce this @trigger_error later, or at least add it to the exclusion list.

neclimdul’s picture

Not sure I understand. 1) is it deprecated or not. 2) are we not targeting dev with this?

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.

borisson_’s picture

Status: Needs review » Needs work

#11, it is deprecated but we should add it to the exclusion list. Setting to needs work to do that.

neclimdul’s picture

I still don't get the hold up. 1) that issue is open/active not accepted. 2) we seem to meet the requirements.

If core is not using deprecated code, it can be removed from that skipped deprecation list as long as the new API is available in a tagged release (at least alpha, stable if it's a widely used API) - this can be checked by consulting the change record for the deprecation.
Core note using code: we're removing usage ✔
Available in tagged release: wonky wording but we're targeting MINOR release not PATCH so there should be no problem. ✔

Mile23’s picture

After #2949363: Impossible to make trigger_error in some files without test fails we don't need to add the deprecation error to the exclusion list. We might need to update the work from #2973127: Exclude *TestBase.php, *Trait.php and *Interface.php files from test discovery reflection if it's committed first, or update that issue if this one is committed first, so it also excludes *TestCase.php.

+++ b/core/tests/Drupal/Tests/UnitTestCase.php
@@ -2,274 +2,14 @@
+@trigger_error('The '. __NAMESPACE__ . '\UnitTestCase is deprecated in Drupal 8.5.0 and will be removed before Drupal 9.0.0. Instead, use \Drupal\Tests\Core\UnitTestCase', E_USER_DEPRECATED);
...
+ * @deprecated in Drupal 8.5.0 and will be removed before Drupal 9.0.0.

Needs an update to 8.6.0.

Also some semi-related stuff, based on the IS here: #2943856: [meta] Reorganize Components so they are testable in isolation and #2943842: Allow component namespaces to be autoloaded independently

neclimdul’s picture

Status: Needs work » Needs review

Rebuilt this from scratch so no interdiff. Was easier to start from scratch and use PhpStorms refactor tool to avoid all the merge use conflicts and to get any new tests.

re #15
#2973127: Exclude *TestBase.php, *Trait.php and *Interface.php files from test discovery reflection 1) So many questions... As it doesn't pertain to this issue I'll skip them and follow up in other issues. Don't see anything we need to do for this issue either.

Trigger is 8.6.0 now.

The component issues do seem tangentially related though since we take pains to block components from using this test base the connection is limited. :) Thanks for the heads up though!

neclimdul’s picture

woops, rusty at this. Here's the patch.

Mile23’s picture

1) So many questions... As it doesn't pertain to this issue I'll skip them

Those issues allow you to say @trigger_error() in a file that might be read during test discovery.

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.

borisson_’s picture

We still need that change record, this patch doesn't apply anymore either.

neclimdul’s picture

Status: Needs review » Needs work

Sure

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.

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.

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.

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

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.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.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.