Comprehensive analysis of iOS unit testing and UI testing

【51CTO.com Quick Translation】Writing tests is not a glamorous job; however, since testing can prevent your baby app from becoming a big garbage dump full of errors, writing tests is a very necessary job. If you are reading this article, then you should already know that you should write tests for your code and user interface, but you are not sure how to write tests in Xcode.

[[186816]]

Maybe you've already developed a working application but haven't tested it yet; on the other hand, as you expand the application, you want to test any changes. Maybe you've written some tests but aren't sure they're the right tests. Or, you're currently developing your application and want to test it as you go along.

This tutorial will show you how to use the test navigator in Xcode to test your app's models and asynchronous methods, how to simulate interactions with library or system objects by using proxies and mocks, how to test user interfaces and performance, and how to use code coverage tools. As the article unfolds, you'll become familiar with some test-related terminology, and by the end of the article you'll be able to inject dependencies into your system under test (SUT) with ease!

Testing, testing…

What to test?

Before writing any tests, first ask the most basic question: What do you need to test? If your goal is to extend an existing application, then you should first write tests for any components you plan to change.

More generally, your tests should include the following:

• Core functionality: Model classes and methods and their interaction with controllers
• The most common UI workflows
• Boundary conditions
• Bug Fixes

The priority

The acronym FIRST describes a set of concise and effective unit testing standards. These standards are:

• Fast: Tests should run quickly so that people don't mind running them.
• Independent/Isolated: One test should not be setup or disassembled for another test.
• Repeatable: Each time you run the test, you should get the same results. Note that external data providers and concurrency issues may cause intermittent failures of the program.
• Self-validating: Tests should be fully automated; the output should be either "pass" or "fail" rather than providing the programmer with an explanatory log file.
• Timely: Ideally, you should write tests just before you write production code.

Following the FIRST principle above for testing will ensure that your tests are clear and useful, rather than becoming roadblocks in your application.

start

First, please download, unzip, open and observe the two initial sample projects BullsEye and HalfTunes provided in this article from https://koenig-media.raywenderlich.com/uploads/2016/12/Starters.zip.

Note that Project BullsEye is based on a sample app provided in the article https://www.raywenderlich.com/store/ios-apprentice. I have extracted the game logic into a BullsEyeGame class and added another game style accordingly.

A segmented controller component is provided in the lower right corner of the game for the user to select a game style: either Slide type, allowing the player to move the slider component to get as close to the target value as possible; or Type type, allowing the player to guess where the slider will reach. The corresponding action code of the control will also store the game style selected by the user as the default setting for that user.

