Posts Tagged ‘testing’

Break Things Faster with Ruby Parallelization

February 25th, 2013 by Dylan

You’re probably wasting two things when you’re testing. Your time… because the other thing is your extra CPUs. Any time you’re waiting on a relatively slow resource, your CPU is just sitting there, twiddling its silicon thumbs. If you’re only using one CPU core at a time, the other cores are doing much the same. Unfortunately for web developers who do things involving CRUD operations, slow resources includes databases. Most unfortunately for you, Dear Reader (and us, Dear… Us), they also include the browsers you’re integrating with for Selenium testing.

Source: http://www.flickr.com/photos/calliope/440681335/

This is what waiting for browsers and io should be measured with

One of the best ways to get more test for your tokens is to run more tests at once. If you’ve got several tests going, even if some are waiting for one slow resource, the others can use the CPU. The more tests you can run at once, the shorter your test cycles will be, especially if you could, say, spin up more then one copy of the slow resource to test with (Psst: I’m talking about Sauce Labs Parallelization).

I’ve been looking for ways to make parallelization easier when testing with Ruby, and I stumbled across the Parallel Tests gem. It’s actively developed, has some nice documentation and integrates with rspec, rspec-rails and test:unit. Their benchmarks show that using the gem, the Rails ActionPack test suite time was cut in half, from 88 seconds to 44, with just 4 test runners. This, conveniently, is the number of parallel tests you can run with a Mild plan.

Source: http://www.flickr.com/photos/59937401@N07/5857826966/

Checkmate. Wait. Snap. Game Set Match?

So for many of you, there’s already a possibility of making your tests take half the time. Which means you can run twice as many. Which means a much faster turnaround time for TDD, BDD, and release testing.

I’d say that’s a win.

Share

Announcing “Open Sauce,” free unlimited testing for Open Source projects

December 13th, 2012 by Ashley Wilson

For about a year, we’ve been quietly giving free testing support to some high profile open source projects, like Mozilla and the Selenium Project. As open source advocates and contributors ourselves, we know it’s important to support projects that we benefit from on a regular basis. And what better way to do it then by providing the infrastructure that helps ensure new releases are fully tested?

Given that history, we are very excited to announce today that we’re taking this effort one huge leap forward and providing free “Open Sauce” accounts to any OSS project that could benefit from our automated and manual cross-browser testing services.

If you have an open source project, simply sign up here and enter in your project’s repository URL and a description of what it is. You’ll automatically be enrolled in the plan, which provides unlimited testing minutes on up to three parallel VMs and access to all our features, including 96+ OS/browser combos, screenshots, debugging tools and more.

In exchange, we just ask that you agree you will only use this account for your OSS project(s) and that all of your test results (videos, screenshots, and the Selenium log) will be publicly accessible (we actually think this is an awesome thing, as it makes it super simple to share the tests with other developers).

For more info, visit our Open Sauce page or sign up for an account. And if you’d like for us to list your project on Open Sauce, let us know.

Happy (open source) testing!

Share

The Eschaton: What The End Game Looks Like For Testing with Selenium

November 13th, 2012 by The Sauce Labs Team

This is the first in a series of posts by QAOnDemand, which offers self-service QA scripting and testing. For more info, visit http://qaondemand.com.

In theological circles, “The Eschaton” is defined as the end of time. In fact, there’s a whole field of study called Eschatology that studies what the end of the world looks like. While I have to believe their office parties are pretty grim, they’re definitely on to something. Visualizing the end result of what you’re building before ever laying down any foundation can lead to better decision-making, which is a key thing to keep in mind when setting up a mature testing environment for the first time.

To help you with this effort, I’ve devised a zombie readiness kit that includes how to set up the five key components for building a mature testing environment with Selenium:

  • A place to store your tests (source code repository)
  • A place to run your tests (Sauce Labs or a Selenium server)
  • A mechanism to trigger your tests (continuous integration server like Jenkins)
  • A place to log and track defects (a bug tracker like Bugzilla)
  • An army of human testers to test what cannot or has not yet been automated

While you can certainly test software without all five in place, it’s radically more productive with everything integrated and running smoothly. I’ll be diving into each component in more detail, so let’s get started with the guide!

A place to store your tests.

The Z: drive of your network is not a place to store tests. Neither is Dropbox. Your tests belong under source control. All of them. And by all, yes, I mean both manual test scripts and your test automation code.

There are many reasons why bringing your test assets under source control is a good idea, but here‘s the top 26:

A) Continuous integration servers are designed to pull from repositories. This means that if you put your test code in a well-organized repository, it’s relatively easy to configure your CI server to pull the latest copies from the repo and execute your tests automatically. Plus when a test fails, it’s also easy to take a quick look at your revisions to see if a recent change to the test code could be responsible for the failed test.

B) Products like the Atlassian suite are designed to broadcast repository activity. This is a good thing. Too often, QA gets a siege-like quality where we only come up from the dungeon when there’s a problem or free food. The truth is that by continuously broadcasting QA test results into the main communication streams of your company, you normalize the process of QA for everyone outside the group. QA test results become less of an interrupt and more routine. That’s a good thing and a worthy goal.

C-Z) Revision control. If your test code isn’t under revision control, then you’ve been living in the woods too long. You’s ignorant so listen up! If it’s worth doing, it’s worth keeping track of. The ability to trace changes over time is one of the most underrated tools out there. If something breaks and you’ve got to pop open the code, the first thing to look at is what has changed. Did the code change? Did the test change? With Git, CVS, SVN, Merc, whatever, you can easily see the evolution of your test code. It solves so many problems and enables so many good things such as skills development, accountability, and humility.

A place to run your tests.

You’re reading this on Sauce Labs‘ blog so this hardly needs mentioning, but there’s a nuance here worth talking about. One of the best qualities of Sauce Labs is the visibility it creates. The value in being able to rerun a test or capture a screenshot cannot be overstated. Whether you’ve provided a manual step-by-step set of instructions or you’ve provided a link to a screen cast, the first step in remediating a bug is to reproduce it and observe it in action. So if that “place to run your test” is “Joey’s Laptop,” then you’re going have a bad time. But if it’s a generally available service that anyone can access, it’s going to be a whole lot more fun.

A mechanism to trigger your tests

We see a lot of test teams “kicking off” tests manually. This is fine; there are lots of cases where you need to do this, but it’s waaaay better when a continuous integration (CI) server does this for you. Getting your CI to manage your test execution is tricky. Now I’d love to tell you there’s a simple script ./make-it-so.py, but alas, there is not. There are different types of builds, different deployment scenarios, and different types of check-ins that should fire off different types of tests.

But the net-net is that in the end, you want your QA process to be seamlessly integrated into the development process. And increasingly, CI drives development. Consider this question: In five years, is continuous integration and automated deployment going to be more or less prevalent? Is it going to be more common or less common? The answer is yes, so why bring up the rear of the parade? Get out in front. The sooner your QA process is wired into your CI, the easier it’ll be in the end.

A place to log and track defects

I’m going to move quickly through this point because most of you probably have this at some level. The one feature I’ve seen in the last few years that’s really been a huge boon to development is tying tickets to checkins, such that you can see the code that is related to the ticket. This makes it infinitely easier to quickly find the business requirements associated with a ticket and cross-reference it to the code itself. If you can tie your test code to tickets in a similar fashion, it’s so much the better because you’ve created visibility for both the created tests and related revisions. I highly recommend you select bug-tracking software that does this. It’s absolutely worth every expense.

An army of human testers to test what can’t (or has yet to be) automated

In its heart of hearts, quality assurance is a request for an opinion that is inescapably a human observation. “Does it work as you expect?” can sometimes be described in a way that can be automated. Sometimes it can be described in a way that a tester with nominal knowledge of the system can test. Sometimes it takes a domain expert to tell if something works as expected.

