Validate Acceptance Criteria with UITests

To build an app that displays human viruses on the load of an app, business folks in cooperation with a development team write BBD Specs, the aim being to lay the groundwork for future acceptance testing.

Writing UI tests to validate the system’s compliance with business requirements can give a team necessary confidence to continue implementing the vision of the product, the only problem being that they can become a liability. The team has to justify their use.

Pictured as a pyramid, like a Maslow’s hierarchy of needs, the types of tests form three levels. Unit tests build the foundation, integration tests occupy the second level, finally at the top sit UI tests.

Validating high-level business acceptance criteria requires running an app, leading to the UI tests taking over 10 seconds per test. As a result, the total run time of UI test suite can highly likely exceed an hour. The figures show that the UI tests probably will be expensive to run. Now, the team faces a decision how to implement them.

A few tactics can the development team devise to mitigate the cost. First, the unit tests or integration tests might already cover some acceptance criteria, rendering necessary only a few UI tests critical to the business. Second, it is paramount to separate the UI tests from the everyday development workflow. The team can create a discrete test target, run it on demand or include it in the CI system. Third, the team can train QA engineers and delegate the tests.

The last option is viable as UI tests, called black box tests, operate without touching the internals of the system under test. Run separately from production code, the UI tests don’t access the classes like unit or integration tests do. As per Apple documentation, “UI testing gives you the ability to find and interact with the UI of your app to validate the properties and state of the UI elements.” In UI tests, one interacts with the app through the UI.

Let’s now illustrate a UI test by writing a sample BDD Specs and a test for the human viruses app.


BDD Specs

Story: User requests to see human virus types.

Narrative 1:
As an online user
I want the app to automatically display human virus types on the load of an app.

Given the user has connectivity
When the user requests to see human virus types
Then the app should display them from a remote server


Validation of the above requirements can look like the example below, assuming that mocked online state and data source display on the device screen four images contained within cells.

import XCTest
class AppUIAcceptanceTests: {
    func test_onLaunch_displayHumanVirusTypesWhenCustomerHasConnectivity() {
      let app = XCUIApplication()
      XCTAssertEqual(app.cells.count, 4)
      XCTAssertEqual(app.images.count, 4)

Sure enough, the test is passing, yet it can be improved. For one, in the scenario where the developers add new features, the app can display new types of cells. For another, depending on the screen size of the testing device, the app may load fewer images. Taking iPhone 5SE screen size as an example, it might fit two images or even only one image. 

Accessibility identifiers can uniquely identify an element in the scripts using the UI Automation interfaces. The team can assign them in storyboards or in code for possibly quicker access and maintenance. In the test code the matching(identifier:) method can find specific UI components:

import XCTest
class AppUIAcceptanceTests: {
    func test_onLaunch_displayHumanVirusTypesWhenCustomerHasConnectivity() {
      let app = XCUIApplication()
      let virusCells = app.cells.matching(identifier: "virus-cell")
      XCTAssertEqual(virusCells.count, 4)
      let firstImage = app.images.matching(identifier: "virus-image-view").firstMatch


Responsible for relentlessly improving the system design and processes to deliver high quality apps, the team can validate business requirements with UI tests. Beyond doubt, unit tests or integration tests take priority and often seem enough to continue implementing the vision of the product with confidence. That said, UI test seems to suit for high-level details hard to test with unit or integration tests.


Comment Rules: The goal is to be better at our craft. If you want to post code, insert it between the tags <code></code> Critical is fine, but if you’re rude, I'll delete your stuff. Please do not put your URL in the comment text and please use your PERSONAL name or initials and not your business name, as the latter comes off like spam. Have fun and thanks for adding to the converstaions!

Leave a Reply

Your email address will not be published. Required fields are marked *