This article shows corporations that have more than one application how to increase the ROI of their automated tests by having test frameworks with highly readable DSLs and reusable components. Companies with only one application still benefit from using the test frameworks suggested here for various reasons that we are going to explore.

本文向拥有多个应用程序的公司展示了如何通过具有高度可读的DSL和可重用组件的测试框架来提高自动化测试的ROI。 由于我们将要探讨的各种原因，只有一个应用程序的公司仍然可以从此处建议的测试框架中受益。

Note: Automated tests here refer mostly to UI automated tests for web and mobile apps. However, we will also look at a few examples of API tests.

注意：此处的自动化测试主要是指针对Web和移动应用程序的UI自动化测试。 但是，我们还将查看一些API测试示例。

问题 (The Problem)

In general, there are two types of reactions to automated testing. The first reaction is that it is difficult, takes too much time, devs can churn out features at a faster rate than testers can automate the tests, and we do not have the skills or the resources to do it, so let’s continue with manual testing for now. The second reaction is that it is easy, so let’s not spend too many resources on it. We can always catch up in the next sprint — and they never do.

通常，对自动化测试有两种类型的React。 第一个React是，这很困难，需要花费太多时间，开发人员可以以比测试人员可以自动化测试的速度更快地推出功能，而且我们没有技能或资源来进行测试，因此让我们继续进行手动测试目前。 第二个React是它很容易，所以我们不要在它上花费太多资源。 我们总是可以赶上下一个冲刺，而他们永远都做不到。

Well, here’s the hard truth: It is not easy to write and maintain automated tests, but you can make it easier and faster by using the right approach.

好吧，这是一个硬道理：编写和维护自动化测试并不容易，但是您可以通过使用正确的方法使其变得更容易，更快。

The first reason why automated testing is not as easy as many think it would be is that the UI nowadays is so much richer compared to a decade ago. Not only are the visuals getting more appealing, but the interactions — especially on mobile devices — are getting more complex. Suddenly, we are no longer dealing with just a single swipe but simultaneous multiple swipes to browse through the lists of movies on the Amazon Prime Video mobile app. Not to mention that in the pursuit of a richer lifestyle, a gamut of wearable IoT devices is born.

自动化测试并不像很多人想象的那么容易的第一个原因是，与十年前相比，如今的UI更加丰富。 不仅视觉效果越来越吸引人，而且交互(尤其是在移动设备上)的交互也越来越复杂。 突然，我们不再只处理一次滑动，而是同时进行多次滑动来浏览Amazon Prime Video移动应用程序上的电影列表。 更不用说，在追求更丰富的生活方式时，可穿戴式物联网设备便应运而生。

The second reason automated testing is notorious for taking a lot of time and effort is that the Agile landscape means tests often require changes in a short period of time. Over the years, I have seen a lot of automation code that struggled against this. Fast-paced release cycles require a smarter test approach. It is not just about writing the tests but also about easy-to-change code ready to reflect requirement changes on the fly, and yet with confidence that the code change will not break any tests.

自动化测试以花费大量时间和精力而臭名昭著的第二个原因是，敏捷环境意味着测试通常需要在短时间内进行更改。 多年以来，我已经看到许多自动化代码为此而苦苦挣扎。 快节奏的发布周期需要更智能的测试方法。 这不仅涉及编写测试，而且还涉及易于更改的代码，这些代码随时可以反映需求的变化，并且充满信心地认为代码更改不会破坏任何测试。

解决方案 (The Solution)

For testing to catch up to development, the QA team should take a leaf out of the dev team’s book. There is often a seed project that the developers can use to build an app right away. For instance, the seed project may contain a sample of an Angular project plus access to a wealth of Angular components from a central repository that your firm may have introduced to keep the look and feel consistent across all the apps developed in the firm. Learning by example, there should also be a seed project for automated tests — a test framework that imports a library consisting of components interacting with the UI components.

