Global functions and User Extensions rollup. #20
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The new build script will generate user-extensions.js. The new directory "user extension" is for the output user-extension.js and can be used for scripts that may need to be included on the server only. selblocks.js has been altered so that the selblocks object has a new property "onServer" that is false by default. After checking for the existence of "testCase" in the global context, onServer will be set to true if "testCase" does not exist. Using that flag, additional code will be executed if the server environment is detected.
Detecting whether this is running on the server or not is silly. I just include a setting when creating the user-extension. If the setting is set, then extra code for the server gets executed. If the setting is undefined, then the server code is not executed. The extension passes the test suite and the server extension doesn't crash on the server. Now I'll figure out SelBench and we'll be able to run the full test suite on the server.
SelBench user extension still needs work, but once it's right this should be a snap to test. This will grab the user-extensions.js file in C:\projects\selenium\selbench\SelBench\user extension Assuming you have this script at C:\projects\selenium\selblocks\SelBlocks\testUserExtension then it will concatenate the selbench script with the user extension for selblocks and the tests will be run.
both selbench and selblocks applied the same patches and ended up creating a loop that never ended. Now they flag when they've applied patches and check the flags before applying them.
The pound sign works in the IDE but screws up the server when it tries to fetch the test.
…mentation Conflicts: sel-blocks-fx_xpi/chrome/content/extensions/selblocks.js
This doesn't pass testing yet. The tests run but almost all of them fail.
this code has to run once, and only once, every time the reset method is intercepted. It has to run after the original reset method has executed, but before any tests are actually run. I'll have to move it out into its own file and intercept the call to reset before any other extensions do.
This moves the server augmentation code out of the FF extension. This appears to be working, I'm missing some mappings between obejcts and methods on the server and IDE though. This passes testing in the IDE but fails gloriously on the server. The "while" test makes the screen twitch because the incrementor never increments. I'm sure it's something simple once I look...
The file runTestsOnServer will autorun the html test suite. If the tests timeout or the server fails to launch then the debug environment will open.
somewhere along the way I broke the default action of opening up the tests in the default browser for debugging. I fixed that. I fixed everything. This is a pretty sweet launcher.
I had forgotten to write this in the help text.
I think I've got it down to only changing three of the variables at the top of the script, to port this over to selbench.
There's a lot of code in this extension that relies on strict mode being off.
interceptFrame.attrs doesn't always exist. There won't be an error manager in that case and, the test blows up. I'm just catching that error and returning false from isManaged, since the error isn't managed.
This was breaking everything, so I took it out. It was only used on the server and only broke things on the server...
I've updated the user-extension for selbench as well. They go together.
the automatic script won't be automatic unless you set your browser to use the selenium server as its proxy.
When giving the server an html suite to run automatically, it will root there. This overrides setting the server root by placement of the user-extensions.js file. To make file paths consistent between automatic and debug tests, I moved the location of the debug copy of the user script into the sel-blocksTests folder.
The iterator value "w" is evaluated and stored inside the "with" block.
The iterator emits the right values but after the block is completed,
emitting "end ${w}" gets the value of w in the scope above the "with"
block, which hasn't been changed.
The variable is automatically shadowed in local scope, so storing the
iterator value globally doesn't work because the updated value isn't
visible locally. I don't know how that works exactly, it's something
with the way arguments are being parsed.
the value for i will be the same at the start and end because it's incremented in block scope to the for loops.
this test is really convoluted. It looks like "finally" is supposed to execute even after a return statement. That finally throws, so nothing is being returned.
I was setting and verifying at the same time, which is wrong.
The tests explain it better than I can. Basically, without this you only have the choice of shadowing variables in the child scope, or setting globals all the time to pass data around. storeAt allows you to name a variable defined in any preceeding scope and bubble the value to set on it. The changed value will be available after you exit the current scope, so you can do things like "while" and "for" loops without bouncing return values off the global scope. . . Just storeAt whatever receiving variable you have set up in the parent and it's like magic!
The new tests might take a little while because the websites might not respond immediately.
Everything is working as expected in the IDE, and on the server in Firefox and Chrome. Internet Explorer passes all the tests except for calling functions across cases. I don't know if it's because the functions I'm testing are calling slow web pages or if it's some kind of syntax error in IE when we use the command name "call". IE is cool and all, but I'm submitting this because it works everywhere else and one of us will be able to figure out the bug in IE in the near future.
when doCall tries to validate the "argSpec" argument, the validation method was throwing an error in IE if the value was a blank string. We want to be able to call functions without any arguments, so I told it to skip validation when the argSpec is like a blank string. Like a blank string, not exactly a blank string, but like a blank string. parseArgs handles this just fine.
there's some kind of bug with selenium in IE, it tries to use the window before it's ready and that is causing our tests to fail if they open pages. I've changed the tests so we're not getting false failures anymore, except for in the readme test, since all it does is open a window.
|
I fixed the bug in IE and added some documentation. Take a look at the readme and let me know if you like it. |
The "KEY_" variables were being wiped out. Now they're not.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Passes testing in all but IE
Everything is working as expected in the IDE, and on the server in
Firefox and Chrome. Internet Explorer passes all the tests except for
calling functions across cases. I don't know if it's because the
functions I'm testing are calling slow web pages or if it's some kind of
syntax error in IE when we use the command name "call". IE is cool and
all, but I'm submitting this because it works everywhere else and one of
us will be able to figure out the bug in IE in the near future.
You'll need the version of SelBench from my kastor-dev branch on that project to test this. I've got copies of all the latest test results in here for you to see exactly what passed and failed.