SpinDance

public class AcmeThingController {
  /// It's a singleton!
  static let shared = AcmeThingController()


  private init() {}


  // The ACME developers decided to conceal the inner workings of 
  // their devices and use a private type AcmeThing to represent 
  // them. This makes our job in this example a little easier, later 
  // on, since we don't have to create an abstraction around AcmeThing.
  private var things = [AcmeThing]()


  public func scanForAcmeThings() -> [String] {
    // Scan and initialize the private cache of things, and return 
    // the IDs.
    // things = ...
    return things.map { $0.acmeThingIdentifier }
  }


  // ACME's motto is "No regrets, Coyote": there's no turning back, 
  // you can arm but never disarm their devices.
  public func makeReadyToGoPow(acmeThingIdentifier: String) {
    // Find the specified device and do complex "ready to go pow" logic
    // ...
  }


  public func goPow(acmeThingIdentifier: String) {
    // Find the specified device and do complex "go pow" logic, then 
    // remove it since it is no more.
    // ...
    things = things.filter { $0.acmeThingIdentifier != acmeThingIdentifier }
  }
}

Just to get things working, he creates a quick and dirty view model class and a screen with a couple buttons and a list:

import AcmeSdk


class ViewModel {
  private(set) var deviceIds = [String]()


  func scanTapped() {
    deviceIds = AcmeThingController.shared.scanForAcmeThings()
  }


  func armDeviceTapped(selectedDeviceId: String) {
    AcmeThingController.shared.makeReadyToGoPow(
      acmeThingIdentifier: selectedDeviceId
    )
  }


  func explodeDeviceTapped(selectedDeviceId: String) {
    AcmeThingController.shared.goPow(acmeThingIdentifier: selectedDeviceId)
  }
}

OK, things are working, Road Runner used his proof of concept app to find, arm and explode one of his devices. All good, but at $100 a pop (pun intended), that was an expensive test! Time to tighten things up, and with his life depending upon his view model code working correctly and all, unit tests are a must. Being smart, he obviously knows he needs to create an abstraction around the ACME code and then depend upon the abstraction instead of the ACME code in his view model. He knows he can do this with Swift protocols; in fact he knows Swift protocols are his go-to method for “rolling his own” mocks. He knows his app might need to support other explosive device brands Wile E. Coyote is experimenting with, and he knows the ACME SDK is frequently updated with breaking changes. He also doesn’t like those silly names in the ACME code either, so he’s going to create a device API that’s a little more palatable and hides some of the inner workings of the “backend” code in his app. He wants to improve things with the following objectives in mind:

• Limit the code in his app that is dependent upon the ACME SDK (he has other screens up his sleeve that will also interact with the ACME SDK).
• Make his view model unit testable (he can’t mock the AcmeThingController singleton, therefore he can’t unit test the view model yet).
• Enable running his app on the iOS simulator (which doesn’t support BLE, which the ACME SDK depends upon.)
• Enable manually testing his app’s UI without having to go to the firing range and spend $100 per test.

He knows he needs to do the following:

• Create a Swift protocol that does what AcmeThingController does but with more sensible method names. He’ll call it DeviceController.
• Extend AcmeThingController so that it conforms to the DeviceController protocol. Note that this code is also not unit testable, and that’s why he’ll keep it “thin”.
• Make the view model dependent upon DeviceController instead of the ACME SDK and inject the AcmeThingController singleton into the view model.
• Create a “dummy” implementation of DeviceController that prints log statements instead of blowing things up. He can use an instance of this class when running on the simulator and to remove the requirement for having real devices present when he’s developing his UI.
• Create mock implementation(s) of DeviceController and inject them into his view model in unit tests as needed to achieve test objectives.

Here’s the abstraction he came up with. It maps pretty closely to what AcmeThingController does:

/// Abstracts interactions with explosive devices.
protocol DeviceController {
  func scanForDevices() -> [String]
  func arm(deviceId: String)
  func ignite(deviceId: String)
}

Now he needs to “hide” the ACME code behind that abstraction. In a Flutter app, he might create a class that implements DeviceController, but in Swift he can extend AcmeThingController to make it conform to (“look like”) a DeviceController. Then, wherever he needs a DeviceController, he can simply pass in the ACME singleton (or in Flutter, an instance of the class that implements DeviceController):

import AcmeSdk


/// AcmeThingController extension that adds DeviceController conformance.
extension AcmeThingController: DeviceController {
  func scanForDevices() -> [String] {
    scanForAcmeThings()
  }


  func arm(deviceId: String) {
    makeReadyToGoPow(acmeThingIdentifier: deviceId)
  }


  func ignite(deviceId: String) {
    goPow(acmeThingIdentifier: deviceId)
  }
}

Using the DeviceController abstraction now allows him to create another implementation that can be used on the iOS simulator, or while developing the UI at his desk:

/// DeviceController implementation that simply prints to the console
class SimulatedDeviceController: DeviceController {
  private let deviceIds = ["1", "2", "3"]


  func scanForDevices() -> [String] {
    deviceIds
  }


  func arm(deviceId: String) {
    print("Armed \(deviceId)")
  }


  func ignite(deviceId: String) {
    print("Ignited \(deviceId): POW!")
  }
}