digi-serve / kitchensink_app

Testing all AppBuilder options.
1 stars 1 forks source link

Failing Tests #111

Open Hiro-Nakamura opened 4 months ago

Hiro-Nakamura commented 4 months ago

The failing tests are interesting. The problems seem to extend from the Cypress test runner having issues typing in the correct data to the fields.

For example,

  1. in the widget_form_save.js tests, the first form's [save] button is disabled when the page loads. So even though Cypress can type the data into the form, it wont submit and the test fails when checking the value in the grid.

Screenshot Disabled Form Save

  1. the second one is the process_test_kcs-onCreate-process.js file where the test tries to enter test label into the form and then submit it. Then it looks for that value in the Grid.

However something is interfeering with cypress typing into the form, and all that is entered is bel.

So it looks like once typing starts, there is something that resets the Textbox and we loose any data typed in.

Screenshot : incomplete typing

I did add the following code, to trigger the refresh, add a wait, then reenter the data. It works but seems more of a #Hack to get things moving rather than an actual fix for what is happening.

        cy.get(
            '[data-cy="string label 06a93149-590d-4e4f-9463-5ff43a689fd1 2172ba78-b327-42a1-8918-d97852234aee"]',
         ).type("test label", { delay: 0 });

         cy.wait(1000);

         cy.get(
            '[data-cy="string label 06a93149-590d-4e4f-9463-5ff43a689fd1 2172ba78-b327-42a1-8918-d97852234aee"]',
         ).type("test label", { delay: 0 });
nh758 commented 4 months ago

So it seems both of these are caused by the test running before the app is ready to test. The best practice is to use assertions to ensure the page is fully loaded.

Often we use:

cy.get(".webix_spin").should("not.exist");

This should wait until the webix loading spinner is removed. But that's not always enough

  1. What about asserting that the button is not disabled first?

  2. We've seen this before as well. The ideal solution would be to get a signal that the field is ready to use (and assert that that happened). But we have done something slightly less hacky then using cy.wait() in other places:

    cy.get("@field").type("something").clear();
    cy.get("@field").type("what I actually want");
Hiro-Nakamura commented 4 months ago

Yeah, in that first case, even with a .should("be.enabled") clause, it still fails:

cy.get('[data-cy="button save 7e074587-ddc5-4d34-9f37-a0ab88a4258b"]')
            .should("be.enabled")
            .click({ force: true });

Ultimately, the button never becomes enabled on it's own.

Hiro-Nakamura commented 4 months ago

OK, I think I found the culprits in the ab_platform_web code that was causing the problems.

I had added a dc.waitReady() function to make sure that the DataCollection was ready before the Form continued on with its loading. However, in the case of our first form, it seems that it was actually preventing the form from completing the loading process. Hence the save button remained disabled.

However, now I'm seeing the GitHub process hanging on the Wait for AB step: Screenshot 2024-05-09 at 4 04 16 PM