为了进行测试以赶上开发的步伐，质量检查小组应该从开发小组的书中删除。 通常有一个种子项目，开发人员可以立即使用它们来构建应用程序。 例如，种子项目可能包含一个Angular项目的示例，并可以从您的公司可能引入的中央存储库访问大量Angular组件，以使公司中开发的所有应用程序的外观保持一致。 通过示例学习，还应该有一个用于自动化测试的种子项目-一个测试框架，该框架导入由与UI组件交互的组件组成的库。

One such test component is highlighting a certain time period in a chart, which is certainly not something that can be done in a matter of one or two hours and guaranteed to be bug-free. Considering that it is no easy feat, we certainly do not want to repeat the effort in another project when both projects use the same graphical component — hence the goal of this article: free the testers from automating the app and let them focus on the real testing work.

这样的测试组件之一就是突出显示图表中的某个时间段，这肯定不是一两个小时就能完成的事情，并且保证没有错误。 考虑到这并非易事，当两个项目使用相同的图形组件时，我们当然不希望在另一个项目中重复工作—因此，本文的目标是：使测试人员从使应用程序自动化的过程中解放出来，让他们专注于真正的应用程序。测试工作。

Another reason for using a seed test project is that there is really no merit in having many test automation frameworks with varying implementations in the firm, unlike the concept of microservices that gives the dev team flexibility to choose the technology and language of choice best suited for the type of work it is doing. In fact, giving each squad or tribe the flexibility to use their own test framework of choice means loss of time because some may choose to write the framework from scratch, confusing test frameworks because each has his or her own interpretation of Page Object, and there is also the inability to share the test code.

使用种子测试项目的另一个原因是，在公司中拥有许多具有不同实现方式的测试自动化框架真的没有好处，这与微服务的概念不同，微服务的概念使开发团队可以灵活地选择最适合的技术和语言。它正在执行的工作类型。 实际上，给每个班组或部落一个灵活性来使用他们自己选择的测试框架意味着浪费时间，因为有些人可能选择从头开始编写框架，而使测试框架混乱，因为每个人对页面对象都有自己的解释，因此也无法共享测试代码。

This article suggests that the firm keeps to only one or two test frameworks, these frameworks employ the Screenplay Pattern approach, and teams collaborate to produce reusable test components.

本文建议该公司仅保留一个或两个测试框架，这些框架采用“剧本模式”方法，并且团队协作以产生可重用的测试组件。

剧本模式 (The Screenplay Pattern)

There are three compelling reasons to use the Screenplay Pattern to scale:

使用“剧本模式”进行缩放有三个令人信服的理由：

1. It enables a highly readable DSL to be written, as we will see in the next section. Once the DSL is written, anyone (devs, manual testers, BAs from any squad) would be able to use it with a modest learning curve to form tests thanks to the easy-to-understand and articulate way to express the tests. This, in turn, speeds up the test writing process.
   正如我们将在下一节中看到的那样，它使能够编写高度可读的DSL。 一旦编写了DSL，由于易于理解且表达清楚的方式来表达测试，因此任何人(开发人员，手动测试人员，任何班级的BA)都可以使用它以适度的学习曲线来形成测试。 反过来，这可以加快测试编写过程。

