Opera Developer News

Introducing RoboHydra - Opera's open-source HTTP client test tool

By Bruce Lawsonbrucelawson. Wednesday, June 27, 2012 11:02:52 AM

open source, server, Opera, testing, robohydra

We'd like you to meet RoboHydra - a web server designed to help you test any kind of HTTP-based client. RoboHydra is easy to configure to return the responses you want, mimicking any server behaviour needed to test your clients.

Usecases include:

Testing how the client behaves when it receives a certain combination of valid (but possibly uncommon or cumbersome to reproduce) data
Being able to easily reproduce race conditions
Checking how the client behaves when the server returns Internal Server Error or invalid data
Simulating server connection latency when connecting to a real server

Take a look at the screencasts for more information on how to use RoboHydra while we're preparing some tutorial articles.

The project started at Opera as an internal tool to test some of our projects. Large parts of this code were (and still are) developed there, but as it’s pretty generic we decided to open source it. See Opera’s GitHub account for more open source goodies.

Shiny Demos on GithubdevicePixelRatio in Opera Mobile

Comments

Martin KadlecBS-Harou # Wednesday, June 27, 2012 12:16:52 PM

Wow, this is definitely going to be handy! Long live Node.JS

Çağlar Yeşilyurtgreench # Wednesday, June 27, 2012 12:19:57 PM

Cool tool

Martin KadlecBS-Harou # Wednesday, June 27, 2012 1:01:42 PM

RoboHydra ready on port 3000 - Admin URL: http://localhost:3000/robohydra-admin

now the worse part, trying to actually understand it

Esteban Manchado Velázquezemanchado # Wednesday, June 27, 2012 7:30:30 PM

BS-Harou: watch the screencasts and read the tutorials, that should be (hopefully) a good introduction :-)

I'm guessing if you have a use for it, you'll realise after going through the tutorials and reading the examples (see https://github.com/operasoftware/robohydra/tree/master/examples). Good luck!

Martin KadlecBS-Harou # Wednesday, June 27, 2012 9:14:39 PM

Originally posted by emanchado:

I'm guessing if you have a use for it, you'll realise after going through the tutorials and reading the examples (see https://github.com/operasoftware/robohydra/tree/master/examples). Good luck!

Thx. The tutorials seems fine, already feeling much more clever

and it has lots of similarities with ExpressJS

One thing that seems a bit odd to me is the req.getParams property. The "get" at start makes me always think it is method and not property. It would even make sense as you would not have to parse the query string until (and only if) the method is called.

Martin KadlecBS-Harou # Wednesday, June 27, 2012 9:36:34 PM

Also it seems to me that often we need only one config file with no configuration so instead of:

{"plugins": [{"name": "search", "config": {}}]}

It would be nice to just write:

{"name": "search"}

Or in case of some config.:

{"name": "search", "config": { ... } }

It might even be good idea to consider running the robohydra like:

robohydra (-l | --plugin) path/search

and get rid of the config file completely - when it's possible

Esteban Manchado Velázquezemanchado # Thursday, June 28, 2012 7:24:24 AM

Ah, I never thought getParams could be confusing in that way. The idea is that it holds the parameters for a GET request, but maybe I should have called it urlParams. One of the problems I had with urlParams, though, was that it could be mistaken with what is currently simply called params (it's the values you get out of the colon-variables in URLs like this: "/articles/:articleid"). So I'm not sure what to do.

As for the configuration, you're right, it could be simpler. I want to keep the "plugins" key because I'd like to leave the possibility open for other things, and it's true that most times you don't really need the "config" key. So I'll probably allow a compact form like:

{"plugins": ["search"]}

How about that? You could even mix the two types, like so:

{"plugins": ["search", {"name": "another-plugin", "config": {"this-needs": "additional config"}}]}

I'm not sure yet about getting rid of the whole configuration file, but it might be a good idea, too. I'll think about it, thanks!

Martin KadlecBS-Harou # Thursday, June 28, 2012 11:04:34 AM

Originally posted by emanchado:

So I'm not sure what to do.

How about queryParams?It is two chars longer, but should be pretty obvious.

Esteban Manchado Velázquezemanchado # Thursday, June 28, 2012 1:20:34 PM

Hm, that sounds good I think. Let me think about it, maybe I'll change it or make both available. Thanks for the feedback!

Martin KadlecBS-Harou # Thursday, June 28, 2012 2:00:41 PM

I have also noticed you use http.createClient method for proxy heads. According to Node v0.8 doc it is deprecated. It might be good idea to change it. Once its removed people might have some troubles with newer Node.JS versions.

(If I'm nagging too much, just say it and I'll stop

)

Esteban Manchado Velázquezemanchado # Thursday, June 28, 2012 2:43:02 PM

Are you looking at 0.1.0? I had noticed that at some point and fixed before 0.2.0, see https://github.com/operasoftware/robohydra/commit/9ba77cd028c0503b39e2025b9f7ce175cbaf5cee. And thanks a lot for the feedback!

Martin KadlecBS-Harou # Thursday, June 28, 2012 3:48:08 PM

Originally posted by emanchado: