[WIP] - Added automated tests with cypress for Zone form

[asirvadAbrahamVarghese]

CP4AIOPS-17892
Pr that adds cypress tests for Zone form: Settings > Application Settings > Settings > Zones > Configuration > Add/Edit Zone
 - Validate add form elements
 - Validate edit form elements
 - Add, edit & delete a zone
 
@miq-bot assign @elsamaryv
@miq-bot add-label cypress
@miq-bot add-label test
 

[asirvadAbrahamVarghese]

TODO:

• Use commands for form elements selection: Add custom commands for selecting form elements #9537 ✅
• Switch to direct API calls for cleanup, if the implementation under Added automated tests with cypress for Namespace form #9517 is approved - Holding off on this, as a more effective cleanup method is in progress Cypress on rails #9633

[jrafanie]

Similar to the question above about the input fields type() possibly doing async stuff afterwards... I'm seeing one run of this test retry 4 times. So, don't waste time trying to debug it until this test actually fails all 10 attempts but wanted to share in case there was something obvious async you saw when you ran this manually.

[asirvadAbrahamVarghese]

I think the session timing problem is the culprit here again, and doesn’t look like there’s anything async that’s needs to be awaited or handled

[jrafanie]

haha, I didn't get any takers on reviewing #9533 so it's stalled. Reducing our session writes on requests that shouldn't be updating session doesn't fix the problem but it does reduce the likelihood of a timing bug with much less session writes across threads.

[jrafanie]

Close / open after revert of #9505 via #9553

[jrafanie]

After we do a few pages of these, we'll probably have shared behavior we can extract. It's probably best to get a few of these in first.

[asirvadAbrahamVarghese]

I am not really sure about the best approach to extract these, one way would be to have separate methods in a shared helper file for each field, something like:

function validateNameField(isDisabled = false) {
  cy.getFormLabelByInputId('name').should('be.visible');
  cy.getFormInputFieldById('name')
    .should('be.visible')
    .then((nameField) => {
      if (isDisabled) {
        expect(nameField).to.be.disabled;
      } else {
        expect(nameField).to.not.be.disabled;
      }
    });
}

But we might end up with a pile of methods 😴

More flexible one would be to get the set of field configs and then do the assertions:

function validateFormFields(fieldConfigs) {
  fieldConfigs.forEach((config) => {
    const { id, fieldType = 'input', shouldBeDisabled = false } = config;

    // Check label
    cy.getFormLabelByInputId(id).should('be.visible');

    // Check field
    if (fieldType === 'input') {
      cy.getFormInputFieldById(id)
        .should('be.visible')
        .then((field) => {
          if (shouldBeDisabled) {
            expect(field).to.be.disabled;
          } else {
            expect(field).to.not.be.disabled;
          }
        });
    } else if (fieldType === 'select') {
      cy.getFormSelectFieldById(id)
        .should('be.visible')
        .then((field) => {
          if (shouldBeDisabled) {
            expect(field).to.be.disabled;
          } else {
            expect(field).to.not.be.disabled;
          }
        });
    }
  });
}

and use it like:

validateFormFields([
  { id: 'name', shouldBeDisabled: true },
  { id: 'description' },
  { fieldType: 'select', id: 'concurrent_vm_scans' },
]);

Any thoughts?

[jrafanie]

Sorry, I didn't see this reply. yeah, I think something like that is what we should do. How many pages have we done this for now? Maybe after we have several done and can figure out a clean way to do this...

One for validating form labels and one for form input fields seem the most logical to me. Keep this in mind as you do these and propose an interface and maybe we can try converting one of these tests to use it... and we can judge before vs. after.

[asirvadAbrahamVarghese]

PR with form element validation commands: #9635

[jrafanie]

LGTM so far. Just a few comments above.