Uploaded image for project: 'Moodle'
  1. Moodle
  2. MDL-39528

Prevent all the test to fail if a modal window is found during functional tests execution

    Details

    • Testing Instructions:
      Hide
      1. Pull a modified test to make a JS modal window appear
        • git pull git://github.com/dmonllao/moodle.git MDL-39528_master-testme
        • Run behat with --tags @MDL-39528 option
        • You SHOULD see a failure with Modal window present. Ensure there are no edited forms pending to submit/cancel
      Show
      Pull a modified test to make a JS modal window appear git pull git://github.com/dmonllao/moodle.git MDL-39528 _master-testme Run behat with --tags @ MDL-39528 option You SHOULD see a failure with Modal window present. Ensure there are no edited forms pending to submit/cancel
    • Affected Branches:
      MOODLE_25_STABLE
    • Fixed Branches:
      MOODLE_25_STABLE
    • Pull from Repository:
    • Pull Master Branch:
      MDL-39528_master

      Description

      This is a scenario that is unfortunately common, it appears a modal window and the other scenarios execution can not continue because JS modal windows are blocking everything until they are accepted or cancelled. I suppose the solution could be at the hook level, looking for modal windows and killing them before beginning with other stuff, but I haven't tried anything so I have no idea if it will work, but it makes sense.

        Gliffy Diagrams

          Issue Links

            Activity

            Hide
            dmonllao David Monllaó added a comment -

            Adding Eloy and Damyon as watchers; with the last changes to catch exceptions/debugging()/backtraces we are also preventing the "global" exception that stops other's scenarios to be executed, but the problem is more or less the same: If there appears one of the JS popups when following a link after editing a non-submitted & non-cancelled form, when the next scenario starts (going to the homepage) then the JS confirm appears again, blocking the UI (JS alert/confirm are evil) until someone (or something) accepts.

            With this patch:

            • Re-throw the exception providing a moodle-friendly message more specific than the WebDriver one and failing the scenario
            • Before each scenario, it checks that there are no opened alerts after going to the homepage

            I've been looking for alternatives because I don't really like to close a non existing alert before each scenario, but what I've found is that JS popup windows are not specially friendly (to say it in a proper way)

            Show
            dmonllao David Monllaó added a comment - Adding Eloy and Damyon as watchers; with the last changes to catch exceptions/debugging()/backtraces we are also preventing the "global" exception that stops other's scenarios to be executed, but the problem is more or less the same: If there appears one of the JS popups when following a link after editing a non-submitted & non-cancelled form, when the next scenario starts (going to the homepage) then the JS confirm appears again, blocking the UI (JS alert/confirm are evil) until someone (or something) accepts. With this patch: Re-throw the exception providing a moodle-friendly message more specific than the WebDriver one and failing the scenario Before each scenario, it checks that there are no opened alerts after going to the homepage I've been looking for alternatives because I don't really like to close a non existing alert before each scenario, but what I've found is that JS popup windows are not specially friendly (to say it in a proper way)
            Hide
            poltawski Dan Poltawski added a comment -

            Hi David,

            Your fix looks good to me.

            If I were to nitpick i'd say, try and make your commit message so it doesn't wrap on the first line and expand with some detail in the following lines

            Show
            poltawski Dan Poltawski added a comment - Hi David, Your fix looks good to me. If I were to nitpick i'd say, try and make your commit message so it doesn't wrap on the first line and expand with some detail in the following lines
            Hide
            dmonllao David Monllaó added a comment -

            Thanks for the review Dan, I've reworded the commit msg (with the MDL-XXXX and the component name sometimes will be hard to use just 50 chars)

            Show
            dmonllao David Monllaó added a comment - Thanks for the review Dan, I've reworded the commit msg (with the MDL-XXXX and the component name sometimes will be hard to use just 50 chars)
            Hide
            damyon Damyon Wiese added a comment -

            Thanks David,

            I also ran the standard behat tests on some modules to check for regressions and they worked fine.

            Integrated to 25 and master.

            Show
            damyon Damyon Wiese added a comment - Thanks David, I also ran the standard behat tests on some modules to check for regressions and they worked fine. Integrated to 25 and master.
            Hide
            fred Frédéric Massart added a comment -

            Passing after cleaning up the commits to pick from the test branch. Cheers!

            Show
            fred Frédéric Massart added a comment - Passing after cleaning up the commits to pick from the test branch. Cheers!
            Hide
            damyon Damyon Wiese added a comment -

            Thanks for your contribution! This issue has been reviewed, integrated, tested and now released to everyone.

            Closing as Fixed!

            Show
            damyon Damyon Wiese added a comment - Thanks for your contribution! This issue has been reviewed, integrated, tested and now released to everyone. Closing as Fixed!

              People

              • Votes:
                1 Vote for this issue
                Watchers:
                6 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:
                  Fix Release Date:
                  8/Jul/13