What do thermodynamics, Cucumber framework, and Screenplay Pattern have in common?
From time to time, I come across texts that are critical of Cucumber. Today, I would like to clarify a few issues about this framework, as well as some more general issues.
However, let’s start with the thermodynamics mentioned in the title.
THERMODYNAMICS — WHAT DOES “ORDER” MEAN IN IT?
The second law of thermodynamics is a fundamental principle in physics that explains the natural tendency of a closed system towards disorder or entropy. It states that in a closed system, the level of entropy will always increase and arrive at a state of thermodynamic equilibrium. Entropy is a measure of the level of disorder or randomness in a system. In other words, as time passes, things tend to get messier, more chaotic, and less organized.
The analogy of the second law of thermodynamics can be applied to software development and testing, where order and structure are highly valued. Just like in a closed physical system, a software system tends to become more disorganized and complex over time if left unchecked. Therefore, extra work is required to maintain the order and structure of a software system and move from a state of higher entropy (higher disorder) to a state of lower entropy (lower disorder).
What does order mean in the case of IT projects? Primarily, it means separation. Here are some examples of IT concepts related to various types of separation:
- OSI model (separate layers: Physical, Data Link, Network, Transport, Session, Presentation, and Application.)
- TCP/IP (layers: link layer, internet layer, transport layer, application layer)
- Operating system architecture (layers: kernel, device drivers, system libraries, user interface, and application layer)
- Test organization (levels: unit tests, integration tests, system tests, user acceptance tests)
- Separation of layout and contents in typesetting and web pages (HTML and CSS)
If we have spaghetti code written in an old-fashioned procedural way with plenty of global variables and goto instructions, it requires extra work to apply object-oriented approach to it. This includes a lot of refactoring, i.e., changes to code that works correctly. What do we get in this way? After separating some classes and placing them in separate files, the code is easier to maintain. We know exactly where to look when we want to change something. Changes in variables of one class are not as error-prone as changes to global variables.
Another example is when we have a large monolithic application. We have to invest some effort to modularize it or change it into microservices. This is again an investment in maintainability.
What are benefits from separation into layers?
- Split of responsibility across people and teams
- Easier investigation of the root cause of defects
- Ability to change one layer without touching others
- Reusability
As we can see, in the world of software, making things separated and encapsulated is highly valued.
CUCUMBER
Cucumber and Behavior Driven Development (BDD) provide an additional layer — a language layer. This requires some effort to maintain it. I fully understand Mr. Zhimin Zhan, who says that this layer is unnecessary for him, and it would cost additional work to maintain it. Yes, he is right. This layer requires extra work. But, at the same time, this layer is an additional level of order. This level may have some value.
However, we can observe some examples in IT development where some level of separation was abandoned. For example, in an agile approach, we do not strictly separate the phases of development as we did in the waterfall approach.
So, do we really need an additional level of order? Here, the situation becomes more interesting. The answer is, as always, it depends. For some projects, this layer is not necessary at all, and in such cases, there is no need to apply Cucumber. However, some projects require this level of communication for non-technical stakeholders.
Moreover, I do believe that this additional level of test description increases the understanding of test scenarios and requirements across the entire team. This is my personal opinion.
I can repeat what I wrote some time ago: When you do not need it, do not use it!
SCREENPLAY PATTERN
In the title, I have also mentioned the Screenplay Pattern. This is another level of separation in testing built upon the Page Object Pattern. It applies the Single Responsibility Principle and separates the responsibilities of Page Objects.
The code of classes representing Page Objects can sometimes be very long and difficult to maintain. Some methods are designed for active interaction with page elements, whereas others should just read the state of page elements. Such large classes should be divided into smaller parts. This is the idea of the Screenplay Pattern. It was proposed in 2007 by Antony Marcano and refined with ideas from Andy Palmer, Jan Molak, Kostas Mamalis, and John Ferguson Smart. The final version was presented in 2016 in the article ‘Page Objects Refactored. SOLID steps to the Screenplay/Journey Pattern’.
The authors pointed out that Page Object Pattern classes usually need to be refactored for several reasons. First of all, they are too large. Such classes also violate the Single Responsibility Principle, Open-Close Principle (see SOLID), and sometimes duplicate parts of code (see DRY).
Another thing that was changed was the focus. Because tests have to take the user’s perspective, the objects have to be organized in an anthropocentric way. In the Page Object Pattern, the center was a web page. Now, the center is an end user — the Actor.
The Screenplay Pattern encourages us to understand several things for every requirement:
- Roles — Who is this for?
- Goals — Why? What is the outcome they hope for?
- Tasks — What they will need to do to achieve the goals?
- Actions — How do they complete each task through specific interactions?
We can say that it is some form of layers of requirement.
In the center of the testing process is the Actor (representing some Role). This is the starting point, whereas the end is a web page. The details are presented in the following figure
In Java the Screenplay pattern is supported by Serenity-BDD framework.
OPEN QUESTIONS
While the Screenplay Pattern appears to be a promising approach, to be honest, for me, the question about the value of this level of separation remains open. I have seen several projects with the Page Object Pattern and one project with the Screenplay Pattern. I do not have enough sample sets in my experience to say if it brings real value. When I read some texts about it, they usually explain the concept but do not provide any statistics about the effectiveness.
Medicine should be evidence-based, and in the same way, software development management should be evidence-based. When somebody asks if TDD is efficient, I know that I am able to provide some hard data about it.
This point (providing some statistics) should be the focus of Screenplay Pattern advocates. Without such statistics, it is difficult to assess the true value of this approach, and it may be challenging to convince skeptics to adopt it. While the Screenplay Pattern appears to be a promising approach, further research and evidence is necessary to fully assess its effectiveness. The theoretical side is pretty clear and understandable, but we need hard practical data.
The story was originally created by me, but it may contain parts that were created with AI assistance. My original text has been corrected and partially rephrased by Chat Generative Pre-trained Transformer to improve the language.
