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

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.