In my earlier posts, I mention about using interactive shells (including Java via Beanshell) for debugging/testing/trying out Selenium code. But it was more at a general/high level. Today, I’ll present a more detailed clarification of the step by step process of doing so (at least in terms of how I do it), for the Selenium beginners:
- Start up your interpreter shell (Python, Ruby, PHP, Java Beanshell or use Groovy/Scala/JRuby/Jython, etc.). How to do so is out of the scope of this tutorial. Research yourself if you don’t know how.
- Import Selenium/WebDriver libraries
- Instantiate your Selenium/WebDriver object for given browser against give host (localhost, some grid node, or just a remote machine for RemoteWebDriver in non-grid mode). Use the sample code you can find online at Selenium project website or other sites for how to start up Selenium/WebDriver session in code.
- Load the starting URL in browser for Selenium (for RC the selenium.open(url) method, for WebDriver the driver.get(url) method)
- Now, here’s the fun part. To be described later
- After having fun, teardown the test. Hack way = just close all the Selenium browser windows and close the interpreter shell window (or forcefully exit shell). Proper way, run Selenium code to close all browser windows and quit (e.g. selenium.close() & optionally selenium.stop() or driver.close() or driver.quit() methods), then call command to quit the shell (usually exit, or Ctrl+C/D/Z, etc.)
- Repeat all the steps as needed in the future if you need to do this again. If you do this frequently, just keep your interpreter shell and Selenium session open instead of start up and teardown all the time.
Now for the fun part of step 5, after you have started up Selenium browser with a starting URL, you can then do any of the following:
- execute Selenium RC/WebDriver code snippets that you desire, one line at a time, and see it happen in real time. Print variables to standard output to see their content. You may have to use your languages variable dump function/method to print out variable values for variables that are not basic types (integers or strings), such as arrays and more complex objects, etc. Executing the code snippets assumes you are also in the right page with the right “state” (logged in, preconditions met, etc.), if not you have to make it so by first executing additional code to set up the preconditions OR do the next option first.
- perform manual test execution steps in your browser to set up the preconditions for executing your desired code snippets. E.g. log in, create user account or needed test data, etc. You may find it is far faster sometimes to manually execute some test steps than to type out the code commands to do same thing or keep running the whole test script/file in Eclipse/IDE/etc. setting breakpoint and waiting for the damn script to get to the breakpoint. This is especially true if the particular commands before the breakpoint or snippet of interest takes a freakin long time to execute that you could do same thing manually.
Now, afterwards you can also interleave or mix running manual test execution with running code commands in the shell, which is very useful for the following:
It also works well when you have some code snippet to test but don’t have a test script/file written up for executing the snippet with and don’t want to modify your existing test yet where you want to put the code snippet to, for whatever reason.
It’s a quicker hack method to try out code than to go full blown with IDE and debugger plus it starts up faster taking less memory and CPU than a debugger session.
Once you have what you like, you can copy & paste the code in your interpreter shell session to a file and clean it up for inclusion/integration into a formal test script.
NOTE that this shell approach can’t be used for one area of testing, debugging timing related issues (at least with commands executing too fast, no issues with commands executing too slow) because executing shell commands one line at a time by typing it it or pasting code is far slower than running lines of code in a script. So you can’t reproduce fast execution and race condition quirks this way.
And to summarize, here’s a good (though not perfect) video demo of using (Java Groovy) shell to interactively try out Selenium code snippets: