Cannot enable both views_test_entity_reference and entity_reference_test in testing

Pushed fix. Ready for review!

Seems pretty straightforward, but should the view machine name start with the whole test module name to prevent future conflicts?

I can confirm this issue exists.

Steps to reproduce:

• Added entity_reference_test to the $modules array in FilterEntityReferenceWebTest.php
• Ran PHPUnit 10.5 with Drupal 11.2.3 and PHP 8.3
• Got the error:
  

  Drupal\Tests\views_ui\Functional\FilterEntityReferenceWebTest::testFilterUi
  Drupal\Core\Config\PreExistingConfigException: Configuration objects (views.view.test_entity_reference) provided by views_test_entity_reference already exist in active configuration

  Please see the screenshot

#2 Fix the Problem. Following the suggestion in #4, I created a new merge request that renames the view to use the full test module name as a prefix.
The view is now named views_test_entity_reference_view instead of test_entity_reference_view for better namespace isolation.

@solimanharkas there was already an MR though doing something very similar why a new one?

@smustgrave I wasn’t sure which ID / file name would be better, so I didn’t want to overwrite the existing solution in case it’s already correct and sufficient.

@solimanharkas while I appreciate the code review, given it has been less than 24 hours since I posted the MR and I hadn't yet had a chance to respond to @nicxvan comments, I am wondering if adding MR code comments with code suggestions or simply adding your suggested machine name in a comment might have been less confusing than adding another MR. If I hadn't replied in a few days, than I think jumping in and changing the existing MR would have also been ok.

@nicxvan thanks for the review and good point!

I have modified the machine name to include the module name but also tried to make it descriptive of what it is. I also changed the label and added a description to provide more information. I feel like this could help when writing new tests and seeing if there is an existing view that can be used instead of creating another one. Back to NR.

@solimanharkas given I have used a different machine name and made additional changes, I have hidden your MR to prevent confusion.

tame4tex → changed the visibility of the branch 3543036-views-test-entity-reference-naming-conflict to hidden.

@solimanharkas I just wanted to make sure it is clear we appreciate your help! Please don't be discouraged from contributing by the feedback here!

But to highlight there are a couple of general Drupal etiquette items as I see for core.

Generally for any issue it's customary to give the original author a couple of days to respond to feedback, especially if they have contributed recently. As mentioned if you still want to help in that situation opening MR suggestions can be a good way to do that. An important note, that creating suggestions based on another user's feedback may not always reach the bar of getting credit on a core issue.

Second, creating a new MR is usually reserved for a completely new approach or if an MR gets too far out of date so rebasing is not possible.

To summarize the preference is to give the contributor some time to reply and provide MR suggestions if you are trying to help out.

If it goes stale you can leave a comment mentioning you are going to pick it up, then you can push up the changes directly or create a new MR depending on what makes sense for the change your making.

I think this is good now!

Less likely to conflict and much more semantic for the name.

Thanks everyone!

Saving credit

Thanks @nicxvan & @smustgrave for the quick response!

@solimanharkas I want to echo @nicxvan’s comment, I definitely don’t want to discourage you from helping. We need all the help we can get! If my earlier comment came across otherwise, apologies. I really appreciate your review.

Thank you all a lot for your kind replies and respect . I really appreciate it.

And please @tame4tex , you don’t need to apologize at all. I truly value the feedback and support.

Honestly, the only reason I opened a new MR was because I wasn’t sure if adding commits to the existing one might break something that already works. I just wanted to be careful.

I don’t have much experience with Drupal core issues yet, but your comments really helped me understand the process better. I’ll know how to handle it next time.

Thanks again, it really means a lot.

Triaging the RTBC queue.

This is straightforwards as was said in #4. I applied the diff and searched for 'test_entity_reference' and confirmed that the correct instances are changed. I didn't find any that should be changed that are not. Well done.

I checked credit. Everything is in order here.

And thanks to @nicxvan for helping with how we work in the Drupal core issue queue.