This is a follow up to

https://www.drupal.org/node/2782309#comment-11669209

In a PSR compliant way I want to find a better home for test specific traits.

A trait that can be used in Kernel, Function or maybe unit test for example the image module.

image
  tests
    src
      Kernel
      Functional 
      Unit
      Trait      <--- New Directory

I propose the trait directory is the ideal place to put ImageFieldCreationTrait but we need to makes changes for this to work.

Maybe phpunit is not the correct component for an autoloader discussion ... so please correct me.

Comments

martin107 created an issue. See original summary.

martin107’s picture

martin107 commented
Issue summary: View changes
pfrenssen’s picture

pfrenssen
Location Sofia
commented

Maybe we should call the directory Traits to be consistent with core/tests/Drupal/Tests/Traits. I'm personally more in favor for the singular Trait though.

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

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.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

Traits are supposed to be in module/tests/src/Traits/ with a namespace of Drupal\Tests\module\Traits\YourTraitHere.

That's how it's supposed to work, based on #2605664: [Needs change record updates] Align TestDiscovery and bootstrap.php's non-permissive loading of PSR-4 namespaces for traits Change record: https://www.drupal.org/node/2848889

An example here: #2803621: Break BrowserTestBase & children dependency on Simpletest, deprecate stub BC traits which has a change record that isn't published yet.

martin107’s picture

martin107 commented
Assigned: Unassigned » martin107

@Mile23, thanks for the definitive answer.. it is much appreciated.

cd core
find . -name *Trait.php | wc -l
120

ignoring the traits in core/modules/simpletest/src it will take a little effort :)

Thinking about the burden on the reviewer / committer.

Its seems wrong to break this into 20 or so small sub issues..
but if we follow cores's more conventional approach of ... fix it once and do it globally... It will be difficult to review.

That old chestnut...

I will start by doing the first 20 or so ... and others can dictate how I should proceed.

martin107’s picture

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

I am happy to limit the scope of this issue to test traits [*TestTrait.php]

There are a couple of landmines here... for example BasicAuthTestTrait has a soon to be deprecated version and conventional trait already in its final resting place.

I think we should delay until

#2803621: Break BrowserTestBase & children dependency on Simpletest, deprecate stub BC traits

just to be safe

It will be disruptive and 8.5.x-dev was opening overnight...

./modules/basic_auth/src/Tests/BasicAuthTestTrait.php -- do not move
./modules/basic_auth/tests/src/Traits/BasicAuthTestTrait.php --- already in place.
./modules/book/tests/src/Functional/BookTestTrait.php
./modules/comment/src/Tests/CommentTestTrait.php
./modules/config/src/Tests/SchemaCheckTestTrait.php
./modules/field/src/Tests/EntityReference/EntityReferenceTestTrait.php
./modules/field_ui/src/Tests/FieldUiTestTrait.php
./modules/file/tests/src/Kernel/Migrate/d6/FileMigrationTestTrait.php
./modules/media/tests/src/Functional/MediaFunctionalTestTrait.php
./modules/migrate_drupal/src/Tests/StubTestTrait.php
./modules/rest/tests/src/Functional/AnonResourceTestTrait.php
./modules/rest/tests/src/Functional/BasicAuthResourceTestTrait.php
./modules/rest/tests/src/Functional/BcTimestampNormalizerUnixTestTrait.php
./modules/rest/tests/src/Functional/CookieResourceTestTrait.php
./modules/simpletest/src/SessionTestTrait.php
./modules/simpletest/tests/src/Traits/TestTrait.php
./modules/system/src/Tests/Entity/EntityDefinitionTestTrait.php
./modules/taxonomy/src/Tests/TaxonomyTestTrait.php
./modules/taxonomy/src/Tests/TaxonomyTranslationTestTrait.php
./modules/taxonomy/tests/src/Functional/TaxonomyTestTrait.php
./modules/taxonomy/tests/src/Functional/TaxonomyTranslationTestTrait.php
./modules/user/src/Tests/UserResetEmailTestTrait.php
./modules/views/tests/src/Unit/Plugin/HandlerTestTrait.php
./tests/Drupal/Tests/ConfigTestTrait.php
./tests/Drupal/Tests/SchemaCheckTestTrait.php
./tests/Drupal/Tests/SessionTestTrait.php
./tests/Drupal/Tests/Traits/Core/Config/SchemaConfigListenerTestTrait.php

martin107’s picture

martin107 commented
Status: Active » Postponed

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.

kingdutch’s picture

kingdutch
he/him
Primary language English
commented
Status: Postponed » Active

The issue referenced in #7 has been fixed so I'm moving this back to Active. I think this would be cool to get in Drupal core because traits in Tests can be really useful and aren't always tied to a specific type of test :)

borisson_’s picture

borisson_
Primary language Dutch
Location Mechelen, 🇧🇪
commented

If we do this, we're going to have to deprecate all of those traits, that's not a big problem, we can't just move them.

mile23’s picture

mile23
Primary language English
Location Seattle, WA
commented

Sorry I was unclear in #5.

Traits which aren't shared between different types of tests can be anywhere as long as PSR-4 can find them. So leaving a trait in a \Functional\ namespace (or whatever applies) is fine, as long as only functional tests ever use it.

It's only the shared ones that should end up in \Traits\. Currently all the tests are working, so we don't need to move anything. If there are specific ones that need to be moved, we can move/deprecate them on a case-by-case basis.

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.

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.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.

smustgrave’s picture

smustgrave commented
Status: Active » Postponed (maintainer needs more info)
Issue tags: +stale-issue-cleanup

Thank you for creating this issue to improve Drupal.

We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!