The point is, human testing always has been and always will be a part of QA. Anyone who says it can be completely automated is either an academic or a fool. So plan for it and work towards an end game that uses human testers in a productive and efficient way. We think it’s helpful to break up the problem of organizing human-based QA work into three buckets using the following guidance.

  • a) Automate the simple stuff that’s easy to maintain or is tedious. Automate the routine stuff that won’t break often, but when it does, it’s catastrophic. There’s no shortage of people who will tell you that with a good framework and their secret sauce, you can automate everything. You can’t. And more importantly, it’s not worth it. Automation is fundamentally an economic problem, not an engineering problem. You should only automate that which the cost of automation is meaningfully less than the cost of just running the check repeatedly by hand when needed. The bottom-line? Don’t get dragged into complex automation strategies. Automate the simple routine stuff in a simple and routine way.
  • b1) Outsource the intermediate stuff, such as layout, copy writing, new features, and regressing fixes on a well-defined but complex bug. Outsourcing works great where cultural nuance, domain expertise and a qualified point of view don’t matter all that much. The overhead is much lower than it used to be and in the sage words of Eric S. Raymond: “Given enough eyeballs, all bugs are shallow” .
  • b2) Outsource the creation of simple automation — you know, like writing your Sauce Labs tests. Just sayin’. When a well-defined bug gets checked, have an outsourced team write an automated test to check it again. Test harnesses with a thousand tests get built one test at a time. ***
  • c) Use your domain experts as big guns. Focus them on the hard stuff – subtle features that require an understanding of how the code works or how a customer sees the world. If your in-house QA engineers are testing to see if your upload feature correctly kicks out an error for oversized files or disallowed formats, then you are wasting valuable expertise. Again, it’s helpful to think about testing as an economic problem and price your top talent. Give your top dogs a fully loaded cost and socialize the notion that it’s not a few hours, it’s a few dollars. Remind people of what they’re asking for in economic terms – that a detailed, cross-browser, multi-platform manual test by your in-house team is easily a $1,000 request. A simple question to posit: “Is that the best way to spend $1,000?”

So, what now?

In conclusion, take time to work through your endgame. Almost all QA work is time-bound, meaning we all work as hard and as fast as we can testing until the clock runs out. If nothing explodes during testing, we ship. It’s not fair, but that’s the way it is. So if you don’t block off some time each cycle to build toward a better way of doing things, then you’re selling yourself and your team short. Hopefully this post gave you a little perspective on what that end-game could look like.

In the next post, we’ll get into specifics of some of the tools we’ve found to be most helpful and more specifics about what works for us.

*** Look, QAOnDemand basically does B1 and B2 for a living. We see a lot of people’s QA efforts. Our services are structured and priced to make it easy for you to say yes to modest outsourcing. We’ll knock out your intermediate testing without crushing you with a big contract or a lot of overhead. Plus we offer a decent free trial with no strings attached, so give it a go. We’ll also bootstrap your Sauce Labs environment for you if you haven’t done so already. It’s much easier to add to a working system once it’s set up correctly. Net-net, a little help in the beginning goes a long way. Ok, ’nuff said.

Share

Python Virtualenv

July 26th, 2012 by jeremy avnet .:. brainsik

Python logo iconA Python virtualenv is a Python interpreter and set of installed Python packages. Python packages are installed separate from the main system so you don’t need to use sudo/su or worry about installing things system-wide. Since the interpreter (the python run) and packages in a virtualenv are separate from other virtualenvs, you can switch between different versions of Python and different versions of installed packages with a single command.

Using virtualenv lets you do things like:

  • Replicate your production Python environment in a dev setup so you can be sure you’re writing code and tests using the same package versions your deployed code will use.
  • Create environments with the same set of Python packages but using different versions of the Python interpreter (e.g., Python 2.5, Python 2.7, and PyPy).
  • Setup experimental environments for trying out new Python package versions or new Python software projects.

