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 “old” Robot Framework Tutorial.
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.
There might be very specific circumstances where this is working, but most of the time I think it simply doesn’t.
Conclusion
Consider what you want to achieve and your team structure before choosing a testing framework. On the positive side the Robot Framework has really lots of ready-made testing functionality, aka keywords and a very active forum . Those could be assets in the project one should not easily dismiss. Then on the other hand implementing all testing functionality in Java can be very appealing, especially for more developer-centered teams. This might also allow for tests on a bit “lower level” easily without the need to test everything using the GUI. So what can be said: It depends :-).
Just choose wisely and have a really good Christmas time :-).
By loading the video, you agree to YouTube's privacy policy.
Learn more
Always unblock YouTube
Was this post helpful?
More articles
fromThomas Jaspers
22.2.2019 Your job at codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog author
Thomas Jaspers
Do you still have questions? Just send me a message.
Do you still have questions? Just send me a message.