Writing Tests Like Shakespeare Keep your automated tests readable with the Screenplay pattern

Timetable

Thursday 19th,

11:45 a.m. – 12:30 p.m.

Room

Talks (Track 2) – Indoor Hall

Session Type

25-minute Talk,

Advanced session

Audience

Testers, Automation Engineers, Developers

Key-Learnings

  • Learn what the Screenplay pattern is and how it can help you to write better tests.
  • Get to know the key concepts of Screenplay to implement your own or use an existing framework supporting it.
  • Discover how object-oriented design can help to make test code less cumbersome.
  • Find out about a way to keep your tests concise and readable, while using all the Selenium tweaks and tricks to keep them fast and reliable.
  • See how Screenplays allow you to write tests that use different media –like web, email or APIs–, a surprisingly easy experience.

The screenplay pattern can help you to write complex test code (especially but not only for UIs) in a readable, maintainable and strictly user-centric way using any given language and framework.

Automated tests—especially UI tests—often lack readability. They have either a very fine-grained description of the performed actions, or a too sophisticated abstraction which leaves the reader guessing or digging deep into the code base. This becomes a serious problem when we try to understand the context of a test failure. A NoSuchElementException only tells us which element was missing, not why we expected it to be there at the specific point in our test. Another common problem in complex tests is code duplication. Either we just copy and paste long sequences of dull commands, or we forget to use the functions and utils we hide. This makes maintenance a very frustrating experience. Finally, such code is often not fit for being shared among teams working on the same product, or for being reused in different tests. The Screenplay pattern offers a user-centric way of writing tests which abstracts fine-grained interactions into simple non-technical tasks and questions. These make it easy to introduce just the right level of abstraction for the use case at hand. The resulting test code is almost plain natural language with only a few extra “cody” characters, but I assertThat(averageReader.does(understandThis())).isTrue(). As every failure is happening in the context of performing a task or answering a question, understanding failures also automatically becomes a much easier endeavor. Sharing Screenplay code between tests or even among teams is pretty easy as the tasks and questions are implemented as simple immutable objects. This also makes it easy to implement Screenplays in any preferred language and framework. So if this sounds like a good idea to you, come to my talk and learn how to write tests like Shakespeare.


More Related Sessions


  • Talk
  • Workshop
  • Bonus
  • Keynote
  • Social

105-minute Workshop

10:45 a.m. – 12:30 p.m. Workshops (Track 3) – Indoor "Machbar" Equipment required

45-minute Keynote

3:15 p.m. – 4:15 p.m. Main Stage – at the Beach

25-minute Talk

11:45 a.m. – 12:30 p.m. Talks (Track 2) – Indoor Hall

105-minute Workshop

10:45 a.m. – 12:30 p.m. Workshops (Track 4) – Tent at "Machbar"