refactoror
commented
10 years ago Peter,
I see you have been quite busy with this technology. I'll have to take a look at what you've done. Being able to call one script from another has been on the wish list for a while, but I just have not had the time to pursue it.
I plan to begin hosting the source code somewhere, including the documentation and the regression test suite. I am evaluating github, but I may look at googlecode as well. (The docs ended up on wikia one day when I suddenly noticed that openqa had disappeared.)
Once the source code is hosted, I would welcome help in the form of "pull requests", and will give full and prominent credit to contributors. -- I have previously accepted an enhancement from another developer, but it was very time-consuming because it was not test-driven and required much re-work to be production ready. Therefore future submissions will need to be fully integrated, with error handling, and covered by tests.
Note that SelBlocks intentionally goes beyond the basic ${} notation in supporting full javascript expressions. A consequence of this is non-strict code, but it provides much more power and expressiveness. It is also backward compatible with ${}, because Selenium does the substitutions before the command sees the arguments. If anything I would like to see Selenium add direct support for javascript expressions. (Mozilla has given me some grief about this in the past, but have approved releases because the departures are carefully controlled, are consistent with Selenium itself, and removing features would break the scripts of a large user base.)
thanks for your interest! -chris
jbattenjr
Hello Chris.
Background
Thank you for SelBlocks. You've done a hard job (especially given the complexity and little documentation of Selenium IDE).
By making SelBlocks you've motivated me to extend it. I've enabled function calls between test cases. That fork is SelBlocksGlobal (source code). Then my work expanded and I've created SeLite. It helps tests to have data in SQLite (separate from the tested application). It adds some Selenese commands and EnhancedSyntax, too. I believe this all together empowers Selenium IDE users well beyond the initial idea of Selenium IDE as a recording/playground tool. Indeed, nothing of this would exist without SelBlocks.
Initially SelBlocksGlobal was based on SelBlocks version 1.3, now it's based on version 2.0.1.
The goal and the user base
My aim is to create value for the public (and I believe it’s similar for you). I don’t intend to 'recruit' the existing or potential users away from SelBlocks. However, they can't use both extensions. (SelBlocksGlobal could extend SelBlocks via many function intercepts, but it would be too complicated.)
SelBlocks has many more users than SelBlocksGlobal. However, I'm creating test frameworks and demos to make SelBlocksGlobal more known (e.g. for FUDforum).
Compability and dependencies
The only user-level Selenese incompatibility (as compared to SelBlocks) is that it requires $ prefix for loop variable in for, and for stored variables on the right side of assignment in call command. That's because SelBlocksGlobal uses Javascript strict mode (which doesn't allow with(object) { ... }).
Implementation-wise, SelBlocksGlobal depends on two other SeLite AddOns - ExtensionSequencer and TestCase Debug Context. (It also uses SeLite Miscellaneous, but it could work without it.)
ExtensionSequencer resolves dependencies of Selenium Core/IDE extensions and initiates them in the right order.
TestCase Debug Context defines a class used for TestCase.debugContext. That allows SelBlocksGlobal to head intercept nextCommand() of prototype that class (based on replacement intercept in SelBlocks). That way the injected code is a (bit) less dependent on Selenium IDE code base. Indeed, TestCase Debug Context replicates Selenium IDE code base, but it could be pulled into Selenium (ThirdPartyIssues > Selenium IDE issue #5495).
In the other direction, Bootstrap (another SeLite component) depends on SelBlocksGlobal (and TestCase Debug Context). This dependency could be easily removed (it’s there just for convenience - it’s one intercept rather than two separate intercepts of the same method).
All dependencies are listed at AddOnsDependencies.
Working together
I believe we could both deliver more value if we merged SelBlocks and SelBlocksGlobal. That would attract other developers. It would also give us more lobbying power (e.g. to push ThirdPartyIssues), which could save Selenium IDE from being abandoned by Selenium HQ.
At the packaging level, I'd prefer SelBlocksGlobal to stay as a part of SeLite. That’s practical because of dependencies and loading via ExtensionSequencer.
License-wise, I want to keep TextCaseDebugContext class under Apache Lic. 2 (for a potential pull into Selenium, and so that Bootstrap can use it). Currently SelBlocksGlobal is under MPL 1.1 (like SelBlocks). I'd prefer GNU GPL 3. (Licenses gives the rationale behind licenses of SeLite components.)
Hosting-wise, I suggest GoogleCode. I haven't used GitHub (other than for git), but its markdown (especially the links) seems less readable than Wiki in GoogleCode, which also integrates Wiki and git well. It seems to me that GitHub gives more options of code management (via pulls requests), but that should be workable with GoogleCode, too (it's about human co-operation and not just the system). I can't say anything about wikia.com, but I think it's more practical to have one system (or fewer) than more of them.
Javascript strict mode is not essential, but Mozilla suggests that it's a good practice. I believe it's worth the inconvenience of backward incompatibility of Selenese for and call.
Using ExtensionSequencer is beneficial in that it allows partially related functionality to be split into components, thus simplifying maintenance. Investigating and isolating bugs can be easier, too. That all enables more code share, which would also attract other developers. That would mean more and better functionality for the users.
What do you think?