Unit Testing and Why it Matters

Vodafone Proprietary classified as C2 - Internal
Unit Testing
and Why it Matters
Yahya Saddiq
1 February 2020

2
Hello!
I am Yahya Saddiq, hands-on iOS Lead, _VOIS
at Vodafone.
A father of two, fitness enthusiast and coding
is my passion.
You can find me on LinkedIn.

The Beginning
2 February 20203
• Unit Testing is really important to anyone who is getting started in software
development, whether you’ve just discovered it, self teaching or going to school.
• Even if you’ve got yourself into new job, may be you haven’t been exposed to it yet
cause maybe your organization doesn’t do that.

The Beginning
2 February 20204
• It’s really important to learn it from the beginning cause you never know at what
point at your career or job interview ask you about unit testing and currently
that’s inevitable.
• It’s really important to have the conceptual ideas down your head and being able
to explain it to someone.
Unit Testing is Awesome
😎

What is Unit Testing?
2 February 20205

2 February 20206

2 February 20207
• Unit testing helps you to find failures and embarrassing mistakes from being
introduced into your production app
• Helps you have a software that actually works reliably.
• Unit Testing is a White Box testing

2 February 20208
• The purpose is to validate that each unit of the software code performs as
expected.
• Unit Testing is done during the development of an application by you (developers).
• Unit Tests isolate a section of code and verify its correctness.
• A unit may be an individual
– Function
– Method
– Procedure
– Module
– or Object.

Why We Should Do it?
2 February 20209
• We write unit tests, because we want our code to work and to keep it working.
• Unit tests are a great way to write better code.
• Tests help you find most of the bugs early on in the process.
• More importantly, writing code in a test-based development mindset helps you write
modular code that’s easy to maintain.
Easy to test code,
is easy to maintain and debug code.

2 February 202010
When it comes to testing, there’s good news, and bad news.
• The bad news is that there can be disadvantages to unit tests.
– More code
– More to maintain
– No silver bullet
– Takes longer

2 February 202011
Although there is no silver bullet, there is a silver lining.
• Testing has the following advantages
– Protection against regression
– Less coupled code
– Confidence
– Quick feedback
– Focus
– Refactoring
– Executable documentation
Maximizes laziness
😴

How The Process Works in Real Software
World?
2 February 202012

The 5 characteristics of Unit Testing
2 February 202013
•Fast.
•Independent/Isolated.
•Repeatable.
•Self-validating.
•Timely
Following the FIRST principles,
keeps your tests clear and helpful.

A simple gallery app
2 February 202014
We are going to test a simple app, in which:
– The app fetches popular photos from 500px API and lists photos in
a UITableView.
– Each cell in the table view shows a title, a description and the
created date of a photo.
– Users are not allowed to click photos which are not labeled
for_sale.

A simple gallery app
2 February 202015
• The first screen in the app is called PhotoListViewController,
and this is its the data flow.
• We are going to test:
1. Does APIService work and return valid photos?
2. Does photoListCellViewModel correctly created from a photo
object?
3. Does PhotoListViewModel fetch data from the APIService?
4. Does PhotoListViewModel display an error if the request failed?
5. Does PhotoListViewModel allow the segue if the user presses a “for
sale” photo?

The First Test Case
2 February 202016
Does photoListCellViewModel correctly created from a photo object?
• Create a test class for PhotoListViewModel.
• Let’s give the unit tests an access to the internal types and functions in
MVVMPlayground.
@testable import MVVMPlayground.
• Create a placeholder for a PhotoListViewModel, which is the System Under Test, or
the object this test case class is concerned with testing.
var sut: PhotoListViewModel!

Does photoListCellViewModel correctly
created from a photo object?
2 February 202017
• Create a PhotoListViewModel object at the class level, so all the tests in this test
class can access the SUT object’s properties and methods.
super.setUp()
sut = PhotoListViewModel()
• Before we forget, release the SUT object in tearDown().
sut = nil
super.tearDown()
• Setup and teardown prepare initial state before tests run and perform cleanup after
tests complete.

2 February 202018
// A test method’s name always begins with test, followed by a description of what it tests.
func test_cell_view_model() {
// It’s good practice to format the test into given, when and then sections
// Given: Here, you set up any values needed.
// In this example, today’s date and a dummy photo object are created.
let today = Date()
let photo = Photo(id: 1,
name: "Name",
description: "desc",
created_at: today,
image_url: "url",
for_sale: true,
camera: "camera")
// When: In this section, you’ll execute the code being tested: Call createCellViewModel(photo:).
let cellViewModel = sut!.createCellViewModel(photo: photo)
// Then: This is the section where you’ll assert the result you expect with a message that prints if the test fails.
XCTAssertEqual(cellViewModel.descText, "(photo.camera!) - (photo.description!)")
}