The easiest way to get going with virtualenv on Mac and Linux is to use the virtualenv-burrito installer. This one-line command installs virtualenv and virtualenvwrapper (a nice way to use virtualenvs):

curl -s https://raw.github.com/brainsik/virtualenv-burrito/master/virtualenv-burrito.sh | $SHELL

Once installed, you can make new virtualenvs with mkvirtualenv <name>, install packages with pip install <package>, and switch between virtualenvs using workon <name>.

Let’s make a virtualenv and run the example Sauce Labs test:

mkvirtualenv saucelabs
pip install selenium

Login to (or create a free account on) saucelabs.com. Go to the Python getting started page, copy your private curl command, and run it like:

curl -s https://saucelabs.com/example/se2/python/private-?????? | bash

To install the same Python package versions in another virtualenv we can use pip freeze to get what’s in our current environment, save it to a file, and use that file as an install list:

workon saucelabs
pip freeze > requirements.txt
mkvirtualenv likesaucelabs
pip install -r requirements.txt

By developing, testing, and running production Python code in virtualenvs created using the same requirements files, you greatly reduce the risk of writing bugs which only show up in one environment but not another. We highly recommend using this tool to help ship code faster.

Share

Sauce OnDemand Now Supports Selenium 2.1.0

August 1st, 2011 by Santiago Suarez Ordoñez

In keeping up-to-date with the releases pushed by the Selenium project, Selenium version 2.1.0 is now fully available in our service.

This new release includes a mayor fix to an important bug affecting some native clicks on elements. You can check out the official changelog for more information.

Due to our new release process, there will be a testing period before we make this the default version in our service. (Once we’ve decided to do so, we’ll announce it in advance). In the meantime, we advise you to try out your tests in this new version using the following Desired Capabilities/JSON key-value:

"selenium-version": "2.1.0"

We’d love to hear if you see any issues after moving your tests to Selenium 2.1.0. And stay tuned, as we’ll be announcing 2.2.0 as well as other versions through our blog too!

Share

#SeConf Videos Now Available!

May 2nd, 2011 by Ashley Wilson

In case you missed the awesome Selenium Conference that happened in early April, check out videos from each of the presentations. We’ll be posting a couple at a time, so stay tuned to future posts!


Jason Huggins’ Opening Keynote


Dave Hunt & Andrew Smith: Automating Canvas Applications
Despite recent improvements to automated testing tools, there’s still a large gap when it comes to emerging technologies such as HTML5. Recent developments like the canvas element present an interesting dilemma for traditional automated testing as they expose little or no information to debug tools. In order to move forwards, both developers and testers will need to work together. Using Selenium, Java, and JavaScript we will demonstrate writing automated tests for a popular canvas game.


Dima Kovalenko: Selenium and Cucumber
Wouldn’t it be nice to have the BA’s write out the acceptance criteria in plain English, and then have those criteria run as tests? Join us for a beginner to intermediate walk through of Cucumber and Selenium. Learn how to write tests that are easy to understand and run. There will be plenty of examples and sample code to get you going in the right direction.

Share

How to serve PHP/Pear packages with GitHub

April 27th, 2011 by joe

PHP packages are distributed through Pear channels. If you want to download a PHP package, it’s as simple as downloading Pear and using it. The process of using pear is telling it the “channel” you want to download the package from, and then telling it to download the package. That’s what you do if you want to download somebody else’s PHP. If you want other people to be able to download yours, you have to make your own pear channel.

We had to do that recently, and it turns out there’s an easy way to do it thanks to GitHub and Fabien Potencier‘s Pirum. It’s pretty straightforward. Here come the lists. So many lists! Like 40. Still. Straightforward.

By the way, you’ll need to install pear and install git if you haven’t already.


 

