Press "Enter" to skip to content

I can share the story of the previous team I helped. They were using Robot Framework on my recommendation but finally switched to CucumberJS.

To link Robot Framework with your product/code will take a lot of code anyway. All these tools require a lot of code whatever you do.

In the case of this team, CucumberJS was also felt as a better technical solution than Robot Framework.

It’s actually both the strength and weakness of Robot Framework: relying on a client-server architecture to be able to connect with any kind of systems is a powerful strength… Robot Framework is agnostic of the underlying systems. But in the case of this team, this strength never really came to be used.

On the other hand, testing browser stuff (since we’re talking about JavaScript) can be quite challenging in itself. In particular all the data/synchronization stuff can become pretty hardcore if you go into the fine details of the application. For this specific use-case, the architecture of Robot Framework made things even harder.

This is to be opposed to CucumberJS which is fully written in JS and can be directly run in the browser. This solves quite a lot of the synchronization between test case handling and system-under-test observation as everything is then done in the same system without network interaction.

Obviously and as usual, it all depends on your context 🙂