Details

    • Type: Task
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: 2.6
    • Component/s: Development
    • Security Level: Public (Public: Anyone can view)
    • Labels:
    • Sprint:
      Rice Sprint 2015-04-15
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required
    • Code Review Status:
      Not Required
    • Include in Release Notes?:
      Yes
    • Story Points:
      3

      Description

      Currently our rice-sampleapp and krad-sampleapp AFTs each take about 12 hours to complete. Can we shorten that time?

        Attachments

          Activity

          Hide
          cniesen Claus Niesen added a comment -

          The following change caused the run time to decrease by about 2h but caused 12 failures.
          https://github.com/kuali/rice/compare/master...cniesen:KULRICE-14239-master
          Investigation on whether the failure could be fixed with case specific waits or other AFT fixes.

          Show
          cniesen Claus Niesen added a comment - The following change caused the run time to decrease by about 2h but caused 12 failures. https://github.com/kuali/rice/compare/master...cniesen:KULRICE-14239-master Investigation on whether the failure could be fixed with case specific waits or other AFT fixes.
          Hide
          cniesen Claus Niesen added a comment -

          Side note: When refactoring the code it wouldn't hurt to remove the "wait" and "jiraAware" from the general AFT methods. When a test needs to click on an item, the test doesn't care about the implementation specifics (i.e. if we wait when the element isn't there right away or that our tests are jira aware). Naming should be plain so implementation specific things can be changed as desired.

          Show
          cniesen Claus Niesen added a comment - Side note: When refactoring the code it wouldn't hurt to remove the "wait" and "jiraAware" from the general AFT methods. When a test needs to click on an item, the test doesn't care about the implementation specifics (i.e. if we wait when the element isn't there right away or that our tests are jira aware). Naming should be plain so implementation specific things can be changed as desired.
          Hide
          cniesen Claus Niesen added a comment -

          WebDriverUtils.waitFor method still uses the implicitWait in addition to the Thread.sleep causing a full 2 seconds delay between polling. Two seconds seems to be an excessive delay between polling.

          FluentWait might provide a nicer solution to checking the existence of web elements.
          References:
          http://www.toolsqa.com/selenium-webdriver/implicit-explicit-n-fluent-wait/
          https://selenium.googlecode.com/git/docs/api/java/org/openqa/selenium/support/ui/FluentWait.html#timeoutException-java.lang.String-java.lang.Throwable-

          Show
          cniesen Claus Niesen added a comment - WebDriverUtils.waitFor method still uses the implicitWait in addition to the Thread.sleep causing a full 2 seconds delay between polling. Two seconds seems to be an excessive delay between polling. FluentWait might provide a nicer solution to checking the existence of web elements. References: http://www.toolsqa.com/selenium-webdriver/implicit-explicit-n-fluent-wait/ https://selenium.googlecode.com/git/docs/api/java/org/openqa/selenium/support/ui/FluentWait.html#timeoutException-java.lang.String-java.lang.Throwable-

            People

            • Assignee:
              Unassigned
              Reporter:
              cniesen Claus Niesen
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated: