On the robotframework-users mailing list was a question about how radio buttons can be properly handled with the SeleniumLibrary. There was apparently a problem somewhere in the generated xpath expression, and the user found it difficult to debug where things went wrong.
Since I failed to explain to the user in a private e-mail conversation how to debug the situation with the selenium IDE, I made a short screencast. At the end, I had to briefly pause the cast, since I was getting close to the 5:00 restriction, but I hope you’ll catch everything. (read more…)
You started to write automated acceptance tests, so that you don’t need to retest all the results from earlier sprints at the end of every sprint. Greate, we too. After a while of successful test automation, tests start to look like a big ball of mud instead of a cleanly designed test suite. Darn, same for us. Where did we go wrong? Over time, we established a few patterns and best practices, that lead to a scalable and maintainable test infrastructure, which I would like to present in this post. (read more…)
When starting to automate acceptance tests that include a web UI, you probably will hit a wall quite quickly: how to verify a document that is available for download against some criteria? If you tried that one you know: doing file downloads automatically seems to be a mission impossible … or … is it really?
(read more…)
When doing acceptance test driven development, the team writes the tests often by first specifying the behaviour, and then supporting that with a table of examples. How that generally works with the Robot Framework, was already described earlier. As executable specification, those automated tests have to be understandable by all stakeholders. By all means, this includes that they should be written in everybody’s mother tounge – and more often than not, this is not English. This currently does not work with the Robot Framework, does it? (read more…)
Well-fitting to easter I yesterday stumbled on exactly that feature in the Robot Framework that I was missing ever since I am using the tool and that was there in front of my nose all the time … but first things first.
When automating tests there are almost always some properties that depend on the environment where the tests are executed in. Some classic ones are URLs (servernames) for Tests using Selenium or some login information for the database used. Those values will be most likely different on the developer’s machines and the CI environment. Therefore these properties must be “somehow” passed as parameters to the tests, well, to the corresponding keywords to be precise. The Robot Framework supports this with these kind of command line arguments: “–variable NAME:VALUE”. But when having two or more parameters this is already quite confusing and hard to maintain.
(read more…)
The Robot Framework is a very versatile tool and never confronted us with unsolvable problems so far. In some regards it still feels a little rough and needs some polishing, to make development and maintenance of automated tests more efficient. One of those areas is the integration into the well known development environment. There is the Robot IDE, but this only covers a fraction of my requirements. The following will show, how easily the Robot Framework and your own Java Keywords can be integrated in Maven and Eclipse.
(read more…)
category: 