2. It is based on the concepts of actors, tasks, actions, and questions. Tests are formed by describing the tasks and questions from the viewpoint of the actors (users of the app) rather than pages or components. Each task is made up of actions (or even tasks). For instance, a search for flights is a task on a travel website and entering the destination is one of the actions for the task. The question we want answered is the total matching flights returned. Having them written this way means the action (“enter a value into the input field”) and the question (“the total items returned in the list”) can be reused in a shared library because they are solution-based interactions commonly found in most apps. Even business-based interactions can be shared across projects. For instance, someone in another department in your firm may have written the test code for adding, deleting, and retrieving an event from Google Calendar via API calls. If your app relies on the same interactions, then you could just reuse the shared task without taking a peek at the Google API documentation. Or perhaps your team’s app relies on the customer data created by another team’s app. In the same way, you could just reuse the Screenplay task shared by the other team to create the test data prior to running your test.

   它基于参与者，任务，动作和问题的概念。 通过从参与者(应用程序的用户)而不是页面或组件的角度描述任务和问题来形成测试。 每个任务由动作(甚至任务)组成。 例如，搜索航班是旅行网站上的任务，而输入目的地是该任务的动作之一。 我们要回答的问题是返回的匹配航班总数。 以这种方式编写它们意味着操作(“在输入字段中输入值”)和问题(“列表中返回的项目总数”)可以在共享库中重用，因为它们是基于解决方案的交互，通常在大多数应用。 甚至基于业务的交互 可以在项目之间共享。 例如，您公司另一部门的某人可能已经编写了用于通过API调用从Google日历添加，删除和检索事件的测试代码。 如果您的应用程序依赖于相同的交互，那么您可以重用共享任务，而无需查看Google API文档。 或者，您团队的应用程序依赖于另一个团队的应用程序创建的客户数据。 同样，您可以在运行测试之前重用其他团队共享的Screenplay任务来创建测试数据。

3. At its core, the Screenplay Pattern is the application of the SOLID design principles. Desirable traits like separation of concerns, high cohesion, and loose coupling resulting from the principles pave the way for a clean, maintainable, and malleable test code.
   剧本模式的核心是SOLID设计原则的应用。 理想的特征，如关注点分离，高内聚性和由原理产生的松散耦合，为编写干净，可维护和可延展的测试代码铺平了道路。

为什么不页面对象？ (Why Not Page Object?)

A seasoned tester would find that Page Object falls short of a scalable and maintainable test suite. Many tried to overcome the weaknesses by employing variations of Page Object. In my opinion, the best variation so far is breaking the UI into components instead of pages and introducing a layer of abstraction between the UI and the tests. John Smart’s article on how to write Page Objects that “suck less” further suggests how to improve the approach by storing only the locators in the Page Objects, keeping the Page Objects free of business logic, and categorising the abstraction layer into actions and questions. Next, apply the SOLID principles and use objects rather than methods to represent the actions and questions, and we naturally arrive at the Screenplay Pattern.

经验丰富的测试人员会发现Page Object缺少可伸缩且可维护的测试套件。 许多人试图通过使用Page Object的变体来克服这些缺点。 我认为，到目前为止最好的变化是将UI分解为组件而不是页面，并在UI和测试之间引入了抽象层。 John Smart的有关如何编写“吸气更少”的页面对象的文章进一步建议了如何通过仅将定位符存储在页面对象中，使页面对象不受业务逻辑影响以及将抽象层归类为动作和问题来改进该方法。 接下来，应用SOLID原理并使用对象而不是方法来表示动作和问题，我们自然会得出编剧模式。

Head to the Resources section down below to read articles that explain why you would want to employ these techniques. After reading the articles, you should be convinced of the benefits of the techniques mentioned.

前往下方的“资源”部分以阅读文章，这些文章解释了为什么要使用这些技术。 阅读文章之后，您应该确信所提到的技术的好处。

Perhaps you are already using Page Object and thinking of just using some of the techniques above without fully resorting to using the Screenplay Pattern. I’ll show you why you would still want to consider rewriting your whole test framework or switch over to a test framework that supports the Screenplay Pattern.

也许您已经在使用Page Object，并考虑仅使用上述某些技术，而没有完全采用Screenplay Pattern。 我将向您展示为什么您仍要考虑重写整个测试框架或切换到支持“剧本模式”的测试框架。

We have established in the previous section that a fluent DSL is highly attractive to meet our goal of a scalable test framework. Let’s take Cheapflights or any travel website as an example. Say a user wants to fly from London to Bali on the 1st of October 2020 and return on the 31st of October 2020. In the Page Object world, the action “search flights" would be represented by the ensuing method. This is the method that contains the implementation of the interactions with the website that you would call from your step library. We are not going to go into why you shouldn’t do the implementation in the step library itself.

