Rename again

[aslakhellesoy]

The current new name is bound to create the false impression that this integrates with https://github.com/microsoft/playwright

I’ll rename to dollshouse next week as I suggested in #25 - unless someone convinces me of a better name first.

/cc @mattwynne @vincent-psarga

[mattwynne]

Ugh. Shame. I really like "playwright".

Why dollshouse? What's the metaphor?

Other ideas:

• screenplay-lite
• action-stations
• ...

Honestly, I disagree with @jan-molak's assertion in #25 that this isn't faithful enough to the screenplay pattern to share the same name. I think it's close enough to be relevant and easily found from a search query. The differences are interesting and perhaps just reflect an evolution of the pattern. Certainly I think what we've done here with polymorphism for interactions is really important work.

Also, I think we should add Tasks to this library, because they're awesome.

I'd be interested in @wakaleo / @antonymarcano / @andypalmer's takes on this.

[jan-molak]

Hey @mattwynne - it feels like the main focus of this library is to build on and expand on @aslakhellesoy's earlier work on sub-second TDD and make multi-layer testing easier thanks to polymorphism. I agree with you that this work is important and valuable.

However, I still stand by my opinion that this pattern is significantly different from the Screenplay Pattern, which has five components (Actors, Abilities, Interactions, Tasks and Questions, all serving a specific purpose), and is primarily focused on modelling multi-actor workflows.

In this implementation, there are no abilities, no tasks, and questions and interactions are interchangeable. So I don't think that presenting it as an "evolution" of the Screenplay Pattern is accurate; it is a different pattern and deserves its own name.

Furthermore, I'd argue that by dropping abilities as proposed here, actors become a simple representation of state. This means that you could actually get away without actors altogether and simply pass Cucumber World object to action functions instead. Or, set a world property on this in action functions. This approach does also feel like a more idiomatic Cucumber way.

So, if we've removed tasks, questions, abilities, and actors from the Screenplay Pattern, all that we'd be left with are interactions and a polymorphic loading mechanism (which is awesome, by the way).

Now, if we added tasks back into the mix, as per your suggestion above, we'd arrive at one of @antonymarcano's earlier models that preceded the Screenplay Pattern - see Goals, Tasks, Actions.

Since this feels more in line with the direction of this library, perhaps it would make sense to highlight its focus on actions, and making them polymorphic, and call it say @cucumber/actions?

---

I was thinking about it some more; I think that by using only tasks and interactions, the example from the readme could be reduced even further.

From:

When('{actor} logs in', async function (actor: Actor) {
  // The logIn() function is an Interaction
  await actor.attemptsTo(logIn(`${actor.name}@test.com`, 'valid-password'))
})

to:

When('{name} logs in', name => logIn(`${name}@test.com`, 'valid-password'))

where:

export const logIn: LogIn = (email, password) => {
  return async function (this: { world: World }) {
    this.world.shouty // etc
  }
}

This approach would give Cucumber a way to load step definitions the same you'd load our hypothetical "Cucumber action", which I think is an interesting area to explore.

[aslakhellesoy]

Why dollshouse? What's the metaphor?

It's a play by playwright Henrik Ibsen and one of the most played plays ever. It is also regarded as a great contribution to feminist literature.

For people who don't know the play, I think "doll's house" would invoke associations of multiple actors (that's what you typically find in kids' dolls houses). We could emphasise this with a logo picturing multiple characters in a house (or a cage, as has been used for theatre posters).

And most importantly - I think libraries with original names are more fun - "screenplay" is a bit dull IMHO :-)

Honestly, I disagree with @jan-molak's assertion in #25 that this isn't faithful enough to the screenplay pattern to share the same name. I think it's close enough to be relevant and easily found from a search query.

Ok, let's revisit that discussion.

Abilities

I said previously that playwright doesn't implement them. What I meant is that it doesn't implement them as an actor has abilities OO relationship. However, you could argue that the polymorphic interactions described here and implemented here is just a different implementation of abilities that achieve the same goal. The main difference is that deciding what abilities are available is done in configuration (world parameters) rather than in code.

Tasks

In fact, I think what we currently call interactions in this library should be renamed to tasks. I also think that the decomposition of tasks into interactions is something the library doesn't need an API for. It's just delegation/extract method, and could be handled by user code.

Questions

They are supported through the Actor#ask method.

Also, I think we should add Tasks to this library, because they're awesome.

See my comment above. Screenplay is a pattern, and it is not prescriptive of what parts of the pattern should be implemented in a library, and what should be implemented in user code. I believe decomposing tasks into interactions can be handled by user code and still be faithful to the pattern.

[wakaleo]

I would say that the actors, tasks, questions and abilities are pretty central to the DNA of the Screenplay pattern. What you are describing sounds more like what I called Action Classes in https://johnfergusonsmart.com/page-objects-that-suck-less-tips-for-writing-more-maintainable-page-objects/, and what Cypress refer to as "App Actions". I agree with Jan in that, which there are similarities with the Screenplay pattern, without the activities and questions it really feels like its own thing.

