[#SRC-250] Allow Multiple User Extensions Files to be Specified, and Not be Called "user-extensions.js"

Selenium Remote Control

Allow Multiple User Extensions Files to be Specified, and Not be Called "user-extensions.js"

Created: 11/May/07 12:13 PM Updated: 13/May/09 09:59 AM

Component/s:

Server

Affects Version/s:

0.9.2

Fix Version/s:

None

Description

« Hide

Currently it appears that when the -userExtensions switch is provided to the Selenium Server, only one extensions file can be provided, and that file muste be named "user-extensions.js". I'm requesting an enhancement to allow for multiple user extensions files, and the removal of the requirement to name each file "user-extensions.js". Multiple files could be specified either by delimiting the file paths, (-userExtensions /path/to/ext1.js;/path/to/ext2.js), or by using multiple -userExtensions switches (-userExtensions /path/to/ext1.js -userExtensions /path/to/ext2.js).

Here's a use case:

Selenium IDE allows for multiple extensions files to be loaded, and imposes no naming convention on the extensions files. A user might create a test using the IDE loading several extensions, and export to an RC-language. Currently in order to run such tests using the RC, all extensions files must be concatenated into a single "user-extensions.js" file. With the enhancement, the extensions files could remain as is, and be specified as needed on the Server command line.

All

Comments

Change History

Sort Order:

[ Permlink | « Hide ]

Mel Ludowise - 17/Apr/08 06:57 PM

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.

[ Permlink | « Hide ]

Haw-Bin Chai - 14/May/08 07:52 PM

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.

[ Permlink | « Hide ]

Andras Hatvani - 24/Aug/08 06:24 PM

Reducing priority as the feature isn't a major one.

[ Permlink | « Hide ]

Andras Hatvani - 24/Aug/08 06:25 PM

Due to the link you provided this issue could be closed as fixed - do you see it so, too?

[ Permlink | « Hide ]

Haw-Bin Chai - 24/Aug/08 10:30 PM

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 ...)

[ Permlink | « Hide ]

Mary Ann - 12/May/09 07:11 PM

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.

[ Permlink | « Hide ]

Patrick Lightbody - 13/May/09 09:59 AM

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.