I was very fortunate to attend a workshop on Robot Framework given by Pekka Klarck in London a few weeks ago. I’ve written about Robot basics already on this blog so I won’t repeat myself, but here are some new ideas I picked up at the workshop:
The workshop left me with the feeling that the sweet-spot for Robot is automation in heterogeneous environments, because of its support for different languages and the host of ready-made libraries for user interface, network, operating systems and API testing (eg ssh, swing, swt, web, selenium, database, mobile, file management, process control). These libraries in particular allow people without much programming experience to efficiently script automated tests that talk to different elements of a system and organise them so that they are relatively easy to manage.
Another area where Robot seems to be better than the competition is managing huge sets of tests/executable specifications. Pekka said that Texas Instruments have a set of 2 million tests executing through Robot. To help teams manage large sets of tests, Robot has taken the idea of test tags much further than any other tool I’ve seen. For example, Robot automatically collects execution statistics and sorts them by tags, presenting a very useful global summary. I haven’t seen this use of tags before but I love it and I hope that other tools will steal this idea soon.
The danger, as with all such systems, is that people will start programming in keywords and introducing overly complex structures that become unmanageable. That is why I hate the Scenario table feature in FitNesse. A nice feature of Robot, that I have not spotted before, is that there is no difference in how (script) keywords are used in higher level keywords from how library definitions (code keywords) are used. This allows developers to push an implementation of a keyword into code once it becomes complex enough, without changing any of the tests that use it. I haven’t done this myself on a commercial project so I can’t guarantee it, but my gut-feel is that this allows people to control the complexity of a keyword-script system effectively and keep it manageable.
The Robot IDE is where the growth will be in the near future. It already has some nice functions that make creation of Robot tests easier and the core team is now working mostly on adding features that will make searching, changing and maintaining easier. This includes extract-keyword refactoring. I don’t really expect this to ever become as fully featured as a programming IDE, but it should address the most common problems with managing layers of specifications built on layers of script keywords.
The test structure is getting a lot less technical. Pekka showed all examples in plain-text format which he now prefers over the HTML format. I always found the Robot HTML test format a bit too technical but the plain text one looks and feels much better. Robot now supports several ways of matching parameters, including a Gherkin-style language.
|
|
Hi Gojko,
great summary of some of the key features of robotframework. We are using it successfully a lot, especially with the plain text format and giwen/when/then style. Most of how we use it end up in our blog, so you (or your readers) might find some interesting ideas there, in the Agile Testing category:
http://blog.codecentric.de/en/category/agile-en/agile-testing-agile-en/
Kind Regards,
Andreas Ebbert-Karroum
“but my gut-feel is that this allows people to control the complexity of a keyword-script system effectively and keep it manageable.”
oh, it still heavily depend on the people using it. so many people complained that robot is hard / complex to use, and in my opinion, they are all execuses.
-xuyi