Make a pear channel

  1. Create a new repository on GitHub called pear
    1. Make the project on github
    2. $ mkdir pear
    3. $ cd pear
    4. $ git init
    5. $ git remote add origin git@github.com:[your git username]/pear.git
  2. Install Pirum
    1. $ pear channel-discover pear.pirum-project.org
    2. $ pear install pirum/Pirum-beta
  3. Create a pirum configuration file:
    1. It’s called pirum.xml
    2. It goes in the root of your pear repository
    3. It contains:
      1. <?xml version="1.0" encoding="UTF-8" ?>
        <server>
        <name>[username].github.com/pear</name>
        <summary>[username]'s PEAR Channel Server</summary>
        <alias>[username]</alias>
        <url>http://[username].github.com/pear</url>
        </server>
  4. Run the build command
    1. $ pirum build .
  5. Now add and commit everything
    1. $ git add -A
    2. $ git commit -m "Initial server build. Sauce Labs is awesome"
  6. Rename your master branch to gh-pages and push it to GitHub
    1. $ git branch -m master gh-pages
    2. $ git push origin gh-pages
  7. Your PEAR channel server is now available (after maybe 15 minutes) under [username].github.com/pear. Test it out!
    1. $ pear channel-discover [username].github.com/pear
    2. $ pear channel-info [username]
    3. $ pear list-all -c [username]

 


There! Now you have a pear channel. Now you need to

Make a PHP package

  1. Go to the directory that contains your PHP files
  2. Create a package.xml file that contains metadata about your package
  3. Check that it’s a valid package
    1. $ pear package-validate
  4. Make the package!
    1. $ pear package (this should create a .tgz file that’s named after the package you detailed in package.xml)

 


Woo! Now you have a package and a channel. Next step is to

 

Add the package to the channel

  1. Copy the .tgz file to your pear repository
  2. Navigate to that directory
  3. Add the package to the channel locally
    1. $ pirum add . [filename].tgz
  4. Upload the changes to github! Note that you push to gh-pages and not to master.
    1. $ git add -A
    2. $ git commit -m "Added first version of my pear package. Sauce Labs is awesome"
    3. $ git push origin gh-pages

 


And you’re done! No more bullets! Or numbered lists. Now the whole world is exposed to your PHP. Hopefully that’s a good thing.

 

Here’s our Pear channel: https://github.com/saucelabs/pear

Here’s the source we distribute through it: https://github.com/saucelabs/phpunit-selenium-sauceondemand

Special thanks to Jan Sorgalla for showing me by example how to do all this.

Share

Sauce Labs Eliminates Barrier to Automated Cross-Browser Testing with Sauce Builder

March 31st, 2011 by The Sauce Labs Team

New tool enables QA pros to build and run Selenium tests without Selenium expertise or infrastructure

SAN FRANCISCO, CA — (Mar. 31, 2011) – Sauce Labs, the web application testing company, today introduced Sauce Builder, a free testing tool that makes it easy for users to build Selenium tests without Selenium expertise and run them with the Sauce OnDemand service. Sauce Builder allows users to build automated Selenium tests simply by clicking through an application. By eliminating the complexity of hand-coding Selenium scripts, Sauce Builder accelerates the adoption of automated testing for QA and development teams that have been craving the development productivity Selenium offers. Sauce Builder is free and available for immediate download.

“Automated testing has historically been one of the most complicated, yet most valuable, technologies for companies that build software. Automated testing is doubly challenging because teams need to build and maintain a testing environment and on top of that, building tests can require significant technical skill,” said John Dunham, CEO of Sauce Labs. “We launched our Sauce OnDemand cloud service last year to eliminate the headache of maintaining a test infrastructure. Now with Builder, we’ve removed the next barrier to the adoption of automated testing and we’re very excited to see how this combination can help QA and development teams achieve their goals.”

