Hacker News new | ask | show | jobs
by 3am 5538 days ago
Surprised that the Robot framework didn't come up here.

Cucumber's domains specific business language approach is great to when you have a larger group of people, and you want to give non-technical staff (product managers) a way to write tests directly instead of requirement documents. Ideally it provides the non-technical people a vocabulary to describe a test, and mapping that vocabulary to the AUT is up to a test engineer.

Selenium can be that lower level of implementation for cucumber, or can describe the test cases itself. As you noted, Selenium provides a simplifying api for DOM parsing and JS execution, which is a pretty reasonable language for describing a test (if not a little low level and requiring the technical chops that cucumber seeks to avoid).

Robot allows the test designer to compound low level actions into higher level ones in a way that is transparent. I think it strikes a pretty good compromise between high level (cucumber) and low level (direct Selenium API calls).

TL;DR'ing myself: you last paragraph makes me think you'd like the robot framework.

1 comments

Do bear in mind that just writing tests using business language in cucumber doesn't make then run. You still have to use some sort of test library underneath it to power the steps. In my current work I'm using the selenium API to do this, which hopefully is creating readable tests which re-use test execution code that makes updating them to UI changes far easier than just using a recording tool.
Oh, I know, I just was trying to highlight that the underlying library (as far as I know cucumber) is opaque when defining the test, where in robot it's a little less so. Separately, since you're familiar with it - does cucumber allow you to compose new actions from existing actions?

I had a longer post and pared it back... I actually think both frameworks are good in different situations, it just depends how the company is structured and what kind of QA group you have.

FWIW, I have done QA for 11 years, mostly doing automation.