|
Sort Order:
See here a possible solution: http://ttwhy.org/home/blog/2008/05/14/selenium-rc-per-session-extension-javascript/ Instead of specifying files, you're free to specify the entire extension string to be loaded on a per-session basis. Reducing priority as the feature isn't a major one. Due to the link you provided this issue could be closed as fixed - do you see it so, too? That would be fine by me, I don't know about for other people who are potentially interested in this issue. The per-session javascript is pretty flexible. However, I know that I haven't updated the PHP client driver to support this yet (nor am I really looking forward to doing that ...) I disagree that this feature isn't a major one. And I don't see anything in the "possible solution" about it working for HTML tests generated by Selenium-IDE. It is really obnoxious to go from Selenium-IDE's comma-separated list of meaningfully-named extension files to having to create a concatenated mess named user-extensions.js just to get the same test(s) working with Selenium-RC so one can gain the advantage of being able to test on non-FF browsers. I have to agree with Andras that this isn't a major issue. My reason is slightly different though: as we evolve Selenium, we're going to be de-focussing the Selenium Core stuff more and more. That includes the whole concept of JS-based user extension files that need to be injected in to the page. That's not to say we won't have a concept of extensions and sharable modules, but I believe that we need to rethink that distribution model in Selenium 2.0. I understand it's irritating for some users (short term solution: open up both JS files and paste them in to a single file). But we need to stay focussed on the longer term objectives, which at a mile-high view include: 1) get Selenium 1.0 out, 2) crank out Selenium 2.0 and finally fix all the warts we've lived with for years. We use Selenium in our company quite extensively and we have many products in our suite. Just bundling up all javascript extension and concatenating them is quite cumbersome. However, would what i'll describe below work consistently and is this recommended and future compatable? <html> Is this the same as specifying some-modules.js and some-stuff.js after the -userExtensions switch? |
||||||||||||||||||||||||||||||||
Improvement
Open
Minor
Allow Multiple User Extensions Files to be Specified, and Not be Called "user-extensions.js"
This is killing us right now. We have 4 different schemas of our application we need to test, each of which has a common library of custom user-extension functions and some schema specific variables used by Selenium.
Right now, we have 4 different versions of the user-extensions.js file which all share about 90% of the same code. Every time a change is made to one function, we have to update all 4 files, and it's beginning to become a maintenance nightmare. Ideally, we could store all of the common code in one user-extensions.js file, and then specify a schema1.js, schema2.js, etc. Then we could specify the paths to user-extensions.js and the schema*.js for the instance we're testing in the commandline.