测试中 (TESTING)

什么是自动UITest？ (What Is Automated UITest?)

When we speak about testing, we usually think about unit testing. However, there is another kind of test that is extremely powerful and useful in the app world: UITests.

当谈到测试时，我们通常会考虑单元测试。 但是，在应用程序世界中还有另一种功能极其强大且有用的测试：UITests。

The goal of these tests is to verify that your UI is behaving as expected: the buttons are in the correct state, the strings are styled correctly and the navigation happens as we code it.

这些测试的目的是验证您的UI行为是否符合预期：按钮处于正确的状态，字符串的样式正确，并且导航在我们进行编码时发生。

The body of the test simulates a user that interacts with the UI, causing the app to evolve over time and allowing us to assert some condition that we want to be true during the app execution.

测试的主体模拟了与UI交互的用户，从而导致应用程序随着时间的推移而发展，并允许我们断言某些条件，这些条件要求我们在应用程序执行期间必须为真。

为什么要执行自动UITest？ (Why doing Automated UITest?)

As all the testing activities, writing proper UITests takes time. However, this time will save us many headaches in the future, and it will also save more time than it consumes, in the long run.

作为所有测试活动，编写适当的UITests需要时间。 但是，这段时间将来将为我们节省很多麻烦，从长远来看，还将节省比其所消耗的时间更多的时间。

Writing automated UITests has numerous benefits, especially in cases where the app is becoming really big and, potentially, hard to maintain. Some of these benefits:

编写自动化的UITests有很多好处，尤其是在应用程序变得非常大且可能难以维护的情况下。 其中一些好处：

• Prevent the need to test old features. In an agile environment, we are creating new features every couple of weeks. However, developers are a bit paranoid: they will ask their QA friends to test the whole app, every time, to avoid regressions. Automated UITest can be used to go through the most common use cases automatically, preserving the sanity of mind of both developers and QA.

  无需测试旧功能。 在敏捷的环境中，我们每两周创建一次新功能。 但是，开发人员有些偏执：他们会要求QA朋友每次都测试整个应用程序，以避免性能下降。 可以使用自动化的UITest自动浏览最常见的用例，从而保持开发人员和质量检查人员的头脑清醒。

• Encode use case knowledge. UITests allows us to see how the app behaves when a sequence of events occurs. This can be useful to keep track of common use cases and to verify that they don’t break down every time we modify the app.

  编码用例知识。 UITests允许我们查看事件序列发生时应用程序的行为。 这对于跟踪常见用例并确保每次我们修改应用程序时它们不会崩溃都非常有用。

• Test UI Performances. Assuming that your app has to perform some heavy UI operations, like scrolling through a big list of images, we can use UITests to measure how much it takes to perform these operations and if there are regressions or not.

  测试UI性能。 假设您的应用必须执行一些繁重的UI操作，例如滚动浏览一大堆图像，我们可以使用UITests来衡量执行这些操作所需的时间以及是否存在回归。

• Check localizations. Assuming that your app is localized, we can automatically check whether some strings are cut with an ellipsis or not.

  检查本地化 。 假设您的应用程序已本地化，我们可以自动检查某些字符串是否用省略号切掉。

These are just some of the advantages of Automated UITests. There could be more of them, but I think that these are the most prominent. Of course, there are downsides as well:

这些只是自动UITest的一些优点。 可能会有更多，但我认为这些是最突出的。 当然也有缺点：

• They take more time to write than Unit tests.

  他们比单元测试花费更多的时间 。

• They take more time to run than Unit tests.

  他们比单元测试花费更多的时间 。

• Given that the UI can change quite often, they tend to be more volatile. There is a risk that your UITests become obsolete in 6 months.

  鉴于UI可以经常更改，因此它们往往更加不稳定 。 UITests有可能在6个月内过时。

Despite these disadvantages, I think that these tests can be really helpful, especially for big apps that have some parts that are unlikely to change. They can be useful also if you have to manage multiple applications with a small team that can focus on only an app at the time.

尽管存在这些缺点，但我认为这些测试确实有帮助，特别是对于某些部分不太可能更改的大型应用程序。 如果您必须由一个只能同时关注一个应用程序的小型团队管理多个应用程序，它们也很有用。

如何编写UITests？ (How to write UITests?)

搭建环境 (Set up the environment)

UITests are integrated into Xcode and our IDE does most of the job for us. The first step is to add a new target for our app that is a UITest target.

