TestingBot offers easy online Selenium testing.
Use our Selenium grid to run tests across multiple browsers.
We can run your Selenium tests on a daily basis and alert you when a test fails.
Interested? Take a look at our features.
Today we have added support for using a BrowserMob proxy together with our Selenium grid.
By using this proxy, you can manipulate HTTP traffic during your tests, and do some other cool things too:
We provide a private and secure proxy for every customer, free of charge.
The traffic flowing through this proxy will only be available to you.
Below is an example on how to start and use a proxy.
To start a proxy, please make a GET request to our API
curl -u API_KEY:API_SECRET http://api.testingbot.com/v1/tunnel
We will boot up a pristine virtual machine for you, which should take no longer than 45 seconds.
Once the machine is booted, make the same request again to obtain the IP address of your personal VM.
Now that you have the IP, you can start using the proxy and do some interesting things.
In this example, we’ll capture performance data in a HAR file for a single Selenium test in Ruby.
Start off by creating a listener on a free port:
curl -X POST http://IP:9090/proxy
This call will return a free port (for example 9091), which you need to use in your test.
Also, create a HAR attached to the port you obtained:
curl -x PUT http://IP:9090/proxy/9091/har
Now run the test with your proxy:
#!/usr/bin/env ruby
require "rubygems"
require 'testingbot'
gem "selenium-webdriver"
require "selenium-webdriver"
caps = {
:browserName => "firefox",
:version => "10",
:platform => "WINDOWS",
:proxy => Selenium::WebDriver::Proxy.new(:http => "IP:9091") #use the 9091 port we retrieved earlier
}
urlhub = "http://API_KEY:API_SECRET@hub.testingbot.com:4444/wd/hub"
client = Selenium::WebDriver::Remote::Http::Default.new
client.timeout = 120
@webdriver = Selenium::WebDriver.for :remote, :url => urlhub, :desired_capabilities => caps, :http_client => client
@webdriver.navigate.to "http://testingbot.com/"
puts @webdriver.title
@webdriver.quit
When the test has finished running, you can fetch the HAR file from your personal proxy:
curl http://IP:9090/proxy/9091/har
We have added a page in our support area with this browsermob proxy example.
Should you have any questions about this, please let us know in the comments or contact us.
Today we have added full support for Webdriver-backed Selenium, which allows you to use the two API’s together in a single test.
By using this feature, it will be easier for you to migrate your existing Selenium RC tests to the new WebDriver format.
Here’s a list of reasons on why you should consider start using WebDriver:
Even though not all RC commands are supported, you can now run most of your RC tests on a WebDriver instance inside our grid.
An example of using the two API’s together in Ruby would be:
#!/usr/bin/env ruby
require "rubygems"
require 'testingbot'
gem "selenium-client"
gem "selenium-webdriver"
require "selenium-webdriver"
require "selenium/client"
selenium = Selenium::Client::Driver.new :host => "hub.testingbot.com",
:port => 4444,
:url => "https://www.facebook.com",
:browser => "*webdriver"
caps = {
:browserName => "iexplore",
:platform => "WINDOWS"
}
urlhub = "http://API_KEY:API_SECRET@hub.testingbot.com:4444/wd/hub"
client = Selenium::WebDriver::Remote::Http::Default.new
client.timeout = 120
@webdriver = Selenium::WebDriver.for :remote, :url => urlhub, :desired_capabilities => caps, :http_client => client
selenium.start :driver => @webdriver
puts @webdriver.title == selenium.title # WebDriver and RC together
selenium.open "/" # RC
@webdriver.quit # WebDriver
This test will show up in our member area with screenshots/video and a list of steps from both RC and WebDriver.
Today we released a new feature in our TestingBot member area called Test TV.
With Test TV, you are now able to see your Selenium tests running in our Cloud.
A live video (secure VNC connection) will show your test running on any browser/mobile device straight from your test page.
When the test is completed, the live video will be stopped and will be replaced by a video recording of the test.
Test TV utilises HTML5 to show the live feed of your test which means it operates straight from inside your browser, no additional software is required.
To see it in action, log in to our member area and run a Selenium test. While the test is running, go to the test page. A video stream will appear where you will see your test running.
Today we are proud to release our new Selenium Tunnel, which will enable you to run Selenium tests on your local computer and network infrastructure.
Whether you want to test on your local computer (localhost), on a staging server inside your LAN, or on a computer across VPN, our new Tunnel makes all of this possible in a secure and reliable way.
Our previous solution, a simple SSH remote port forwarding program, allowed for testing on a single local computer and was at times slow.
With the new Tunnel, we provide a more robust and faster solution. Here are a few of its features:
- Run tests on your local computer, on computers inside your LAN or across VPN.
- Fast: we cache static content on our end of the tunnel to reduce traffic inside the tunnel
- Secure: when you start the Tunnel, a pristine VM server is booted just for you.
- Robust: full HTTP(s) support, coded in Java
- Easy: very simple setup
When running Selenium tests you might want to test against your local staging environment.
Maybe you’ve updated some code or added a new feature and you want to make sure all regression tests still pass.
With the new Tunnel, you can easily test on http://localhost or http://10.0.1.5 without changing anything to your test code.
The only thing you need to do is point your tests to http://127.0.0.1 port 4445 instead of http://hub.testingbot.com port 4444.
The Tunnel is a Java based program (jar) which contains our very own secure HTTP(s) proxy, which will relay requests to our grid.
This way a browser on one of our instances can easily fetch webpages through the tunnel.
When booting the Tunnel, we boot up a fresh VM server just for you which is required to set up the tunnel.
Booting this VM takes 45 seconds max.
After your tests are finished the tunnel and VM server will be destroyed.
At our end of the tunnel, we added an accelerator called Squid, which is used by a lot of trusted companies.
Squid will keep a cache of the static content flowing through the tunnel and store it for the lifetime of the Tunnel.
When a test requests the same static content file multiple times it will never have to go through the tunnel as Squid will have it in its cache.
This optimisation will make sure your Tunnel stays fast.
All the requests to and from our servers will pass through the Tunnel, which is based on SSH.
The traffic flowing through your personal VM is only available to you.
When your tests are finished, the tunnel is destroyed together with everything on the VM server.
The Tunnel is built in Java with proven code and tests.
We support both HTTP and HTTPS usage inside the tunnel.
Starting the tunnel happens with a simple command on the command line and offers options like verbose logging and fast-fail regexes.
Setting up the Tunnel is very easy. Download the JAR file from our website and run it on your command line:
java -jar testingbot-tunnel.jar API_KEY API_SECRET
All you need to do is replace the API_KEY and API_SECRET with your own key and secret.
You should see “You may start your tests” when your Tunnel is ready.
To use your Tunnel, you need to modify the host and port inside your test file(s).
Instead of using our grid on http://hub.testingbot.com and port 4444, you now need to run your tests on http://localhost and port 4445.
This will make sure your commands flow through the secure Tunnel, reaching our Selenium grid.
If you have any questions or suggestions, please leave a comment or reach out to us via email.
Since our last post announcing Mac OS X Selenium support, we now have added iPhone and iPad to the mix.
You can now run your Selenium webdriver tests on iPad and iPhone (iOS 5.1) inside our grid.
Testing on iPad and iPhone happens with the official iOS Simulator from Apple and comes with a video and screenshots of the test.
At TestingBot we understand that mobile testing is becoming increasingly important, so that’s why we are dedicated to provide you with the best solutions for mobile Selenium testing.
A simple example of how to run your first test on TestingBot:
require "rubygems"
require 'testingbot'
gem "selenium-client"
gem "selenium-webdriver"
require "selenium-webdriver"
require "selenium/client"
caps = {
:browserName => "iphone", # or ipad
:platform => "MAC"
}
urlhub = "http://key:secret@hub.testingbot.com:4444/wd/hub"
client = Selenium::WebDriver::Remote::Http::Default.new
client.timeout = 120
webdriver = Selenium::WebDriver.for :remote,:url => urlhub , :desired_capabilities => caps, :http_client => client
webdriver.navigate.to "https://www.google.com/"
puts webdriver.title
webdriver.quit
You can find more info about our iOS and Android support in our mobile support area.
We look forward to your comments and suggestions.
We will make a lot of people happy with this announcement: today we start providing our customers with Mac OS X testing on-demand.
Next to testing on Windows (2008/2003), Linux and Android we now finally provide testing on Apple’s OS.
We provide a video and screenshots of your test running on OS X, just like we do with all the other platforms we support.
An example in Ruby of running a test on the mac would be:
require "rubygems"
require 'testingbot'
gem "selenium-client"
gem "selenium-webdriver"
require "selenium-webdriver"
require "selenium/client"
caps = {
:browserName => "firefox",
:platform => "MAC"
}
urlhub = "http://key:secret@hub.testingbot.com:4444/wd/hub"
client = Selenium::WebDriver::Remote::Http::Default.new
client.timeout = 120
webdriver = Selenium::WebDriver.for :remote,:url => urlhub , :desired_capabilities => caps, :http_client => client
webdriver.navigate.to "http://www.testingbot.com/"
puts webdriver.title
webdriver.quit
The browsers we currently support on MAC are:
List of all browsers/OS versions we support: browsers
OS X testing is available in beta to our customers (excluding free trials). Enjoy!
We are pleased to announce that we have added Samsung Galaxy Tab testing to our Selenium grid.
Starting today our paying customers can run their tests on Samsung Galaxy Tab emulators running on a Linux node. These nodes are optimized to run the emulator with enough RAM and CPU.
As always, you will have access to all test results together with screenshots and a video of the test.
In the following example you will see a simple Ruby script using Webdriver to test on a Galaxy Tab in our cloud:
require "rubygems"
gem "selenium-client"
gem "selenium-webdriver"
require "selenium-webdriver"
require "selenium/client"
caps = {
:browserName => "galaxytab",
:platform => "ANDROID"
}
client = Selenium::WebDriver::Remote::Http::Default.new
client.timeout = 480
driver = Selenium::WebDriver.for(
:remote,
:url => "http://key:secret@hub.testingbot.com:4444/wd/hub",
:http_client => client,
:desired_capabilities => caps)
driver.navigate.to "http://www.google.com"
element = driver.find_element(:name, 'q')
element.send_keys "Hello WebDriver!"
element.submit
puts driver.title
driver.quit
By modifying the browserName in the example above to “android”, you can also run your test on our Android Ice Cream Sandwich Phone emulator.
More information is available in our support area.
In the meantime we are working on supporting more mobile devices in our cloud, so stay tuned for further updates. To see a full list of browsers/devices/OS versions we support, please consult our browser page.
We are pleased to announce we now support Linux (Ubuntu 11.10) on our Selenium grid.
You can now run your cross browser tests on Linux instances, containing the following browsers:
As with our Windows nodes, we provide screenshots and a video of each test on Ubuntu.
We optimized the screenshots and video processing on our Linux nodes, so rest assured this will not slow down your tests.
Linux Selenium Testing will be available starting from today to all our users (paying and trial accounts).
In our TestLab you can now choose between Linux and Windows browsers.
To see a full list of the browsers and OS combinations we support, please see our browsers page.
Next to running automated browser tests, Selenium and TestingBot can be used for other tasks like monitoring a website, or verifying that the pageload time of a page is below a certain threshold.
With our TestLab we run your Selenium tests when you want, how many times you want.
Let’s say for example that you want to test your website every 5 minutes, and you want to check for a certain piece of text to be on the page (just to make sure you’re not seeing an error page but the real page).
Setting this up is easy with our TestLab:
Sign up for a free account, click “Test Lab” and choose “start a test from scratch”.
Enter a name and URL of the website you want to monitor/test.
Next, let’s add a step which will verify that a certain piece of text is on the mainpage of our website.
Click “Add step” to add a new step to this test.
Choose “Assertion”, and pick the “verifyTextPresent” command.
As a pattern, fill in the piece of text you want to verify on the page.
In our case, we want to make sure that our homepage contains the word TestingBot at all times.
Now let’s specify when and how many times this check should be run.
In this example, we specify that we want this monitoring check to be executed every 10 minutes.
We can now add alerts to make sure we’re alerted immediately when something does go wrong.
TestingBot supports alerts via e-mail, SMS and prowl (push messages).
This test will now run every 5 minutes and will alert you as soon as the piece of text you expect to be on your website is no longer there.
A bit more advanced but very useful is a test which will check the pageload time of your website.
We can calculate the user perceived pageload time of a webpage by storing the current time at the head of your page and then at the end of the page you subtract the current time with the time you stored at the top of your page.
In short, in your head you would add a piece of javascript code:
window._startTime = (new Date()).getTime();
and at the end of the page, you declare a global function:
window.getLoadTime = function() { return ((new Date()).getTime() - window._startTime); }
window.getLoadTime will now return the pageload time in milliseconds.
You can add a verifyEval test step in our TestLab which will verify if the pageload time is below a certain threshold, in this example 9000 milliseconds.
If this is not the case, an alert will be sent so you know something is wrong.
With these examples we hope to convince you that Selenium and TestingBot is a very useful tool for every website owner.
Whether you want to test your website in various browsers or prefer simple website monitoring, it’s all possible with TestingBot and Selenium.
One of the advantages of running your Selenium tests on the TestingBot grid is that we scale depending on your needs.
If you need to run 100 Selenium tests, it might take some time for them to finish if you run them one after another.
By running tests in parallel, you can dramatically reduce the time it takes to run all your Selenium tests.
The same 100 tests can be run x times faster by running them in parallel.
Recently one of our customers asked for a solution to perform parallel testing in PHPUnit.
To our surprise this has been on the PHPUnit todo list for a long time, but is still not supported.
We have created a PHP wrapper script which will collect all the PHPUnit files in the directory you specify and run them in parallel.
You can specify how many tests you want to run at the same time. At the end of the run, the script will echo the results per PHPUnit file.
An example of how to use this script:
php parallel.php -d tests/ -m 5
This will run all tests in the tests directory with maximum 5 simultaneous tests running.
Together with our scaleable grid, parallel testing will make your tests results available much faster.
Our GitHub repository with the parallel PHPUnit code: https://github.com/testingbot/phpunit-parallel