With Sauce Builder, Sauce Labs continues to simplify and improve the cross-browser testing process for development and QA teams. Sauce Builder’s benefits include:

  • Build Selenium tests with zero programming – Simply click through your application and Sauce Builder writes a Selenium scripts that reflect your actions
  • Export results in the language of your choice – HTML, Java, Groovy, C#, Perl, PHP, Python and Ruby so your tests speak the same language as your application and dev team
  • Eliminate bugs faster – Use immediate video playback of your tests in action, and share them with your teammates
  • Remove test infrastructure headaches - Sauce Builder makes it a snap to either run tests locally in Firefox or in the cloud with access to all the browser / operating system combinations supported in the super scalable Sauce OnDemand service

With over four million downloads in just four years, the Selenium project is the world’s most popular functional testing framework for web applications. Designed to further expand Selenium adoption, Sauce Builder is the first web-based Selenium tool of its kind, including technology Sauce Labs acquired from Go Test It in 2010. After becoming more familiar with the technology post-acquisition, Sauce Labs elected to open source the code under the name “Se Builder” earlier this year because the technology held so much promise for the Selenium community.

Sauce Builder expands the capabilities of Se Builder by enabling users to directly access Sauce OnDemand, the cloud-based Selenium service, to run their tests. Sauce OnDemand is free to try for up to 200 testing minutes every month. Sauce Labs is also leading a collaborative effort with the Selenium community to deliver a new generalized plug-in architecture for Se Builder that among other things will support integrated plug-ins for testing services like Sauce OnDemand.

To learn more about how automated testing can accelerate your development velocity, please join Adam Christian,a Sauce Labs developer and project lead for Sauce Builder, on Tuesday, April 19th at 10AM Pacific for the webinar, “From zero to creating, storing and running automated tests in under 30 minutes”.

“Debugging takes up valuable time that developers could be using to focus on their applications,” said Sauce Labs’ Christian. “Now with Sauce Builder, developers can leverage this great development environment through our cloud testing infrastructure and not worry about dealing with building or maintaining their own costly testing infrastructure.”
About Sauce Labs
Sauce Labs, web application testing company, provides Sauce OnDemand, a cloud based service that allows users to run automated cross-browser functional tests faster and eliminating the need to maintain their own test infrastructure. To date, over four million Sauce OnDemand tests have been run in the Sauce cloud. The lead investor of Sauce Labs is the Contrarian Group, Peter Ueberroth’s investment management firm. Sauce Labs is headquartered in San Francisco, California. For more information, visit http://saucelabs.com.

Media Contact
Chantal Yang
LEWIS Pulse for Sauce Labs
sauce@lewispulse.com
415-875-7494

 

Share

Testing Your Mobile Apps with Selenium 2 and Frank

March 30th, 2011 by Ashley Wilson

In case you missed our last SF Selenium Meetup, check out video below of the two great presentations on mobile testing. Pete Hodgsen, a software consultant with Thoughtworks, discussed how to use Frank, a new testing framework he’s involved in developing, for automated acceptance testing of native iOS apps. Jason Huggins, creator of Selenium and co-founder of Sauce Labs, followed this by demoing how to test Android and iPhone applications using Selenium 2.

Many thanks to our friends at CoTweet for co-hosting and making this last meetup such a success! If you think your company might be interested in hosting a future meetup, please get in touch. Our next meetup will be in early May at Mozilla (we’re skipping April because of the Selenium Conference happening next week). Stay tuned for more details!

Share

The Selenium ‘click’ Command

March 22nd, 2011 by The Sauce Labs Team

Introduction

The golden rule of web application testing states that “You can find a number of bugs by simply clicking randomly on various places.” This is especially true for User Interface bugs. If you are using Selenium or Selenium-RC for automating your application’s User Interface tests, it is important to know how the “Selenium.click()” command works in order to simulate user clicks.

