AutomationWait could use a refactor as it's a bit dated in design.
Firstly, we should change how the default wait is initially created. The AutomationWait is instantiated in the constructor of WebDriverWrapper, which is created in WebDriverManager after the web driver has been configured. WebDriverManager has access to the spring context, so we should create a new spring property for the desired automation wait. Then, load that property into AutomationWait as the wait time. If the property doesn't exist in the spring configuration, we can still set it as a default of 5 seconds. This check can happen on the WebDriverWrapper before the manager is created.
Secondly, the above change will require an update to the AutomationWait constructor. Instead of a WebDriverManager, we should require WebDriverManager webDriverManager and Long automationWaitTime.
Thirdly, this means we can nuke a lot of the class variables on AutomationWait like waits, useCustomTimeoutIndefinitely, and customTimeout. There may be moments we'd like to set the timeout after the fact, so we can leave the setCustomTimeout method in the class; but since we will not longer have a reliance on useCustomTimeoutIndefinitely, the setter fundamentally sets the timeout "indefinitely" by default. I think we should also update getDefaultWait() to a new method name of getWebDriverWait() and still allow it to create the new WebDriverWait based on the timeout loaded in from the spring property. Because of that, it means we can nuke getTimeoutInSeconds().
A/C
Scaffold should make it possible to set a custom automation wait time
Scaffold's AutomationWait should be refactored in the criteria as detailed in the summary
Summary
AutomationWaitcould use a refactor as it's a bit dated in design.Firstly, we should change how the default wait is initially created. The
AutomationWaitis instantiated in the constructor ofWebDriverWrapper, which is created inWebDriverManagerafter the web driver has been configured.WebDriverManagerhas access to the spring context, so we should create a new spring property for the desired automation wait. Then, load that property intoAutomationWaitas the wait time. If the property doesn't exist in the spring configuration, we can still set it as a default of 5 seconds. This check can happen on theWebDriverWrapperbefore the manager is created.Secondly, the above change will require an update to the
AutomationWaitconstructor. Instead of aWebDriverManager, we should requireWebDriverManager webDriverManagerandLong automationWaitTime.Thirdly, this means we can nuke a lot of the class variables on
AutomationWaitlikewaits,useCustomTimeoutIndefinitely, andcustomTimeout. There may be moments we'd like to set the timeout after the fact, so we can leave thesetCustomTimeoutmethod in the class; but since we will not longer have a reliance onuseCustomTimeoutIndefinitely, the setter fundamentally sets the timeout "indefinitely" by default. I think we should also updategetDefaultWait()to a new method name ofgetWebDriverWait()and still allow it to create the newWebDriverWaitbased on the timeout loaded in from the spring property. Because of that, it means we can nukegetTimeoutInSeconds().A/C
AutomationWaitshould be refactored in the criteria as detailed in the summary