- Getting started
- Explore our API
Windows, Linux, BSD and OS X supported.
v1.19 released May 20, 2016
v.2.2 released June 7, 2016
Source code on GitHub
Maven groupId: com.testingbot | artifactId: TestingBotTunnel | version: 1.19
Maven groupId: com.testingbot | artifactId: TestingBotTunnel | version: 2.2
Whether you want to test on your local computer (localhost), on a staging server inside your LAN, or on a computer across VPN, our TestingBot Tunnel makes all of this possible in a secure and reliable way.
You will no longer need to open up ports on your firewall or whitelist our IP range to run tests on your staging environment. Below are some of the features of the TestingBot Tunnel:
- Fast: at our end of the tunnel we keep a cache of static content, to reduce traffic inside the tunnel.
- Secure: when you start the Tunnel, a pristine VM server is booted just for you and will last until you end the tunnel.
- Robust: full HTTP(s) support, coded in Java
- Easy: to set up and use.
Run tests in your local environment
The Tunnel makes it easy to run Selenium tests in your private staging environment.
You might want to test a new feature or a big refactor of your local code, to make sure all regression tests still pass.
With our Tunnel this is very easy to do. All you need to do is point your tests to http://localhost and port 4445 instead of using our grid 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.
Optimized for Speed
Setting up a Tunnel means we boot a pristine VM server just for you. This takes about a minute to launch.
We added an accelerator on our end of the tunnel called Squid, which will cache static content flowing through the tunnel.
This optimisation will make the tunnel fast because cached static content no longer needs to go through the tunnel.
Next to that, the tunnel has an option to use RabbIT proxy which compresses images, optimizes pages & more before sending the traffic through the tunnel!
The Tunnel uses zlib ssh compression to minimize the traffic going through the tunnel.
You can run multiple tunnels with 1 account. This means you can dedicate xx machines on your LAN to run xx tunnels.
With multiple tunnels, you do not have to worry about load issues when running xx tests in parallel.
Every request to and from our servers will pass through the Tunnel, which is based on the SSH protocol.
A fresh VM is booted up just for you and when your tests are finished the tunnel and VM server will be destroyed.
We've built a strong Tunnel which can handle a lot of traffic, even during parallel testing.
The Tunnel is built in Java with proven code and runs on a standard JVM.
Both HTTP and HTTPS usage is supported inside the tunnel.
Starting the tunnel happens with a simple command on the commandline and offers options like verbose logging and fast-fail regexes.
Works on Mac, Linux, BSD and Windows.
Version 1 vs Version 2
We currently offer 2 different versions: a V1 version and a V2 version.
The V1 version supports Java 7 and uses an older proxy mechanism, which might be a bit slower than V2.
The V2 version requires Java 8 and uses a newer proxy mechanism which is faster.
Setting up and using the Tunnel is easy.
Download the JAR file from our website and run it on your commandline.
All you need to do is replace the API_KEY and API_SECRET with your own key and secret.
You will see "You may start your tests" when your Tunnel is ready.
The Tunnel will create a ~/.testingbot file on your local system where it saves the API_KEY and API_SECRET.
This way, you can save the necessary credentials in the file and then just start the tunnel without passing anymore credentials to the tunnel.
Below you will find some examples on how to use the Tunnel.
To start your Tunnel, download the Java based Tunnel and run from the commandline:
urlhub = "http://key:firstname.lastname@example.org:4444/wd/hub" client = Selenium::WebDriver::Remote::Http::Default.new
urlhub = "http://key:secret@localhost:4445/wd/hub" client = Selenium::WebDriver::Remote::Http::Default.new
Notice how we now use localhost:4445, which will send the test commands through the Tunnel.
To prevent certain websites or pages from being proxied by our tunnel, please use the fast-fail regex:
If you are behind an HTTP proxy, please start the tunnel with these extra arguments:
The system requirements depend on how you are going to use the tunnel.
If you intend to do parallel testing, you will need to increase the CPU and RAM of the machine running the tunnel.
By default, a machine with 4GB ram and 3GHz processor should be enough.
Shutting down tunnel
It is recommended to do a graceful exit of the tunnel every time, otherwise the tunnel will remain active in our system since we never received a shutdown command.
To do a graceful exit please use Ctrl+C in the process window or remove the TestingBot pid file: testingbot-tunnel.pid. This will trigger a graceful exit, send the shutdown command to TestingBot and clean up everything.
We have created a NodeJS based launcher which you can use in your NodeJS tests and projects:
These options are available when launching testingbot-tunnel.jar:
|-b,--boost||Will use rabbIT to compress and optimize traffic|
|-d,--debug||Enables debug messages|
|-f,--readyfile <FILE>||This file will be touched when the tunnel is ready for usage|
|-F,--fast-fail-regexps <OPTIONS>||Specify domains you don't want to proxy, comma separated.|
|-h,--help||Displays help text|
|-l,--logfile <FILE>||Write logging to a file.|
|-P,--se-port <PORT>||The local port your Selenium test should connect to. Default port is 4445|
|-p,--hubport <HUBPORT>||Use this if you want to connect to port 80 on our hub instead of the default port 4444|
|-q,--squid||Bypass our Squid proxy running on the tunnel VM.|
|-s,--ssl||Will use a browsermob-proxy to fix self-signed certificates|
|-v,--version||Displays the current version of the Tunnel|
|-Y,--proxy <PROXYHOST:PROXYPORT>||Specify an upstream proxy.|