Robot Framework Tutorial 2016
Part 1: Installation
Part 2: Keywords
Part 3: Implementing Keywords in Java
Part 4: Selenium2Library as a drop-in replacement for SeleniumLibrary
Part 5: Integration with TeamCity CI-Server
Part 6: Integration with Jenkins
Part 7: File Processing
Part 8: Working with Collections
Part 9: Wrap-Up and Conclusion
The year 2016 is coming to an end and as this is the “Robot Framework Tutorial 2016” it is kind of the last chance to add the final chapter for this tutorial. Everything started in January this year with the first blog post on how to install the Robot Framework. But it is not the idea of this post to simply list again all the previous ones. They are anyway listed at the top of this page. But there is one – for me a bit exceptional – blog post I would like to mention though. That is the one about keywords. Not only are keywords the central concept of the Robot Framework, but I also started a small example project on GitHub for it. This was extended in the course of the tutorial when new concepts have been shown which I personally like a lot, having one central place for all these examples.
Pros and Cons using the Robot Framework
But now to something completely different :-). I like the tool for reasons not all being totally objective. But of course there are quite some really strong pros for the tool as there are cons as well (very diplomatic of me, right?). I would really like to avoid getting into bullet point lists of pros and cons here, but instead let’s talk about the people I believe the Robot Framework is a good choice for. Those are definitely “testers” or “QA-people” and yes, there are projects out there that have these roles still explicitly. Typically testers do not have a strong programming background, but are for sure totally capable of writing tests and own keywords using the Robot Framework. And let’s face it: They are much more dedicated to the testing subject than developers taking over that role (temporarily).
On the contrary we are having those projects that do not have an explicit testing role. Still there is a need to write automated tests and developers like to stay inside their IDEs. Therefore tools like JBehave or Cucumber are typically first choice in those cases.
Then we can have a mixed approach of course where developers are implementing the testing functionality. This can be done basically using any of the before mentioned frameworks. Then the testers are building their tests on top of this. This can really work well, but I also think it limits the creativity of the testing to some extend. Whenever there is something where no testing functionality is available yet the tester needs to request that one from a developer and then wait for it while doing something else. This could be ok, but it is something really worth thinking about and discussing in the team before choosing a testing framework and thus also a testing approach.
Some thoughts on letting the subject-matter experts write tests
What about letting the users of the application write some tests, assuming this is possible and wanted from an organisational point of view. I have simply never seen that this worked out. And even if it might look as if it works in the beginning – while a lot of effort is put into this from the development team – it dies in the long run. There are simply too many technical hurdles that might seem small to us, but they are not. It starts with simple syntactical problems and cryptic error messages. Now the Robot Framework brings its own IDE, which has really made huge progress since that blog post has been written. But still I doubt that it really works out for non-technical users. Another problem is that tests must be put under version control. If users should write tests they must use the version control system as well. Not good! Let alone the problem of defining testdata that allows tests to be executed repeatedly.