在上一节中，我们已经证明，流利的DSL对于满足我们可扩展的测试框架的目标非常有吸引力。 让我们以Cheapflights或任何旅游网站为例。 假设用户想在2020年10月1日从伦敦飞往巴厘岛，然后在2020年10月31日返回。在页面对象世界中，“搜索​​飞行”动作将由随后的方法表示。包含您将要从步骤库调用的与网站的交互的实现，我们将不讨论为什么不应该在步骤库本身中进行实现。

searchFlights("London", "Bali", "1 October 2020", "31 October 2020");

In an attempt to make this read better, you might use the Builder Pattern so that calling the method now looks like this:

为了使阅读效果更好，您可以使用“构建器模式”，以便现在调用该方法如下所示：

Flight flight = Flight.builder()
                      .from("London")
                      .to("Bali")
                      .departOn("1 October 2020")
                      .returnOn("31 October 2020")
                      .build();searchFlights(flight);

Now that looks better, but the Screenplay Pattern can make it even more elegant. This is possible because the action “search flights" is an object:

现在看起来更好了，但是“剧本模式”可以使它更加优雅。 这是可能的，因为“搜索飞行”操作是一个对象：

SearchFlights.from("London")
             .to("Bali")
             .departOn("1 October 2020")
             .returnOn("31 October 2020");

Let’s take another example on the website. After making the basic search, users are presented with the search results and options to filter the results. Some of the options are in the form of a slider. You might create a Page Object for the slider component that takes in the data attribute of the slider container as a parameter to differentiate the sliders on the results page. Using the Builder Pattern for the stopover duration slider, the code looks like this:

让我们在网站上再举一个例子。 进行基本搜索后，将向用户显示搜索结果和用于过滤结果的选项。 一些选项采用滑块的形式。 您可以为滑块组件创建一个Page对象，该对象将滑块容器的data属性作为参数来区分结果页面上的滑块。 使用“构建器模式”作为中途停留时间滑块，代码如下所示：

Slider stopoverDurationSlider = Slider.builder()
                      .id(stopoverDurationSliderId)
                      .min(30)
                      .max(120)
                      .build();
slide(stopoverDurationSlider);

Compare that with the following if you were to use the Screenplay Pattern. Again, notice how the latter looks more fluent and natural:

如果要使用编剧模式，请与以下内容进行比较。 再次注意，后者看起来更流畅和自然：

Slide.toMin(30)
     .andToMax(120)
     .the(stopoverDurationSlider)

There you have it. The solid reasons not to use Page Object.

你有它。 坚实的理由不使用Page Object。

使用哪种测试框架 (Which Test Framework to Use)

If you are sold on using the Screenplay Pattern but do not know how or where to begin, fret not because there are already a few open-source test frameworks that support it.

如果您以使用“剧本模式”而被出售，但不知道如何开始或从何处开始，那就不要担心，因为已经有一些开源测试框架支持它。

Serenity BDD is a Java-based test framework that supports both the Page Object and Screenplay Pattern. It acts as a wrapper on top of Selenium Webdriver for web automation and Cucumber/jBehave for BDD. You can also use it with Appium for mobile and desktop automation — see Appium for Mac and Appium Windows Driver — and REST-assured for RESTful API testing. That’s pretty much everything covered except Windows 7 because Appium Windows Driver only supports Windows 10 and above.

Serenity BDD是基于Java的测试框架，同时支持Page Object和Screenplay Pattern。 它充当用于Web自动化的Selenium Webdriver和用于BDD的Cucumber / jBehave的包装。 您还可以将其与Appium一起用于移动和桌面自动化(请参阅Mac版的 Appium和Appium Windows驱动程序) ，以及针对RESTful API测试需要REST保证的版本。 除了Windows 7之外，几乎所有内容都涵盖在内，因为Appium Windows驱动程序仅支持Windows 10及更高版本。