A rendering library could be used as part of an implementation of an MVC pattern, but in itself it does not implement the pattern. The other Screenplay implementations out there, such as the .NET (https://automationpanda.com/2020/10/16/introducing-boa-constrictor-the-net-screenplay-pattern/) and Python (https://screenpy-docs.readthedocs.io/en/latest/) respect the Actors/Abilities/Tasks/Interactions/Questions architecture pretty rigorously.

[antonymarcano]

I don't agree that the fully-fledged implementation is entirely necessary in all cases.
I would say, in its purest state, it's about Actors and Tasks... Here, when you read Task, think the what – e.g. "Make a call". When you read Actions, think the how – e.g. "unlock phone, open contacts, enter 'Aslak' into the search box... etc).

Everything else is just options. Actions can just be imperative lines of code doing things. Questions were just a way to have fluent assertions using a Given/When/Then style in code and due to the constraints of Java largely. I'm not sure that's as relevant with Cucumber (or javascript).

If I need to have a return type for a Task, that would be an Outcome – something you can use to return state (or not).

When I relate this to Cucumber, I explain it something like this:
Goals: the Scenario title is written as the user's goal (e.g. Scenario: Get feedback on why my email was invalid)
-> Tasks: Steps say 'what' the actor is doing (and the Step Def acts as a thin adapter delegating to a Task)
--> Actions: are the 'how' concrete things an actor would do – think 'interactions' – one or more of which will be inside the body of a Task. This could just be imperative lines of code, or that too can be abstracted behind the concept of an Action... Hence, the Actor and Task is the more important concept.

The pattern was intended to break the structural thinking binding people to a 'page' concept (which continued long after the concept of a page in web apps became irrelevant) and to do the same for APIs – enabling what I demonstrated in 2012 – the code for which is here.

Instead, I wanted to encourage people to model the domain – that there are people using our products to complete tasks (like "Pay by Card") to achieve a goal (like "Buy a Book"). The benefits of the resulting abstractions will be clear to this group.

I encourage you to consider thinking of the Actor performing Tasks... and to feel free to continue the exploration of the ideas inspired by Screenplay – under the same name if you would like to... Or under another name if you prefer.

[aurelien-reeves]

I think @cucumber/dollshouse is fine 👍 .

I have also the following suggestion: @cucumber/scene. As the scene is where actors play their parts
Or @cucumber/theater

In those cases, each test domain could be referred as theater sets, backdrops, or scenaries.

[mattwynne]

I like those suggestions @aurelien-reeves. @cucumber/stageplay?

[mattwynne]

But, having now read @antonymarcano's reply I suggest we rename what we've called "interactions" to "tasks", and then keep the name screenplay. I think I'd misunderstood the distinction between those two a little bit.

I can imagine that this library might evolve to support these other concepts as the need for them becomes clearer.

I'm super curious about how we can fit the polymorphism concept into the screenplay metaphor. I'd personally called these Perspectives in a previous iteration of this idea, my thinking being that Actors carry out their Actions through a Perspective.

I have to admit I never really understood Abilities, so not sure where they would fit into this idea.

[antonymarcano]

Abilities came about to separate the actions from the means of achieving them. This is one way to create the option to polymorphically substitute the means by which you interact with the product without having to have multiple implementations of tasks.

…

On Mon, 12 Jul 2021, 22:35 Matt Wynne, ***@***.***> wrote: But, having now read @antonymarcano <https://github.com/antonymarcano>'s reply I suggest we rename what we've called "interactions" to "tasks", and then keep the name screenplay. I think I'd misunderstood the distinction between those two a little bit. I can imagine that this library might evolve to support these other concepts as the need for them becomes clearer. I'm super curious about how we can fit the polymorphism concept into the screenplay metaphor. I'd personally called these *Perspectives* in a previous iteration <https://github.com/cucumber-ltd/feynmanl> of this idea, my thinking being that Actors carry out their Actions through a Perspective. I have to admit I never really understood Abilities, so not sure where they would fit into this idea. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#31 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACAGOMRDHJUNP3OERTLDA3TXNNYJANCNFSM4766FY7Q> .

[aslakhellesoy]

But, having now read @antonymarcano's reply I suggest we rename what we've called "interactions" to "tasks", and then keep the name screenplay. I think I'd misunderstood the distinction between those two a little bit.

I agree.

Decomposing a task into multiple interactions is something I don't think the library needs to provide an API for. It's just an extract method refactoring. It's a concept of the pattern that doesn't need to be implemented in a library. The programming language provides the constructs you need.

[aslakhellesoy]

I've addressed the renames in #34

Here is an example of a task that is decomposed into interactions.

[aslakhellesoy]

Now that #34 illustrates the following:

• Actors
• Tasks
• Questions
• Interactions (aka Actions)
• Abilities (implemented as dynamic loading of polymorphic task implementations)

...do we have your blessing to rename this back to @cucumber/screenplay @antonymarcano?

(BTW, I have updated the credits section with more historical links dating back to 2007).