Another sample project HalfTunes comes from another tutorial NSURLSession (https://www.raywenderlich.com/110458/nsurlsession-tutorial-getting-started), which has been updated to Swift 3. Users can use the iTunes API to query songs, then download and play the corresponding song clips.

Now, let’s start testing!

Unit Testing in Xcode

Creating a unit test target

The Test Navigator in Xcode provides the easiest way to test your app; you can use it to create test targets and run tests on your app.

Now, open the BullsEye project and press Command+5 to open its Test Navigator.

Then, click the + button at the bottom left; after that, select the “New Unit Test Target…” command from the menu as shown in the figure.

For this example, just use the default name BullsEyeTests. When the test package appears in the test navigator, click it to open it in the editor. If BullsEyeTests does not appear automatically, you can click in another navigator and then return to the current test navigator.

Notice that the template imports XCTest and defines a subclass of XCTestCase called BullsEyeTests, and provides a setup() method, a tearDown() method, and a system default example test method.

In summary, there are three ways to run test classes:

1. Use the command Product\Test or Command-U; this will run all test classes.

2. Use the arrow commands in the Test Navigator.

3. You can also click the diamond button on the left edge of the code.

Alternatively, you can run a single test method by clicking the diamond button in the test navigator or on the left margin of the code.

It is recommended that you try running the tests in different ways above to get a feel for how long it takes and what running the tests looks like. The current sample tests don't do anything, so they will run very quickly!

When all tests are successful, the diamond button will turn green and a check mark will be displayed on it. You can click the gray diamond button at the end of the testPerformanceExample() method to open the Performance Result window for observation, as shown in the figure below.

Now, we don't need the function testPerformanceExample(); so, just delete it.

Testing the Model with XCTAssert

First, you will use XCTAssert to test a core functionality of the BullsEye model: Can a BullsEyeGame object correctly calculate the score of a round?

To do this, add the following line of code to the file BullsEyeTests.swift, just below the import statements:

 @testable import BullsEye

This line of code enables the unit test to access the classes and methods in BullsEye.

Next, add the following property at the top of the BullsEyeTests class:

 var gameUnderTest: BullsEyeGame!

Then, in the setup() method, just below the call to the superclass, start a new BullsEyeGame object:

 gameUnderTest = BullsEyeGame() 
 
 gameUnderTest.startNewGame()

The above code will create a class-level SUT (System Under Test) object. This way, all tests in the test class can access the properties and methods of the SUT object.

Here, you also call the game's startNewGame method - this method simply creates a targetValue value. Many of your tests will use this targetValue value to test that the program can correctly calculate the score in the game.

Finally, remember to release your SUT object in the tearDown() method before calling the superclass:

 gameUnderTest = nil

【Note】A recommended testing practice is to create the SUT object in the setup() method and release it in the tearDown() method to ensure that each test corresponds to a thorough cleanup. For more detailed discussion, please refer to Jon Reid's post http://qualitycoding.org/teardown/.

Now you are ready to write your first test!

Please use the following code to replace the method testExample() in the project:

 // XCTAssert to test model
 func testScoreIsComputed() {
 // 1. given
  let guess = gameUnderTest.targetValue + 5 
  
 // 2. when  
  _ = gameUnderTest. check (guess: guess) 
  
 // 3. then  
  XCTAssertEqual(gameUnderTest.scoreRound, 95, "Score computed from guess is wrong" )
 }

The name of a test method always starts with test, followed by a description of what it tests.

A recommended approach is to format the test method into given, when and then parts:

1. In the given section, set any values ​​you want. In this example, you create a guess value so that you can specify how much it should differ from the targetValue value.

2. In the when section, execute the code under test—call the method gameUnderTest.check(_:) .

3. In the then section, assert the result you expect (in this case, the value of gameUnderTest.scoreRound is 100-5): if the test fails, print a corresponding message.

You can now run your tests by clicking the diamond icon button in the test navigator or to the left of your code. You will notice that the application will build and run, and finally the diamond icon will change to a green check mark!

[Note] To view a complete list of XCTestAssertions, you can press the Command key while clicking XCTAssertEqual in the code to open the file XCTestAssertions.h. In addition, you can also refer to the list of assertions provided by category provided by Apple's official website

(https://developer.apple.com/library/prerelease/content/documentation/DeveloperTools/Conceptual/testing_with_xcode/chapters/04-writing_tests.html#//apple_ref/doc/uid/TP40014132-CH4-SW35).

[[186817]]

In addition, the Given-When-Then structure in the above test comes from the easy-to-understand industry terminology in Behavior Driven Development (BDD). In fact, you can also use other naming systems, such as Arrange-Act-Assert and Assemble-Activate-Assert, etc.

Debugging a test

I have intentionally placed a bug in the BullsEyeGame project. Now let's test it to find it. To see the problem this bug causes, rename testScoreIsComputed to testScoreIsComputedWhenGuessGTTarget, then copy, paste, and edit it to create another method, testScoreIsComputedWhenGuessLTTarget.

In this test, the targetValue is subtracted by 5 in the given part, and the rest remain unchanged. See the following code for details:

 func testScoreIsComputedWhenGuessLTTarget() {
 // 1. given
  let guess = gameUnderTest.targetValue - 5 
  
 // 2. when  
  _ = gameUnderTest. check (guess: guess) 
  
 // 3. then  
  XCTAssertEqual(gameUnderTest.scoreRound, 95, "Score computed from guess is wrong" )
 }

Notice that the difference between the guess and targetValue is still 5, so the score should still be 95.

In the Breakpoint Navigator, add a Test Failure breakpoint; this will stop the test run when a test method issues a failing assertion.

Now run your test: it should stop at the XCTAssertEqual line and give you a test error.

You can then observe the output of gameUnderTest and guess in the debug console:

You should notice that the value of guess is -5, but the value of scoreRound is 105, not 95!

To analyze further, you can use the usual debugging process: set a breakpoint on the when statement, and also set a breakpoint in the BullsEyeGame.swift file—that is, in the check(_:) method within it. Then, run the test again and step-over the let statements to examine the different values ​​in the application.

The problem now is that the difference is a negative number; therefore, the score is 100-(-5). The solution is to use the absolute value of the difference. To do this, uncomment the correct code in the check(_:) method and delete the incorrect code.

Delete the two breakpoints set above and run the test again to confirm that the above line of code now passes successfully.

Testing asynchronous operations using XCTestExpectation

So far, you have learned how to test models and debug test failures. Next, let's move on to learning how to use XCTestExpectation to test network-related operations.

First, open the HalfTunes project. You'll notice that it uses URLSession to query the iTunes API and download song samples. Let's say you want to modify it to use AlamoFire for network operations. To see if anything breaks, you should write tests for the network operations and run them before and after changing the code.

URLSession methods are executed asynchronously: they return immediately, but do not actually complete until they have run for a while. To test asynchronous methods, you should use XCTestExpectation to make your test wait for the asynchronous operation to complete.

It's worth noting that asynchronous tests are generally slow, so you should separate them from your other faster-running unit tests.

Select and run the command "New Unit Test Target..." from the menu under "+", and name the target HalfTunesSlowTests. Then, import the HalfTunes program below the import statement:

 @testable import HalfTunes

All tests in this class will use the default session to send requests to Apple's servers. Therefore, we declare and create a sessionUnderTest object in the setup() method, and then release it in the tearDown() method:

 var sessionUnderTest: URLSession!
 override func setUp() {
 super.setUp()
  sessionUnderTest = URLSession(configuration: URLSessionConfiguration.default )
 }
 override func tearDown() {
 sessionUnderTest = nil
 super.tearDown()
 }

Next, replace your asynchronous test with the TestExample() function:

 //Asynchronous testing: Successful tests are fast, but failed tests are slow
 func testValidCallToiTunesGetsHTTPStatusCode200() {
 // given
  let url = URL(string: "https://itunes.apple.com/search?media=music&entity=song&term=abba" )
 // 1
  let promise = expectation(description: "Status code: 200" ) 
  
 // when  
  let dataTask = sessionUnderTest.dataTask( with : url!) { data, response, error in  
 // then  
 if let error = error {
      XCTFail( "Error: \(error.localizedDescription)" )
 return  
    } else if let statusCode = (response as ? HTTPURLResponse)?.statusCode {
 if statusCode == 200 {
 // 2
 promise.fulfill()
 } else {
        XCTFail( "Status code: \(statusCode)" )
 }
 }
 }
 dataTask.resume()
 // 3
  waitForExpectations(timeout: 5, handler: nil)
 }

The purpose of the test above is to check that a valid query sent to iTunes returns a status code of 200. Obviously, most of the code is the same as what you wrote in the application above, with the following additions:

1. expectation(_:) returns an XCTestExpectation object; this object is stored in the variable promise. Other common names for this object are expectation and future. In addition, the description parameter describes what you expect to happen.

2. In order to match the description parameter, you need to call promise.fulfill() in the success condition closure of the asynchronous method's completion handler.

3.waitForExpectations(_:handler:) keeps all tests running until all expectations are met or the time interval specified by the timeout value expires—whichever happens first.

Now, run the test again. If you are connected to the Internet, it should take about a second for the test to succeed once the app loads in the simulator.

Make the test fail faster

A failed test can cause a lot of problems, but it doesn’t have to be a big deal. Now, let’s tackle the problem of how to quickly determine if your tests are failing.

To modify your test to fail on asynchronous operations, just remove the s after the word "itunes" from the following URL:

 let url = URL(string: "https://itune.apple.com/search?media=music&entity=song&term=abba" )

When you run the above test: it will fail, and the test will take the entire specified timeout interval! This is because the expectation is that the request will succeed - this is where the promise.fulfill() method is called. Since the request failed, the test will only end if the specified timeout is exceeded.

You can make this test fail sooner by changing its expectation: instead of waiting for the request to succeed, wait until the asynchronous method's completion handler fires. This will happen as soon as the application receives a response from the server (either success or failure); however, this is expected. Your test can then check whether the request succeeded.

To see how this works, you'll create a new test. First, fix this test - this can be easily done by undoing the url change above, then add the following test to your class:

 // Asynchronous test: faster fail
 func testCallToiTunesCompletes() {
 // given
  let url = URL(string: "https://itune.apple.com/search?media=music&entity=song&term=abba" )
 // 1
  let promise = expectation(description: "Completion handler invoked" )
 var statusCode: Int ?
 var responseError: Error? 
  
 // when  
  let dataTask = sessionUnderTest.dataTask( with : url!) { data, response, error in  
    statusCode = (response as ? HTTPURLResponse)?.statusCode
 responseError = error
 // 2
 promise.fulfill()
 }
 dataTask.resume()
 // 3
  waitForExpectations(timeout: 5, handler: nil) 
  
 // then  
 XCTAssertNil(responseError)
  XCTAssertEqual(statusCode, 200)
 }

The most critical point in the code above is that the expectation is only entered for the completion handler to be fulfilled - this takes about a second to happen. If the request fails, then the assertion will also fail.

Now run the above test again: it will now take about a second to fail; it fails because the request failed, not because the test run timed out.

Fix the URL above and run the test again to confirm that it now passes successfully.

Faking objects and interactions

Asynchronous tests can give you confidence that your code provides the correct input to an asynchronous API. You may also want to test that your code works correctly when it receives input from URLSession, or when it correctly updates UserDefaults or a CloudKit database.

Most applications interact with system or library objects (which you do not control), and testing interactions with these objects is likely to be extremely slow and non-repeatable - violating two of the FIRST principles at the beginning of the article. Instead, you can fake these interactions - by getting input from a stub or updating a mock object.

When your code depends on an object in a system or library, you can use the fake method above to create a fake object to implement that part of the functionality and inject this fake into your code. Jon Reed's Dependency Injection Technology article (https://www.objc.io/issues/15-testing/dependency-injection/) introduces several ways to achieve this goal.

[[186818]]

Faking input from a stub

In the test in this section, you’ll check that the application’s updateSearchResults(_:) method correctly parses the data downloaded by the session—by checking that the value of the property searchResults.count is correct. The SUT is the view controller; you’ll use a stub technique to fake a session and some pre-downloaded data.

To do this, select the command "New Unit Test Target..." from the "+" menu and name it HalfTunesFakeTests. Then, import the HalfTunes program below the import statement:

 @testable import HalfTunes

Next, declare the SUT, create it in the setup() method, and release it in the tearDown() method:

 var controllerUnderTest: SearchViewController! 
  
 override func setUp() {
 super.setUp()
  controllerUnderTest = UIStoryboard( name : "Main" ,
      bundle: nil).instantiateInitialViewController() as ! SearchViewController!
 } 
  
 override func tearDown() {
 controllerUnderTest = nil
 super.tearDown()
 }

Note: The SUT (system under test) is the view controller, because HalfTunes has a lot of view controller issues - all the work is done in the file searchviewcontroller.swift. "Move the network code to a separate module" (see the article http://williamboles.me/networking-with-nsoperation-as-your-wingman/) will reduce this problem and make testing easier.

Next, you'll need some sample JSON data for your fake session to provide to your tests. It only takes a little work; so limit your downloads from iTunes by adding a limit string &limit=3 to the end of the URL string:

https://itunes.apple.com/search?media=music&entity=song&term=abba&limit=3

Copy this URL and paste it into your browser. This will download a file called 1.txt or something similar. You can preview it to confirm that it is a JSON file, then rename it to abbaData.json and add it to the HalfTunesFakeTests group.

The HalfTunes project includes a supporting file, DHURLSessionMock.swift. This file defines a simple protocol, DHURLSession, which provides methods (delegates) for creating a data task using a URL or URLRequest. It also defines a URLSessionMock object that conforms to the protocol, and provides initializers that allow you to create a mock URLSession object using the data, response, and error of your choice.

Now, let's build fake data and responses and create a fake session object; this is all done in the setup() method, after the statement that creates the SUT object:

 let testBundle = Bundle( for : type( of : self))
 let path = testBundle.path(forResource: "abbaData" , ofType: "json" )
 let data = try? Data(contentsOf: URL(fileURLWithPath: path!), options: .alwaysMapped) 
  
 let url = URL(string: "https://itunes.apple.com/search?media=music&entity=song&term=abba" )
 let urlResponse = HTTPURLResponse(url: url!, statusCode: 200, httpVersion: nil, headerFields: nil) 
  
 let sessionMock = URLSessionMock(data: data, response: urlResponse, error: nil)
 At the end   of setup(), inject the fake session into the app as a property of the SUT: 
 
 controllerUnderTest.defaultSession = sessionMock

Note: You will use the fake session directly in your tests, but this will show you how to inject such a fake session; that way, your further tests can call SUT methods that use the view controller’s defaultSession property.

Now you can write a test to check whether calling the updateSearchResults(_:) method can resolve the fake data. To do this, replace the TestExample() method with the following:

 //Use DHURLSession protocol and proxy to forge URLSession
 func test_UpdateSearchResults_ParsesData() {
 // given
  let promise = expectation(description: "Status code: 200" ) 
  
 // when  
  XCTAssertEqual(controllerUnderTest?.searchResults. count , 0, "searchResults should be empty before the data task runs" )
  let url = URL(string: "https://itunes.apple.com/search?media=music&entity=song&term=abba" )
  let dataTask = controllerUnderTest?.defaultSession.dataTask( with : url!) {
 data, response, error in  
    // if HTTP request is successful, call updateSearchResults(_:) which parses the response data into Tracks
 if let error = error {
      print(error.localizedDescription)
    } else if let httpResponse = response as ? HTTPURLResponse {
      if httpResponse.statusCode == 200 {
 promise.fulfill()
        self.controllerUnderTest?.updateSearchResults(data)
 }
 }
 }
 dataTask?.resume()
  waitForExpectations(timeout: 5, handler: nil) 
  
 // then  
  XCTAssertEqual(controllerUnderTest?.searchResults. count , 3, "Didn't parse 3 items from fake response" )
 }

Note that you still have to write this test in an asynchronous manner because the proxy (stub) pretends to be an asynchronous method.

In the code above, the when assertion says that the value of searchResults should be empty before the data task runs - which should be true because you created a brand new SUT in the setup() method.

The fake data contains the JSON data provided to the three Track objects; therefore, the then assertion is that the view controller's searchResults array should contain three items.

Run the test again. This time it should succeed, and be fast, since there's no real network connection!

Faking updates to mock objects

The previous test used a proxy to provide input from a fake object. Next, you can use a mock object to test that your code can correctly update UserDefaults.

Reopen the BullsEye project. Notice that the app offers two game styles: the user can choose to move the slider to match the target value or guess the target value from the slider position. The segmented control switch in the lower right corner of the interface can be used to switch game styles and update the user's default game style.

The next test you'll write will check that the application correctly updates the user's default game style data.

In the test navigator, click the command "New Unit Test Target..." and name it BullsEyeMockTests. Then, add the following below the import statements:

 @testable import BullsEye 
  
 class MockUserDefaults: UserDefaults {
 var gameStyleChanged = 0
  override func set (_ value: Int , forKey defaultName: String) {
    if defaultName == "gameStyle" {
 gameStyleChanged += 1
 }
 }
 }

Notice that the MockUserDefaults class above overrides the set(_:forKey:) method to increment the gameStyleChanged flag by 1. Typically you’d see similar tests setting a Boolean variable, but here we’re incrementing an integer value, which gives you more control—for example, your test could check that the method was called exactly once.

Declare the SUT object and the mock object in the BullsEyeMockTests class:

 var controllerUnderTest: ViewController!
 var mockUserDefaults: MockUserDefaults!

In the setup() method, create the SUT object and the mock object, and then inject the mock object as a property of the SUT:

 controllerUnderTest = UIStoryboard( name : "Main" , bundle: nil).instantiateInitialViewController() as ! ViewController!
 mockUserDefaults = MockUserDefaults(suiteName: "testing" )!
 controllerUnderTest.defaults = mockUserDefaults
 Release the SUT and the mock object in tearDown():
 controllerUnderTest = nil
 mockUserDefaults = nil
 Replace testExample() with this:
 // Mock to test interaction with UserDefaults
 func testGameStyleCanBeChanged() {
 // given
  let segmentedControl = UISegmentedControl() 
  
 // when  
  XCTAssertEqual(mockUserDefaults.gameStyleChanged, 0, "gameStyleChanged should be 0 before sendActions" )
  segmentedControl.addTarget(controllerUnderTest,
 action : #selector(ViewController.chooseGameStyle(_:)), for : .valueChanged)
  segmentedControl.sendActions( for : .valueChanged) 
  
 // then  
  XCTAssertEqual(mockUserDefaults.gameStyleChanged, 1, "gameStyle user default wasn't changed" )
 }

The when assertion in the code above means that the gameStyleChanged flag is 0 before the test method triggers the segment control switch. Therefore, if the then assertion is also true, it means that the method set(_:forKey:) is called correctly only once.

Now run the test again; it should succeed.

UI Testing in Xcode

Xcode 7 introduces support for UI testing, which allows you to create UI tests by recording interactions with the UI. UI testing works by finding an application's UI objects through queries, synthesizing events, and then sending these events to these objects. The APIs provided allow you to inspect the properties and states of a user interface object to compare them with the expected state.

Now, let's add a new UI test target in the BullsEye project's test navigator. Make sure the target to be tested is BullsEye, and accept the default name BullsEyeUITests.

Then, add the following property at the top of the BullsEyeUITests class:

 var app: XCUIApplication!

In the setup() method, replace the XCUIApplication().launch() statement with the following code:

 app = XCUIApplication() 
 
 app.launch()

Change the name of testExample() to testGameStyleSwitch().

Then, press Enter to create a new empty line in testGameStyleSwitch() and click the red Record button at the bottom of the editor window, as shown.

When the app appears in the simulator, click the slider that controls the game style switch and the top label. Then, click the Record button in Xcode to stop recording.

You now have the following three lines of code in the method testGameStyleSwitch():

 let app = XCUIApplication() 
 
 app.buttons[ "Slide" ].tap() 
 
 app.staticTexts[ "Get as close as you can to: " ].tap()

If there are other statements, delete them.

The first line of code copies the properties you created in the setup() method; since you don't need to click anything yet, delete this first line as well, and also delete the ".tap()" at the end of lines 2 and 3. Open the small menu next to ["Slide"] and select segmentedControls.buttons["Slide"].

So, you have the following code:

 app.segmentedControls.buttons[ "Slide" ] 
 
 app.staticTexts[ "Get as close as you can to: " ]

Modify the above code further to create the given part of the test:

 // given 
 
 let slideButton = app.segmentedControls.buttons[ "Slide" ] 
 
 let typeButton = app.segmentedControls.buttons[ "Type" ] 
 
 let slideLabel = app.staticTexts[ "Get as close as you can to: " ] 
 
 let typeLabel = app.staticTexts[ "Guess where the slider is: " ]

Now that you have two buttons and two possible top label names, add the following:

 // then   
 
 if slideButton.isSelected { 
 
 XCTAssertTrue(slideLabel.exists) 
 
 XCTAssertFalse(typeLabel.exists) 
 
 typeButton.tap() 
 
 XCTAssertTrue(typeLabel.exists) 
 
 XCTAssertFalse(slideLabel.exists) 
 
 } else if typeButton.isSelected { 
 
 XCTAssertTrue(typeLabel.exists) 
 
 XCTAssertFalse(slideLabel.exists) 
 
 slideButton.tap() 
 
 XCTAssertTrue(slideLabel.exists) 
 
 XCTAssertFalse(typeLabel.exists) 
 
 }

This code will check if the correct label exists for each button when it is selected or clicked. Now, run the test - all assertions should succeed.

Performance Testing

According to Apple's official documentation

(https://developer.apple.com/library/prerelease/content/documentation/DeveloperTools/Conceptual/testing_with_xcode/chapters/04-writing_tests.html#//apple_ref/doc/uid/TP40014132-CH4-SW8) Description: A performance test takes a block of code that you want to evaluate and runs it 10 times, collecting the average execution time and the standard deviation of the runs. The average of these individual measurements becomes a value for the test run, which is then compared to a baseline value to evaluate success or failure.

Writing a performance test is pretty straightforward: you just put the code you want to test inside the closure of the measure() method.

To see this in action, reopen the HalfTunes project and use the following test in the HalfTunesFakeTests class, replacing the default generated testPerformanceExample() method:

 // Performance
 func test_StartDownload_Performance() {
  let track = Track( name : "Waterloo" , artist: "ABBA" ,
      previewUrl: "http://a821.phobos.apple.com/us/r30/Music/d7/ba/ce/mzm.vsyjlsff.aac.p.m4a" )
 measure {
    self.controllerUnderTest?.startDownload(track)
 }
 }

Now, run the test above and click the icon at the end of the measure() closure to watch the statistics.

Click the Set Baseline button, then run the performance test again and view the results - the results may be better or worse than the baseline. You can click the Edit button to help you reset the baseline to this new result.

Benchmark values ​​are stored per device configuration, so you can have the same test run on several different devices and have each device maintain a different benchmark value - depending on its specific configuration of processor speed, memory, etc.

Any time you make a change to an application that might affect the performance of the method you are testing, you can run the performance test again to see how the current values ​​compare to the baseline.

Code Coverage

Code coverage tools can tell you which code in your application has actually been exercised by your tests; this way, you can know which parts of the application code have not been tested.

Note: Should you run performance tests with code coverage enabled? Apple's documentation (https://developer.apple.com/library/prerelease/content/documentation/DeveloperTools/Conceptual/testing_with_xcode/chapters/07-code_coverage.html#//apple_ref/doc/uid/TP40014132-CH15-SW1) describes it this way: Code coverage data collection can cause performance degradation... in a linear manner to the execution of the code; therefore, the performance of the program will vary from test to test run when code coverage is enabled. However, you should seriously consider whether to enable code coverage support when you have extremely strict requirements for the routines in your tests.

To enable code coverage, you can edit your pre-planned Test action and check the "Code Coverage" checkbox:

Run all your tests (Command+U) and open the report navigator (Command+8). Select the top item in the By Time list (see the image below) and then select the Coverage tab.

You can click the expand triangle icon as shown below to view the list of functions in the SearchViewController.swift file:

You can hover over the blue Coverage bar near the updateSearchResults(_:) method and observe the corresponding coverage of 71.88%.

Click the arrow buttons corresponding to the function to open the source file and locate the function. When your mouse moves over the coverage comment in the right bar, the code snippet will be highlighted in green or red:

The information on the coverage comment shows how many times each segment was hit in a test. Note that the section of the segment that was not called is highlighted in red. As you would expect, the for loop runs 3 times, but none was executed along the wrong path. To improve the code coverage of this function, you can copy abbaData.json and modify it so that it causes different errors - for example, change "results" to "result" to test the execution to the print statement print("Results key not found in dictionary").

100% coverage?

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

Summarize

This article has provided you with a variety of tools for writing tests for your iOS project. I hope you can build enough confidence to test everything through the study of this tutorial!

You can download the complete sample project source code in this article from the address https://koenig-media.raywenderlich.com/uploads/2016/12/Finished-3.zip.

Finally, the following resources are available for you to use for further study and test:

• : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
• Use Swift Playgrounds for test-driven development (http://initwithstyle.net/2015/11/tdd-in-swift-playgrounds/). You can use XCTestObservationCenter to run XCTestCase unit tests in the Playgrounds environment. You can develop your engineering code and test it in Playgrounds, and then convert both into your application.
• Tutorial from the CMD+U Association (http://www.cmduconf.com/) shows you how to use PivotalCoreKit (https://github.com/pivotal/PivotalCoreKit) to test watchOS applications.
• If you have written an application and just haven't written a test for it, you can refer to Michael Feathers' book "Working Effectively with Legacy Code" (https://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052/ref=sr_1_1?s=books&ie=UTF8&qid=1481511568&sr=1-1), because code that does not include tests is often left over!
• Jon Reid's high-quality coding sample programming article (http://qualitycoding.org/tdd-sample-archives/) is also a great place for you to learn test-driven development.

[Translated by 51CTO. Please indicate the original translator and source as 51CTO.com when reprinting on partner sites]