Create ParagraphsTestBaseTrait.

Will work on this.

Duplicated code from test bases moved to the trait. This leads to Experimental test base being obsolete, and completely removed.
Now the tests from Experimental widget are extending ParagraphsTestBase. Trait is being used only in tests where needed.

I made mistake with 'entity_reference_paragraphs' and 'paragraphs' and assigned them to wrong widgets.

All previous changes are dropped. After discussion with @Berdir we agreed that it is better to keep ExperimentalTestBase without changes, and keep the logic separated for two widgets. Here, we create the Trait for all future JS tests to be used.

Adding parameters to make difference between widgets.

This looks fine for me. We have some basic function that we can continue to work on other issue which are waiting this to be committed.

Nice!

+++ b/tests/src/FunctionalJavascript/ParagraphsTestBaseTrait.php
@@ -0,0 +1,104 @@
+   * @param string $paragraphs_type
+   *   Declares if we use experimental or classic widget.
+   */

Maybe $widget_type is more appropriate here.

Also IMHO we should explicitly state which two options are available. Ie: "Options are: ..."

Addressing comment #10.

Any more feedback here?

I am not pretty sure that name is ok for the trait. I think that should have something which will associate that is trait for JS testing.

I disagree with the comment #13. This trait can be later used for all of the tests, not only JS. We can just call the namespace and use it in both Experimental and Classic tests.

The general idea was to do not mix the experimental and classic widget, we are creating this trait only for JS tests.

Here's why the two worlds should not be mixed:
Say the new widget changes functionality, people start to mangle / alter the test trait. Then they will update the classic trait calls to make the classic still work. This risks that they update it just to make the tests pass - while possibly not understanding what was (and still is) broken.

So every change on the new widget should not interfere with the old widget. This can only be reached by separating traits and bases.
Review complexity and cost of all issues significantly rise and speed is reduced otherwise.

But in general, a common trait makes sense, as long as those methods are NOT using the widget UI - instead just use the entity API to create resources. :-)

My proposal is then to have that in tests/src and rename it to something that carries the information that we just want to have entity api paragraphs creation stuff in there. Perhaps TestParagraphGeneratiopnTrait? If we find in the future that we could have other general trait stuff, we could have more traits if those are unrelated. Thoughts?

Added check for creating the field storage.

If we take the approach from #17, do we want to update existing tests where relevant (even though we stated differently in #7)?

What we want to keep separate are widget interaction methods and test helpers. A common trait for those are the wrong direction.

Helpers to create entities through entity api (zero UI interaction) are a healthy trait to share and apply to both widgets.

Then I think moving this back to Needs work is fine

Agree. I see the trait here, but it's not used.
For sure, introducing this Trait only makes sense if we use it and through that, the patch will proof that the test code is getting more beautiful - for instance through less repetition.

Replaced the test bases methods with the trait and adjusted tests accordingly.

+++ b/tests/src/FunctionalJavascript/ParagraphsTestBaseTrait.php
@@ -0,0 +1,111 @@
+  protected function addParagraphsField($entity_type_name, $paragraphs_field_name, $entity_type, $widget_type) {

IMHO we should default $widget_type to 'paragraphs' here and not change those calls above.

Also default the $paragraphs_field_name to something and unify it / skip it wherever possible to field_paragraphs. Currently we also have at least paragraphs and paragraphs_field.

Committing for the current improvements, back to work for the proposed transformation.
Chances are that we broke tests of Paragraphs Collection or other project tests building on top of our traits?

Added defaults params and modified some function calls that didn't need a lot of changes.

Re-uploading with some minor changes

Retry for applying patch

+++ b/src/Tests/Experimental/ParagraphsExperimentalAddModesTest.php
@@ -19,15 +19,15 @@ class ParagraphsExperimentalAddModesTest extends ParagraphsExperimentalTestBase
+    $this->addParagraphedContentType('paragraphed_test');

@@ -54,7 +54,7 @@ class ParagraphsExperimentalAddModesTest extends ParagraphsExperimentalTestBase
+    $this->addParagraphedContentType('paragraphed_test', 'paragraphs');

Why do we need to have here an own field and can't use the default field? (lots of similar locations)

Agree, this leads to lots of renames. We can commit some intermediate update without #30 rename.

I tried to apply the patch locally, but i have many errors from the test run. Need to investigate what the problem is here.

Fixed the error in ParagraphsExperimentalAddModesTest, now locally web tests are passing

Needs refactoring after the container summary was committed.

Removed unneeded function in summary test.

+++ b/tests/src/FunctionalJavascript/ParagraphsTestBaseTrait.php
@@ -26,7 +26,7 @@ trait ParagraphsTestBaseTrait {
+  protected function addParagraphedContentType($content_type_name, $paragraphs_field_name = 'field_paragraphs', $widget_type = 'paragraphs') {

@@ -51,7 +51,7 @@ trait ParagraphsTestBaseTrait {
+  protected function addParagraphsField($entity_type_name, $paragraphs_field_name, $entity_type, $widget_type = 'paragraphs') {

If we are adding the defaults, we should change the docblock too.

Added default in the function docs.

Triggered 8.3.x tests too. Looks good to me.

Optional in the function docs

Committed, thanks.