While it’s one of the lesser-advertised features of Selenium, it’s a blessing in disguise for testing application behavior for various UI elements without needing any manual intervention. For instance, we recently tested a JSP form with a few dozen dropdown lists (single and multi-select), checkboxes, and a plethora of radio buttons. Clicking each UI control manually was a pain in the hand. In contrast, simulating these clicks using Selenium not only saved crucial manual testing effort, it helped uncover a number of important bugs in the application as well.

How to use the Click command?

To put it in simple words, the click command emulates a click operation for a link, button, checkbox or radio button. It takes a locator (an identifier for which HTML element the command refers to) as an argument.

Example – The following command invocation simulates a click on a button element named myButton

selenium.click("myButton");

Browser Support

The Selenium click command works in the following browsers

Browser Versions
Firefox 3, 3.5, 4
Internet Explorer 6, 7, 8, 9
Safari 3, 4, 5
Opera 9, 10, 11
Google Chrome current

Language Support

The Selenium click command works in the following languages

Language/ Tool Command Name
C#
selenium.Click
Java
selenium.click
PHP
$this->selenium->click
Python
self.selenium.click
Perl
$sel_click_ok
Ruby
@selenium.click
Selenium IDE
selenium.click

Challenges and Workarounds

The Selenium click command offers basic locator click functionality. Though it has several limitations, these can be overcome using the following workarounds.

  • How to click on specific coordinates?

Click command is only capable of clicking on a specific element locator. It can’t click on an element using the coordinates of the mouse event relative to the element locator. Example

selenium.clickAt("myButton", "50,50");

Moreover, it can be used to have the same effect as click command by specifying the coordinates as “0,0”. This is especially true when using JavaScript frameworks such as extJS and GWT where click command doesn’t work very well because it does not trigger the mouseUp event.

  • Does issuing the click command fire the onblur event?

No, it doesn’t. That’s the reason why you should use the fireEvent command in such cases. Example

selenium.FireEvent("Cancel", "click")

Sample HTML

Let’s consider the following example as a reference point to understand how the Selenium click command works.

<!DOCTYPE HTML>
<html>
    <head>
        <script type="text/javascript">
            function show_msg(){
                alert("Selenium Rocks!");
            }
        </script>
    </head>

    <body>
        <input type="button" id="myButton" onclick="show_msg()" value="Show Message" />
    </body>
</html>

Example Test Cases

Let’s consider the following test cases to understand how the Selenium click command works in various languages. In each of the code snippets provided below, we first open the application root, set the value “selenium rc” into the field named ‘q’, invoke the click command on myButton and then wait for 30 seconds for the page to load.

  1. Python
self.selenium.open("/")
self.selenium.click("myButton")
self.selenium.wait_for_page_to_load("30000")
  1. PHP
$this->selenium->open("/");
$this->selenium->click("myButton");
$this->selenium->waitForPageToLoad(30000);
  1. Ruby
@selenium.open "/"
@selenium.click "myButton"
@selenium.wait_for_page_to_load “30000”
  1. Java
selenium.open("/");
selenium.click("myButton");
selenium.waitForPageToLoad("30000");

  1. Selenium IDE HTML Suite Test
open /
click myButton
waitForPageToLoad 30000

Using Selectors with Click Command

The Click command can also be used in conjunction with the following selectors.

1. css=

The CSS selector is often used with Selenium click command to uniquely identify an object or element on a web page. For example

selenium.click("css=input[name=myButton]”)

The CSS locator is especially handy as an alternative to XPath locator which works painfully slow with IE.

2. name=

As the name itself suggests, the name selector is used to click the first element with the specified @name attribute. For example

selenium.click("name=myButton”)

3. id=

This allows click on an element with the specified @id attribute. For example

selenium.click("id=myButton”)

4. link=

This allows clicking on a link element which contains text matching the specified pattern. For example

selenium.click("link=myLink”)

5. xpath=

This allows clicking on an element using an XPath expression. For example

selenium.click("xpath=//input[@name=myButton' and @type='submit']")

We hope that you find this write-up informational and it helps shorten your Selenium learning curve.

Happy Testing!

Share