UITests已集成到Xcode中，我们的IDE为我们完成了大部分工作。 第一步是为我们的应用添加一个新的目标，即UITest目标。

1. Click on File > New > Target

   单击File > New > Target

2. Select UI Testing Bundle

   选择UI Testing Bundle

3. Click on Next and fill the form with a name

   单击Next然后在表单中填写名称

4. Click Finish.

   点击Finish 。

Xcode will create the new target with the first, empty UITest file. The file has the following structure (notice how many comments Xcode provides, to help us with our first attempt).

Xcode将使用第一个空的UITest文件创建新目标。 该文件具有以下结构(请注意Xcode提供了多少注释，以帮助我们进行首次尝试)。

Let’s focus on the testExample() method. Everything is managed by an XCUIApplication() object. That object is an abstraction of our app. We can launch() and terminate() it and it lets us query all the elements in the UI.

让我们专注于testExample()方法。 一切都由XCUIApplication()对象管理。 该对象是我们应用程序的抽象。 我们可以launch()它和terminate()它，并让我们查询用户界面中的所有元素。

记录我们的第一个测试 (Recording our first test)

Yes, you read right! We are not going to write the test immediately: Xcode offers a very nice and helpful tool that allows us to interact with the app and Xcode will translate our interactions into code. How cool is that?!

是的，你没看错！ 我们不会立即编写测试：Xcode提供了一个非常不错且有用的工具，可让我们与应用程序进行交互，而Xcode会将我们的交互转换为代码。 多么酷啊？！

To start this, we just have to position the cursor in the empty testExample() method, below line 24, and press the small record button at the bottom of Xcode.

要开始此操作，我们只需将光标置于第24行下方的空testExample()方法中，然后按一下Xcode底部的小record按钮即可。

When the record button is pressed, Xcode will launch our app and will capture all the interactions, writing the code for us.

当按下record按钮时，Xcode将启动我们的应用程序并捕获所有交互，为我们编写代码。

For this article, I prepared a very simple app (you can find the code here), which has a view with 3 buttons: a privacy button, a tos (terms of service) button, and a continue button. The Continue button is disabled unless the user taps on both the privacy and tos buttons. Once both the buttons are selected, the Continue button becomes enabled and the user navigates to a blue HomeView when he taps on the Continue button.

对于本文，我准备了一个非常简单的应用程序(您可以在此处找到代码 )，该应用程序具有3个按钮的view ： privacy按钮， tos (服务条款)按钮和继续按钮。 除非用户同时点击“ privacy和“ tos按钮，否则“ Continue按钮将被禁用。 一旦这两个按钮被选中时， Continue按钮将变为启用，用户导航到蓝色HomeView当他在水龙头Continue按钮。

Let’s do a quick experiment and start recording a test. During this use case we want to:

让我们做一个快速实验并开始记录测试。 在此用例中，我们要：

1. Tap on Tap to accept TOS

   Tap to accept TOS

2. Tap on Tap to Accept Privacy Policy

   点击Tap to Accept Privacy Policy

3. Verify that Continue becomes enabled

   确认已启用Continue

4. Tap on Continue and see that the app navigates to the blue view.

   点击“ Continue ，看到该应用程序导航到蓝色view 。

5. Stop recording.
   停止录音。

The output of this process is the following code:

此过程的输出是以下代码：

Notice that Xcode writes another time the let app = XCUIApplication() line. We have to remove it.

注意，Xcode再次编写了let app = XCUIApplication()行。 我们必须将其删除。

Running the test now, by pressing cmd+U, results in Xcode running the app for us and executing again the actions we just performed. The test outcome is a success, mainly because we did not write any assertion.

现在通过按cmd+U ，将使Xcode为我们运行该应用程序并再次执行我们刚执行的操作。 测试结果是成功的，主要是因为我们没有编写任何断言。

写断言 (Write the assertions)

Whenever we have to test a piece of code, we have to write assertions. Assertions are usually boolean checks that let us state some conditions that must be valid to consider the test a success.

每当我们必须测试一段代码时，我们就必须编写断言。 断言通常是布尔检查，可以让我们陈述一些条件，这些条件必须有效才能使测试成功。

Writing assertion in UITests is exactly the same as writing them in standard Unit tests, by leveraging the XCTest framework.

通过利用XCTest框架，在UITests中编写断言与在标准单元测试中编写断言完全相同。

Let’s add the assertion to our code.

让我们将断言添加到我们的代码中。

First of all, we factor out the three buttons into separate variables. In this way, we can query their state. Then we write the assertions. They are pretty easy: just check the buttons’ state as we know it should change during execution.

首先，我们将三个按钮分解为单独的变量。 这样，我们可以查询它们的状态。 然后我们写断言。 它们非常简单：只需检查按钮的状态即可，因为我们知道它在执行期间会发生变化。

Run the test and see.. that they fail! 😨

运行测试，看看..他们失败了！ 😨

How’s that possible? Well, let’s analyze the errors and the code.

那怎么可能 好吧，让我们分析错误和代码。

The first issue is that the continueButton.isEnabled property returns true since the beginning of the test. This is because we are accessing it as a staticText and not as a button. Static texts have no concept of being enabled or not, therefore the isEnabled property always returns true. First change to perform: change all the staticTexts into buttons.

第一个问题是自测试开始以来， continueButton.isEnabled属性返回true。 这是因为我们将其作为staticText而不是button来访问。 静态文本没有启用的概念，因此isEnabled属性始终返回true 。 要执行的第一个更改：将所有staticText更改为button 。

Let’s run the tests again and… another failure! The second set of asserts does not find the tosButton anymore! Don’t worry, there is a reasonable explanation. What happens to the button’s title when we tap the tosButton? What are we using to access the button dictionary? The tosButton.title properties changes when the button is tapped and we are using the original title to query the buttons dictionary.

让我们再次运行测试，……另一个失败！ 第二组断言不再找到tosButton ！ 不用担心，这里有一个合理的解释。 当我们点击tosButton时，按钮的标题会tosButton ？ 我们使用什么来访问button字典？ 点击按钮时， tosButton.title属性会更改，我们使用原始标题来查询按钮字典。

Luckily, we can overcome this issue by using theaccessibilityIdentifier. The Accessibility technology allows the iPhone to describe what’s on the screen to a user. UITests leverages the same technology to index the elements in a view. Thus, we just have to add lines 7 to 10 to the setup() method in the LegalView class:

幸运的是，我们可以使用accessibilityIdentifier解决此问题。 无障碍技术使iPhone可以向用户描述屏幕上的内容。 UITests利用相同的技术来索引视图中的元素。 因此，我们只需要在LegalView类的setup()方法中添加第7至10行：

Now that we have assigned an id to every button, we can use it to retrieve the proper UI elements.

现在我们已经为每个按钮分配了一个id ，我们可以使用它来检索适当的UI元素。

The last question you can have is how can we be sure that the app is correctly navigating to the right view? Well, by combining the accessibilityIdentifiers and the XCUIApplication.otherElements property, we can write a simple assert to verify that everything is working as we want. In fact, we can:

您可能要问的最后一个问题是，如何确定应用程序正确导航到正确的视图？ 好吧，通过将accessibilityIdentifiers和XCUIApplication.otherElements属性组合在一起，我们可以编写一个简单的断言来验证一切是否如我们所愿。 实际上，我们可以：

1. Add the "home_view” accessibility identifier to the blue view.

   将"home_view”可访问性标识符添加到蓝色视图。

2. Check that, after the navigation, there exists an element with that identifier.
   导航之后，检查是否存在具有该标识符的元素。

We can now press cmd+U to run the code and see that every assert passes. The final code, with the right assertions, looks like this:

现在，我们可以按cmd+U运行代码，并查看每个断言都通过了。 具有正确断言的最终代码如下所示：

There are many other things I’d like to add, but I’ll keep them for the next week. This article is already full of concepts and ideas that I feel we should take a break.

我还要添加许多其他内容，但下周将保留它们。 本文已经充满了我认为我们应该休息一下的概念和想法。

The code you’ll find online is slightly more advanced: remember that tests are as important as your business code and you need to take care of them. That’s why the code I prepared is better organized, with checks factored out and two different tests for the state changing logic and the navigation.

您将在网上找到的代码稍微高级一些：请记住，测试与您的业务代码同等重要，因此您需要加以注意。 这就是为什么我准备的代码井井有条，并排除了检查，并对状态更改逻辑和导航进行了两种不同的测试。

Next week I’d like to talk about best practices about writing UITests, how to start the app from a different state (e.g. if we want to run a UITest from a situation where the user already accepted Terms of Service and Privacy Policy) and how not to push in production code that is meant for the tests only.

下周，我想讨论有关编写UITest的最佳实践，如何从其他状态启动应用程序(例如，如果我们要在用户已接受服务条款和隐私权政策的情况下运行UITest)以及如何不要推送仅用于测试的生产代码。