Debugging a Test
2 February 202019
• To cause a test failure, let’s change desc join character to +
• In the Breakpoint navigator, add a Test Failure Breakpoint.
– It will stop the test run when a test method posts a failure assertion.
• Run the test, and it should stop at the XCTAssertEqual line with a test failure.

Test Asynchronous Operations
2 February 202020
Does APIService work and return valid photos?
• URLSession methods are asynchronous:
– They return right away, but don’t finish running until later.
– use XCTestExpectation to make your test wait for the asynchronous
operation to complete.

2 February 202021
@testable import MVVMPlayground
class APIServiceTests: XCTestCase {
var sut: APIService!
override func setUp() {
super.setUp()
sut = APIService()
}
override func tearDown() {
sut = nil
super.tearDown()
}
}

2 February 202022
func test_fetch_popular_photos() {
// Given: Returns an XCTestExpectation object, stored in promise.
// The description parameter describes what you expect to happen.
let promise = XCTestExpectation(description: "Fetch popular photos
completed")
// When
sut.fetchPopularPhoto(complete: { (photos, error) in
// Then
guard error == nil,
let photos = photos else {
if let errorDesc = error?.rawValue {
XCTFail("Error: (errorDesc)")
}
return
}
XCTAssertEqual(photos.count, 20)
for photo in photos {
XCTAssertNotNil(photo.id)
}
// Call this in the success condition closure of the
asynchronous method’s completion handler to flag that the expectation
has been met.
promise.fulfill()
})
// Keeps the test running until all expectations are fulfilled, or
the timeout interval ends, whichever happens first.
wait(for: [promise], timeout: 3.1)
}

Fail Fast
2 February 202023
• Failure hurts, but it doesn’t have to
take forever.
• Let’s update the file name to test a
failure and run the test.
• Now, Let’s improve it and make the
test fail faster by changing the
assumption.
• Run the test. It should now take about
a second to fail.
func test_fetch_popular_photos_completes() {
// Given
let promise = XCTestExpectation(description: "Fetch popular
photos completed")
var responseError: Error?
var responsePhotos: [Photo]?
// When
sut.fetchPopularPhoto(complete: { (photos, error) in
responseError = error
responsePhotos = photos
promise.fulfill()
})
wait(for: [promise], timeout: 3.1)
// Then
XCTAssertNil(responseError)
XCTAssertEqual(responsePhotos?.count, 20)
}

Faking Objects and Interactions
2 February 202024
• Asynchronous tests give you confidence that your code generates correct input to
an asynchronous API.
• Most apps interact with system or library objects — objects you don’t control such
as Alamofire, NotificationCenter or UserDefaults. Tests that interact with these
objects can be slow and unrepeatable, violating two of the FIRST principles.
• Instead, you can fake the interactions by getting input from stubs or by
updating mock objects.
• We should mock all mentioned Black Boxes because unit testing is White Box
testing.

Mocking - Fake Update to Mock Object
2 February 202025
Does PhotoListViewModel fetch data from the APIService?
• We use a technique named Dependency Injection (DI) to design
our PhotoListViewModel.
• The property apiService is a dependency of the PhotoListViewModel.
• In the production environment we assign an APIService object, which connects to a
real server, to the PhotoListViewModel.
• In the test environment, we inject a mock APIService object instead.

Does PhotoListViewModel fetch data from
the APIService?
2 February 202026
@testable import MVVMPlayground
// The mock APIService (APIServiceMock) object doesn’t connect to the real server,
// it’s an object designed only for the test.
// Both APIService and APIServiceMock conform to APIServiceProtocol,
// so that we are able to inject different dependency in different situation.
class APIServiceMock: APIServiceProtocol {
var isFetchPopularPhotoCalled = false
func fetchPopularPhoto(complete: @escaping ([Photo]?, APIError?) -> ()) {
isFetchPopularPhotoCalled = true
}
}

the APIService?
2 February 202027
• Create an instance of the mock in PhotoListViewModelTests
var apiServiceMock: APIServiceMock!
apiServiceMock = APIServiceMock()
• Inject apiServiceMock to PhotoListViewModel
sut = PhotoListViewModel(apiService: apiServiceMock)
• Add the test case
func test_fetch_photo() {
// When
sut.initFetch()
// Then
XCTAssert(apiServiceMock.isFetchPopularPhotoCalled)
}

the APIService?
2 February 202028
• In addition to the behavior test, we also want to see if
the PhotoListViewModel correctly handles networking states.
• By using the DI technique, we are able to simulate the success and failure
networking states by changing the response of the MockAPIService.
• Let’s take a look at the PhotoListViewModel.initFetch():

Does PhotoListViewModel display an error if the request
failed?
2 February 202029
var completeClosure: (([Photo]?, APIError?) -> ())!
// the callback closure is saved to the completeClosure for the later use.
completeClosure = complete
}
// the function call is finished but the escaping closure is still pending.
//The closure won’t be triggered until the fetchSuccess() or the fetchFail(error:) is called.
// Finally, when we call the fetchSuccess() or the fetchFail(error:),
// the PhotoListViewModel receives the response data and continue to finish its jobs.
func fetchSuccess() {
completeClosure([Photo](), nil)
}
func fetchFail(error: APIError?) {
completeClosure(nil, error)
}
}

