That's what i do not like about idea: you've been given BDD, which DSL is so poor in customization, you end up bringing yet another abstraction layer to your methods, so that everytime you maintain / add new step definitions, there's the api at hand to help you build it better. But what if I told you the same thing can be done without BDD and its DSL! just ship a python-pytest code with good page-object-model tests. Code design is a never ending battle between DRY (do not repeat yourself) and KISS (keep it simple, stupid). Where as abstraction layers help you with DRY, they inevitably add up complexity.
I don't like writing bad comments but latest trend in automation are aimed to make automation process even more complicated then before. I'm not fan of BDD, as it's aimed to make PO/BA and other non-tech guys to write tests, but 99% of time only we, automation, are dealing with that. Not them. This, ScreenPlay approach adds one more abstraction layer - it's totally useless, I can't see any good reason to implement it, since it doesn't solve any problem but instead make it (LOL)
Screen play is the reason I’m considering to use Serenity in my new project. The old steps and page objects way of doing things did. never work for me. My beef with screen play is that the API is not well documented. On Cucumber: I too did not see the point in using it as long as the PO did not use it to write his idea down. Nowadays I see lots more eagerness to do so.
Interesting idea, to base your tests on the goals/tasks the user performs, rather than the UI interactions. I tried something similar in production code with my project requirementsascode: github.com/bertilmuth/requirementsascode.
That's what i do not like about idea: you've been given BDD, which DSL is so poor in customization, you end up bringing yet another abstraction layer to your methods, so that everytime you maintain / add new step definitions, there's the api at hand to help you build it better.
But what if I told you the same thing can be done without BDD and its DSL! just ship a python-pytest code with good page-object-model tests. Code design is a never ending battle between DRY (do not repeat yourself) and KISS (keep it simple, stupid). Where as abstraction layers help you with DRY, they inevitably add up complexity.
I don't really get it, if u r using DSL already (cucumber, cypress, robot framework ...), why do u need to use screenplay as the addition?
I don't like writing bad comments but latest trend in automation are aimed to make automation process even more complicated then before. I'm not fan of BDD, as it's aimed to make PO/BA and other non-tech guys to write tests, but 99% of time only we, automation, are dealing with that. Not them. This, ScreenPlay approach adds one more abstraction layer - it's totally useless, I can't see any good reason to implement it, since it doesn't solve any problem but instead make it (LOL)
This abstraction layer makes it easier to communicate and my PO/BA to read.
Screen play is the reason I’m considering to use Serenity in my new project. The old steps and page objects way of doing things did. never work for me. My beef with screen play is that the API is not well documented. On Cucumber: I too did not see the point in using it as long as the PO did not use it to write his idea down. Nowadays I see lots more eagerness to do so.
Interesting idea, to base your tests on the goals/tasks the user performs, rather than the UI interactions. I tried something similar in production code with my project requirementsascode: github.com/bertilmuth/requirementsascode.