|
|
|
|
|
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. |
|