Does PhotoListViewModel display an error if the request
failed?
2 February 202030
func test_fetch_photo_fail() {
// Given
let error = APIError.permissionDenied
// When
sut.initFetch()
// here’s a trick: we ask the mock to fail the request by calling the fetchFail(error:) function.
apiServiceMock.fetchFail(error: error)
// Then
// assert the alert message of the PhotoListViewModel to see if it handles the error correctly.
XCTAssertEqual(sut.alertMessage, error.rawValue)
}

Stubbing - Fake Input From Stub
2 February 202031
Does PhotoListViewModel allow the segue if the user presses a “for sale” photo?
• The ViewModel receives the user interaction and changes the presentation with
respect to the interaction.
• In MVVM, the user interactions are abstracted into a set of methods such
as userPressed(), userSwipe(), etc.
• Therefore, testing the user interactions is straightforward: we call a certain method
and assert the corresponding property of the ViewModel.

Does PhotoListViewModel allow the segue if the user
presses a “for sale” photo?
2 February 202032
func test_user_press_for_sale_item() {
// Given
let indexPath = IndexPath(row: 0, section: 0)
// When
sut.userPressed(at: indexPath)
// Then
XCTAssertTrue(sut.isAllowSegue)
}

2 February 202033
// We create an array, completePhotos, to save the stubs.
// And those stubs will be returns to the PhotoListViewModel once the PhotoListViewModel calls
fetchPopularPhoto(complete:).
var completePhotos: [Photo] = [Photo]()
var completeClosure: (([Photo]?, APIError?) -> ())!
completeClosure = complete
}
func fetchSuccess() {
completeClosure(completePhotos, nil)
}
func fetchFail(error: APIError?) {
completeClosure(nil, error)
}
}

2 February 202034
func test_user_press_for_sale_item() {
// Given
let indexPath = IndexPath(row: 0, section: 0)
// The StubGenerator().stubPhotos() generates couple of photo objects.
// Then we assign the photo objects to the mockAPIService.completePhotos.
apiServiceMock.completePhotos = StubGenerator().stubPhotos()
sut.initFetch()
// When the request finished (mockAPIService.fetchSuccess() is called),
// the PhotoListViewModel will receive those photo stubs via the callback closure.
apiServiceMock.fetchSuccess()
// When
sut.userPressed(at: indexPath)
// Then
XCTAssertTrue(sut.isAllowSegue)
}

Code coverage
2 February 202035
• The code coverage tool tells you what app code is actually being run by your tests,
so you know what parts of the app code aren’t (yet) tested.
• To enable code coverage, edit the scheme’s Test action and check the Gather
coverage for check box under the Options tab.
• Run all tests (Command-U), then open the Report navigator (Command-9).
Select Coverage under the top item in that list:
• Research shows that 80% is best cost-efficient code coverage.

Do's and Don'ts
2 February 202036
• Verify One Concern Per Test Method
– A concern is a single end result: a return value or change to app state.
– if the first assert fails, does it matter what happens to the next one?
– If yes, you must split the test into smaller ones.
• Control Side-Effects
– When we change global app data from our test, this indirectly affects the whole test suite.
– To prevent this from happening you must cleanup before and after each test
• Do Not Leak Test Code into Production
– Firstly, do not weaken encapsulation for the purpose of testing.
– It’s either a flaw in the app design or you might be testing too much.
– Secondly, do not put logic into production code, only to support testing.
– Changes in your test code should not affect the production.

2 February 202037
Recap
• We used Unit Test to check:
– If APIService works and returns valid photos.
– If photoListCellViewModel correctly created from a photo object.
– If the SUT correctly interacts with the APIService.
– If the SUT handles the error state correctly.
– If the SUT handles the user interaction correctly.
• Now, you are able to use the knowledge you learned to write more test cases:
– The loading animation should start when the network request starts.
– The loading animation should stop when the request completes.
– The table view should render correctly.
– It should display error message when user press on the photo that is not for sale.

Unit Testing and Why it Matters

More Related Content

Similar to Unit Testing and Why it Matters (20)

Recently uploaded (20)

Unit Testing and Why it Matters

Editor's Notes