How to debug test and try Selenium code with interactive shells

25 Sep

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:

  1. 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.
  2. Import Selenium/WebDriver libraries
  3. 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.
  4. Load the starting URL in browser for Selenium (for RC the selenium.open(url) method, for WebDriver the driver.get(url) method)
  5. Now, here’s the fun part. To be described later
  6. 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.)
  7. 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:

Try out a code snippet, it didn’t work, now you need to reset state back to where you can try snippet again but differently (different locator value, different javascript) and it may seem easier to reset state manually than via executing code. In a debugger environment, you’d either have to step backwards (where feasible) or if not feasible, then rerun test script/file again to get to breakpoint again.

This approach is best for doing things such as testing out if a given locator works, if some given javascript code works, if a sequence of mouse clicks, hover, or drag & drop work (whether you can use the recommended approach or use a workaround, for example in RC using click() vs mouseDown() followed by mouseUp() when click() fails to work).

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:

http://www.youtube.com/watch?feature=player_detailpage&v=IlfLfLuceWk

Advertisements

One Response to “How to debug test and try Selenium code with interactive shells”

Trackbacks/Pingbacks

  1. Thoughts on a Selenium interactive exploratory test and debug tool | autumnator - January 24, 2014

    […] How to debug test and try selenium code with interactive shells […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Seek Nuance

Python, technology, Seattle, careers, life, et cetera...

TELLURIUM

New Era of Test Automation

Der Flounder

Seldom updated, occasionally insightful.

The 4T - Trail, Tram, Trolley, Train

Exploring Portland with the 4T

Midnight Musings

Thoughts on making art

Automation Guide

The More You Learn The More You Play...!

The Performance Engineer

Code.Test.Tune.Optimize.

humblesoftwaredev

Thoughts related to software development

Yi Wang's Tech Notes

A blog ported from http://cxwangyi.blogspot.com

Appium Tutorial

Technical…..Practical…..Theoretically Interesting

LinuxMeerkat

I swear! Meerkats can do Linux

PacketsDropped

Requeuing the packets dropped in my memory.

Two cents of software value

Writing. Training. Consulting.

@akumar overflow

wisdom exceeding 140 chars.

Lazy Programmer's Shortcut

Java, J2EE, Spring, OOAD, DDD & LIFE! .......all in one :)

Testing Mobile Apps

www.SoftwareTestingStudio.com

Photofocus

education and inspiration for visual storytellers

%d bloggers like this: