premganz
commented
9 years ago There need not be any extensive mixing and mashing of scripts, but a popular use case is when a a) script is expected to work in different environment - achieved by the navmodel injection b) Wok with restricted scope- by injecting a different script constraint. c) Connecting two scripts, one script leads up to a point and delegates the driver (in a particular state) to the next script (via the constraint)- (i) This calls for a ready to use factory, (ii) the SessionContext is anyway global, so no need for a seperate Runner and the outParams provide handle to get data out and evaluate success.
d) Strategy Params , Input Param configuration to defaults.
Looking at all the additional injection required of constraint and the params and the need for a factory anyway for reusable broad scope scripts, is Spring justified as a factory provider? We already use Spring, however this needs quite some overhauling and maintenance as it stands. I think this is justified. So we need to
a) Fix the Spring based ScriptRegistry, instances can be obtained using the SeleniumScriptFactory and configured with params and then launched using SeleniumScriptLauncher.launchScriptInline() which will return the updated script which can then be extracted for outParams. SeleniumScriptLauncher is renamed from LAunchseleniumScript.java. b) No need for start_url in Constraint because this can be put inside the inputParams for the scripts, the rest however can continue. ScriptConstraintFactory simplified c) Scripts can use the JunitScript because WebDriver Script seems superfluous, A spring based scriptFactory provides the JunitScripts as configured in an xml and this can be executed using inParams and outParams inline. Hence deprecating WebDriverScript
Right now we have a way as to how to create scripts that is by extending the JunitScript class and overriding the init() to configure the KeyWords differently by injecting our own PageFactory and NavigationModel.
We also need scripts that are more complex in the sense that it involves covering a lot of controls across different pages, so there is back and forth navigation, complex logical evaluation of the controls and storing and retrieving them from collections. Sometimes also connecting to databases or MongoDB caches, writing to logs et al.
However a lot of customization can be achieved by the flexibility given through the NavigationModel by a) changing the environment HomePage. b) Pages to be picked up from a different package.
I think these, we cannot always ask the developers to extend the JunitScript, configure kw and write their code into the execute() method. There should be liberty on mixing and mashing the script