The document discusses the Screenplay pattern as an alternative to page object models for structuring automated test code. The Screenplay pattern models tests as interactions between actors performing tasks. This improves test code design by separating responsibilities and following SOLID principles. The pattern models the problem domain rather than the technical solution, focusing test code on key user tasks. This makes test code more maintainable, flexible and resilient to changes than traditional page object approaches.
9. Just enough to give confidence
that the product hangs together
for the key usage examples
DON’T try to prove that
absolutely everything
works together in
absolutely every way
that the whole product
is supposed to
10. The Screenplay pattern is as a way of
separating any kind of interactions with your
product, including RESTful APIs, Web or
any form of interaction.
For the purposes of this talk, we’re going to
focus on page objects…
12. Support code using Page
Objects
Todo List Page
newTodo
todoItems
todosRemaining
toggleAllButton
clearCompletedButton
filterTodos
…
addATodoItem()
addTodoItems()
toggleAllCompleted()
filterItems()
…
Responsibilities
How to find page elements
How a user completes given tasks
14. “Selenium is not unstable, and your tests
don’t need to be flaky. […] When your tests
are flaky, do some root cause analysis to
understand why they’re flaky. It’s very
seldom because you’ve uncovered a bug in
the test framework.”
-Simon Stewart, Google Testing Blog 2009, “My Selenium Tests Aren't
Stable!”
18. “A code smell is a surface indication that
usually corresponds to a deeper problem in
the system. The term was first coined by
Kent Beck while helping me with my
Refactoring book.”
-Martin Fowler
23. Single Responsibility Principle
“If a class has more than one responsibility,
then the responsibilities become coupled.
Changes to one responsibility may impair or
inhibit the class’ ability to meet the others.
This kind of coupling leads to fragile designs
that break in unexpected ways when
changed.”
-Robert Martin, Agile Principles, Patterns & Practices
24. Open Closed Principle
The Open Closed Principle (coined by
Bertrand Meyer in Object-Oriented Software
Construction) states that a class should be
open for extension, but closed for
modification. This means that it should be
possible to extend behaviour by writing a
new class without changing existing,
working code.
39. Instead of a few
large classes,
you have more
smaller classes.
When you identify
a new task an
actor must
perform, just add
a new task class.
40. You don’t have to use cucumber for this either…
Example using Screenplay implementation in Serenity-BDD
41. Your scenario is a narrative for a cast of
actors, each playing a different role. Each
actor has the task of performing action to
the best of their ability…
44. Before you begin
Don’t aim to refactor all of your support
code.
Try an experiment alongside what you have.
See how it feels and if you like it, look at
how to use the approach with new
scenarios.
46. • As any support code grows, ask first “are
we testing too much here?”
• Big classes with interaction methods (like
PageObjects) are useful as training
wheels
• As we try to go faster, training wheels
make us less stable
• The Screenplay Pattern allows us to ride
more safely, at speed, from the start
