Developers › ODIN blog

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

June 27, 2012 · by Bruce Lawson

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 code is Copyright 2012 Esteban Manchado Velázquez, and is released on Github under the Apache 2.0 license. Jacob Rask did all the CSS for the admin interface.

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.

Readers' comments 12

Left under the original article, as archived.

  • Martin KadlecWednesday, June 27, 2012 12:16:52 PM

    Wow, this is definitely going to be handy! Long live Node.JS :party:
  • Çağlar YeşilyurtWednesday, June 27, 2012 12:19:57 PM

    Cool tool :smile:
  • Martin KadlecWednesday, 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 :bigsmile:
  • Esteban Manchado VelázquezWednesday, 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 KadlecWednesday, 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 :wink: and it has lots of similarities with ExpressJS :smile:

    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 KadlecWednesday, 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ázquezThursday, 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 KadlecThursday, 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ázquezThursday, 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 KadlecThursday, 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 :angel: )
  • Esteban Manchado VelázquezThursday, 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 KadlecThursday, June 28, 2012 3:48:08 PM

    Originally posted by emanchado:

    Are you looking at 0.1.0?



    Yes, sorry, my bad .. I used npm tomorrow and it installed me v0.1.0 and I was checking my local files.

About this article

Published inODIN blog
DateJune 27, 2012
AuthorBruce Lawson
Tagsopen source, server, Opera, testing, robohydra
OriginalInternet Archive