測試中 (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)以及如何不要推送僅用于測試的生產代碼。