15.
Adding Features to Existing Classes
Written by Michael Katz
Heads up... You’re accessing parts of this content for free, with some sections shown as text.
Heads up... You’re accessing parts of this content for free, with some sections shown as text.
Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.
Unlock now
You won’t always have the time, or it may simply not be feasible, to break dependencies of a very large class. If you have a deadline to add a new feature and your app is a bowl of spaghetti, you won’t have the time to straighten it all out first. Fortunately, there are TDD techniques to tackle this situation.
In this chapter, you’ll learn strategies to add functionality to an existing class, while at the same time, avoiding modifying it! To do this, you’ll learn strategies like sprouts and dependency injection.
To demonstrate these ideas, you’ll add some basic analytics to the MyBiz app’s main view controllers. After all, every business wants to know what their users are doing.
Getting started
Use the back-end and starter projects from this chapter, as they have a few modifications from the last chapter that you’re going to need. Start up the back end. As always, refer back to Chapter 13, “Legacy Problems” if you need help getting it running.
Your objective is to add a screen to view analytics events for each of the five main view controllers: Announcements, Calendar, Org Chart, Purchase Orders and Settings. This way, the product owners will be able to identify the most-used screens, to figure out where to invest time and resources.
Reporting an analytics event involves:
- A user-initiated action, like a screen view or button tap.
- A
Reportthat contains the metadata for the event. - Sending that report to the back end.
Sending reports
It will be easiest, in this case, to start from the bottom up: Adding the ability to send reports to the back end. You already have a class that communicates with the back end, API. You’ll create an extension for this class to handle the new functionality while avoiding bloating the current file.
Laying a foundation
First things first, take what you learned in the previous chapter and start with a protocol to keep the dependencies clean and make the work easier to test.
protocol AnalyticsAPI {
}
import XCTest
@testable import MyBiz
class AnalyticsAPITests: XCTestCase {
var sut: AnalyticsAPI!
override func setUp() {
super.setUp()
}
override func tearDown() {
super.tearDown()
}
func testAPI_whenReportSent_thenReportIsSent() {
// given
let date = Date()
let interval: TimeInterval = 20.0
let report = Report(name: "name",
recordedDate: date,
type: "type",
duration: interval,
device: "device",
os: "os",
appVersion: "appVersion")
// when send a report?
// ???
// then assert a report was sent
// ???
}
}
Extending the API
The first step is to send the report. You already have a class that sends stuff to the back end: API. As you may have seen from previous chapters, this class is cumbersome and is interwoven with the rest of the app code. Ideally, you want to add new functionality to it without increasing its complexity or introducing new dependencies.
extension API: AnalyticsAPI {
}
var sut: AnalyticsAPI { return sutImplementation }
var sutImplementation: API!
override func setUp() {
super.setUp()
sutImplementation = API(server: "test")
}
override func tearDown() {
sutImplementation = nil
super.tearDown()
}
Sending a report
Now you can start thinking about that report.
func sendReport(report: Report)
func sendReport(report: Report) {
}
// when
sut.sendReport(report: report)
protocol RequestSender {
func send<T: Decodable>(request: URLRequest,
success: ((T) -> ())?,
failure: ((Error) -> ())?)
}
extension API: RequestSender {
func send<T>(request: URLRequest,
success: ((T) -> ())?,
failure: ((Error) -> ())?) where T : Decodable {
let task = loadTask(request: request,
success: success,
failure: failure)
task.resume()
}
}
lazy var sender: RequestSender = self
Testing the API
In the MyBizTests target, create a new group: Mocks. In that group, create a new file, MockSender.swift, and replace its contents with the following:
import XCTest
@testable import MyBiz
class MockSender: RequestSender {
var lastSent: Decodable? = nil
func send<T: Decodable>(request: URLRequest,
success: ((T) -> ())?,
failure: ((Error) -> ())?) {
let decoder = JSONDecoder()
decoder.dateDecodingStrategy = .iso8601
do {
let obj = try decoder.decode(T.self,
from: request.httpBody!)
lastSent = obj
success?(obj)
} catch {
print("error decoding a \(T.self): \(error)")
failure?(error)
}
}
}
var mockSender: MockSender!
mockSender = MockSender()
sutImplementation.sender = mockSender
mockSender = nil
// then
XCTAssertNotNil(mockSender.lastSent)
XCTAssertEqual(report.name, "name")
XCTAssertEqual((mockSender.lastSent as? Report)?.name, "name")
Sprouting the send method
API already has a method that takes an object and sends it to the back end: submitPO(po:). It’s too bad that this is specifically for sending purchase orders. You could refactor this method by mapping its dependencies, writing characterization and unit tests, and expanding the API functionality in a reusable way.
extension API {
// 1
func logAnalytics(analytics: Report,
completion: @escaping (Result<Report, Error>) -> ()) throws {
// 2
let url = URL(string: server + "api/analytics")!
var request = URLRequest(url: url)
if let token = token?.token {
let bearer = "Bearer \(token)"
request.addValue(bearer,
forHTTPHeaderField: "Authorization")
}
request.addValue("application/json",
forHTTPHeaderField: "Content-Type")
request.httpMethod = "POST"
let coder = JSONEncoder()
coder.dateEncodingStrategy = .iso8601
let data = try coder.encode(analytics)
request.httpBody = data
// 3
sender.send(
request: request,
success: { savedEvent in
completion(.success(savedEvent))
},
failure: { error in
completion(.failure(error))
})
}
}
try? logAnalytics(analytics: report) { _ in }
Adding analytics to the view controllers
The hard work is over, and the rest should be easy, right? If you think back to the list of steps for analytics, you still need to implement this part:
import XCTest
@testable import MyBiz
class AnnouncementsTableViewControllerTests: XCTestCase {
var sut: AnnouncementsTableViewController!
override func setUp() {
super.setUp()
sut = UIStoryboard(name: "Main", bundle: nil)
.instantiateViewController(withIdentifier:
"announcements")
as? AnnouncementsTableViewController
}
override func tearDown() {
sut = nil
super.tearDown()
}
func whenShown() {
sut.viewWillAppear(false)
}
func testController_whenShown_sendsAnalytics() {
// when
whenShown()
// then the report will be sent
// ???
}
}
Not mocking all of the API
You’ve already set up a protocol to help out with the testing: AnalyticsAPI. You don’t need to use API or mock out the RequestSender at all.
import XCTest
@testable import MyBiz
class MockAnalyticsAPI: AnalyticsAPI {
var reportSent = false
func sendReport(report: Report) {
reportSent = true
}
}
var mockAnalytics: MockAnalyticsAPI!
mockAnalytics = MockAnalyticsAPI()
sut.analytics = mockAnalytics
mockAnalytics = nil
XCTAssertTrue(mockAnalytics.reportSent)
var analytics: AnalyticsAPI?
let screenReport = Report(name: AnalyticsEvent.announcementsShown.rawValue,
recordedDate: Date(),
type: AnalyticsType.screenView.rawValue,
duration: nil,
device: UIDevice.current.model,
os: UIDevice.current.systemVersion,
appVersion: Bundle.main
.object(forInfoDictionaryKey:
"CFBundleShortVersionString")
as! String)
analytics?.sendReport(report: screenReport)
Another interesting use case
To implement the prior test, you set up a whole mock instance of AnalyticsAPI. You can use this for testing, without having to worry about the messiness that was previously built into MockAPI as a subclass of API. By using this protocol and starting with a mock implementation, you’ll ensure by default that any new methods you add to the app will be testable.
var reportCount = 0
reportCount = reportCount + 1
func testController_whenShownTwice_sendsTwoReports() {
// when
whenShown()
whenShown()
// then
XCTAssertEqual(mockAnalytics.reportCount, 2)
}
Passing around dependencies
The analytics feature now works in tests, but not when you run the app. That’s because you still need to pass AnalyticsAPI to the AnnouncementsTableViewController.
protocol ReportSending: AnyObject {
var analytics: AnalyticsAPI? {get set}
}
extension AnnouncementsTableViewController: ReportSending {}
self.userId = userId
let storyboard = UIStoryboard(name: "Main", bundle: nil)
let tabController = storyboard.instantiateViewController(
withIdentifier: "tabController") as! UITabBarController
tabController.viewControllers?
.compactMap { $0 as? ReportSending }
.forEach { $0.analytics = api }
window?.rootViewController = tabController
Adding more events
So you now have one screen sending reports. It should be straightforward to add reports to additional screens. For example, in OrgTableViewController.swift add the following var:
var analytics: AnalyticsAPI?
extension OrgTableViewController: ReportSending {}
import XCTest
@testable import MyBiz
class OrgTableViewControllerTests: XCTestCase {
var sut: OrgTableViewController!
var mockAnalytics: MockAnalyticsAPI!
override func setUp() {
super.setUp()
sut = UIStoryboard(name: "Main", bundle: nil)
.instantiateViewController(withIdentifier: "org")
as? OrgTableViewController
mockAnalytics = MockAnalyticsAPI()
sut.analytics = mockAnalytics
}
override func tearDown() {
sut = nil
mockAnalytics = nil
super.tearDown()
}
func whenShown() {
sut.viewWillAppear(false)
}
func testController_whenShown_sendsAnalytics() {
// when
whenShown()
// then
XCTAssertTrue(mockAnalytics.reportSent)
}
}
static func make(
event: AnalyticsEvent,
type: AnalyticsType) -> Report {
return Report(name: event.rawValue,
recordedDate: Date(),
type: type.rawValue,
duration: nil,
device: UIDevice.current.model,
os: UIDevice.current.systemVersion,
appVersion: Bundle.main
.object(forInfoDictionaryKey:
"CFBundleShortVersionString")
as! String)
}
let report = Report.make(event: .orgChartShown,
type: .screenView)
analytics?.sendReport(report: report)
Challenge
There are few tasks left undone that you should take care of:
Key points
- You don’t have to bring a whole class under test to add new functionality.
- You can sprout a method to extend functionality, even if it adds a little redundancy.
- Use protocols to inject dependencies and extensions to separate new code from legacy code.
- TDD methods will guide the way for clean and tested features.
Where to go from here?
Although you’ve come a long way, you’ve just scratched the surface of making changes and improving code. You can continue to decompose API into specific protocols like AnalyticsAPI and LoginAPI. You can also now incrementally improve API by replacing delegates with Results and using the RequestSender to make the code more testable.