Replace cypress manual UI catalog setup with factories

[jrafanie]

Replace UI creation of service template with factories (catalog)

Note, the resource actions aren't required for the test but creating the
service template in the UI does create them so they been kept to match the UI
behavior.

Follow up to #9697

[jrafanie]

@asirvadAbrahamVarghese can you review this and try it locally?

I see a few problems running it with:

export CYPRESS=true; SPEC=cypress/e2e/ui/Services/Catalogs/copy_catalog.cy.js bundle exec rake spec:cypress

• Fails to find the catalog item sporadically due to the "undefined method split" for nil... that's a known issue due to the API colliding on the session store... that's ok for now, but does happen.

• Creating the service template via factories must be different in some way in terms of the node indexes. In this example, which fails fairly often, even through it navigates "all catalog items", and "unassigned" and expands it, it then looks for the item in the sibling to "unassigned", "my catalog" and can't find it and blows up:

• Sometimes it sporadically fails because the tree is still loading and the main div is also still loading:

and an ajax tree_autoload happens after it already fails... so it didn't wait for it:

Note, we do a tree_select intercept but I don't see one for the tree_autoload.

[asirvadAbrahamVarghese]

Creating the service template via factories must be different in some way in terms of the node indexes. In this example, which fails fairly often, even through it navigates "all catalog items", and "unassigned" and expands it, it then looks for the item in the sibling to "unassigned", "my catalog" and can't find it and blows up:

I really hope that screenshot ⬆️ isn’t right 😢, having ‘Test-Catalog-Item’ visible in UI but our command failing to find it would be quite weird...

it then looks for the item in the sibling to "unassigned", "my catalog" and can't find it and blows up

We expect to traverse all the way to the "My Catalog" node to find a match, because we’re looping through all <li> items(here they are"All Catalog Items", "Unassigned", "Test Catalog Item" & "My Catalog") in the expanded accordion. As of now we aren’t really limiting the lookup to the "Unassigned" node. To do that, we’d need to consider data-nodeid:

Sometimes it sporadically fails because the tree is still loading and the main div is also still loading:

and an ajax tree_autoload happens after it already fails... so it didn't wait for it:

Note, we do a tree_select intercept but I don't see one for the tree_autoload.

Exactly, I also feel waiting on the tree_autoload might fix this. To do that, I think I’ll need to enhance the interceptApi command to wait for multiple APIs, currently, it only waits on tree_select from the same event - I’ll take a look and follow up

[asirvadAbrahamVarghese]

We don't need this navigation to "Unassigned" node here, could you please remove this also?

[jrafanie]

That's actually causing a failure described in #9705 (comment)... while it makes sense to remove that line here, I'm curious if there's a valid use case that could hit that bug.

[asirvadAbrahamVarghese]

I tried a few scenarios and here’s what I found: this one fails because the first selectAccordionItem call clicks "Unassigned" node, which triggers both tree_autoload and tree_select calls. We’re not waiting for both right now, since the interceptApi command only supports a single alias.
While the tree_autoload from the first selectAccordionItem call is still in progress, the next selectAccordionItem call starts. At that point, the expand button (span.fa-angle-right) isn’t available yet (it’s still showing the spinner - span.fa-spinner), so the command assumes the node is already expanded and moves on to find the target node ("Test-Catalog-Item"). The search reaches the end of the tree and throws an error because the node isn’t there yet...

This 🔝 is a pretty rare case where we click the parent node and immediately try to expand it to select a child in the next step,
But calling selectAccordionItem back to back shouldn't cause trouble, trying something like selecting different nodes within the same accordion tree:

    cy.selectAccordionItem([
      'All Catalog Items',
      'My Catalog',
      'Testing',
    ]);
    cy.selectAccordionItem([
      'All Catalog Items',
      'Unassigned',
      'Test Catalog Item',
    ]);

First call to expand "My Catalog" and select "Testing":

Second call to expand "Unassigned" and select "Test Catalog Item"::

We might need to enhance interceptApi to handle multiple aliases from a single event and make sure it plays nicely with Cypress, I’ll start working on it slowly but soon

[asirvadAbrahamVarghese]

For now lets try this: #9706

[jrafanie]

ok, #9706 is merged and I verified it worked. The extra cy.selectAccordionItem call doesn't make sense here, but in case we have a use case where we select two different accordion items back to back, that change should allow it now.

[asirvadAbrahamVarghese]

Let’s give this one a try and see how it goes: #9705

[jrafanie]

It's important to note, this test was already doing the test teardown below:

afterEach(() => {
    cy.appDbState('restore');
});

[jrafanie]

ok, all ready to go on this one... still 💚 in CI

[asirvadAbrahamVarghese]

Thanks, lets get this in