It also comes in the TypeScript flavour, namely SerenityJS, for those who prefer the language. And if you prefer Puppeteer or its successor Playwright, SerenityJS doesn’t support them at the moment, but there is always an opportunity to extend the framework to include these libraries.

对于喜欢该语言的人来说，它还具有TypeScript风格，即SerenityJS 。 而且，如果您更喜欢Puppeteer或其继任者Playwright ，SerenityJS目前不支持它们，但是总有机会将框架扩展为包括这些库。

Serenity BDD and SerenityJS have already solved part of the problem by giving us a plethora of common actions like hover, double-click, scroll to a target, move mouse to a target, and more. Also, see the available questions and matchers. I have personally used Serenity for a number of years and have been impressed by the built-in functionalities, including a great reporting tool. It also integrates with ngWebDriver to handle asynchronous apps.

Serenity BDD和SerenityJS通过给我们提供了许多常见的动作(例如，悬停，双击，滚动到目标，将鼠标移至目标等等)已经解决了部分问题。 另外，请参阅可用的问题和匹配器 。 我已经使用Serenity多年了，并且对内置功能(包括出色的报告工具)印象深刻。 它还与ngWebDriver集成以处理异步应用程序。

For the missing Windows 7 coverage (after all, it still has a 33.44% share in the market compared to Windows 10 at 55.72%, according to the latest Windows OS Families coverage report by Perfecto Mobile), I recommend using Specflow integrated with FlaUI. Specflow is a great .NET test framework that supports BDD and some additional extensions, although the latter is only available via licensing in Specflow+. Meanwhile, FlaUI is a driver in .NET that uses Microsoft’s UI Automation libraries under the hood to interact with Win32, WinForms, and WPF desktop applications. The good news is there is a project that wraps around Specflow that enables Screenplay Pattern usage called CSF.Screenplay, and it is inspired by Serenity. Therefore, you will be familiar with it right away if you have been working with Serenity. The bad news is, at the time of writing, it only has the extension to work with Selenium WebDriver, so you would have to create the FlaUI extension or wait for someone to contribute to the project.

对于丢失的Windows 7覆盖率(毕竟，它仍然有33.44％的份额在市场上比Windows 10的55.72％，根据最新的Windows操作系统家族覆盖报告由PERFECTO移动)，我建议使用Specflow与集成FlaUI 。 Specflow是一个出色的.NET测试框架，支持BDD和其他一些扩展，尽管后者只能通过Specflow +中的许可获得。 同时，FlaUI是.NET中的驱动程序，它使用Microsoft的UI自动化库在后台与Win32，WinForms和WPF桌面应用程序进行交互。 好消息是，有一个围绕Specflow的项目，它启用了名为CSF.Screenplay的 Screenplay Pattern用法，它的灵感来自于Serenity。 因此，如果您一直在与Serenity合作，您将立即熟悉它。 坏消息是，在撰写本文时，它仅具有与Selenium WebDriver一起使用的扩展 ，因此您将必须创建FlaUI扩展或等待有人为该项目做出贡献。

综上所述 (In Summary)

Teams should start collaborating and not working in silos, as is often the case when it comes to automating tests. Having a single test approach is crucial, and we have seen in this article why the Screenplay Pattern is the cornerstone of a successful automation collaboration.

团队应该开始协作，而不是孤零零地工作，这是自动化测试的常见情况。 拥有单一测试方法至关重要，我们已经在本文中看到了为什么“剧本模式”是成功进行自动化协作的基石。

In short, use the Serenity BDD Java test framework. Offer SerenityJS as well if you have the extra capacity to let testers work with TypeScript. And finally, add the support for FlaUI via CSF.Screenplay if you care about your Windows 7 user base.

简而言之，请使用Serenity BDD Java测试框架。 如果您有足够的能力让测试人员使用TypeScript，也可以提供SerenityJS。 最后，如果您关心Windows 7用户群，请通过CSF.Screenplay添加对FlaUI的支持。

资源资源 (Resources)