Posts

• How to exclude SwiftUI Previews From Code Coverage Percentage

  • Developer Tools
  • Swift
  • SwiftUI

  How to exclude SwiftUI Previews From Code Coverage Percentage

  TL;DR: Create a new scheme and compiler flag for your tests.

  THE PROBLEM:

  SwiftUI previews are great and can give you fantastic iteration speed when changing your app’s views. But what about the test coverage that gives you a high level of confidence to iterate quickly on your app itself? While you can test SwiftUI views by digging into their internals (not recommended as those tests may break in future SwiftUI versions) or with high level XCUI tests, you should not spend time unit testing SwiftUI previews because they’re not part of your app’s code.

  The fact that SwiftUI previews generally are defined inline in the file with the view is great for development speed, but starts to become a problem if you use Xcode’s code coverage reports to track and ensure that you’re maintaining a high level of test coverage for your project. SwiftUI Previews show up as uncovered code, and suddenly you no longer expect to see code coverage reported at or near 100% and it becomes easier to let code coverage slip for actual production code. Alternatively, you may waste time digging in to find what code is uncovered — and repeatedly find out that it’s just previews instead of “real” code.

  THE SOLUTION:

  Fortunately, there’s a solution and it’s quick and easy. We just have to create a new build configuration for our tests that does not build the previews. So we start of with something like this:

  

  Since this (relatively simple) app was created with TDD, the reported test coverage is relatively good, but deceptively low due to SwiftUI previews.

  To create a new configuration, go to the Info tab of your project settings and duplicate the Debug configuration.

  

  Believe it or not, you’re already almost done. Next, we need to add an active compilation condition (a compiler flag to go along with the new scheme.

  

  Now, set the new build configuration as the configuration for your tests:

  

  At this point, all you have left to do is surround your SwiftUI previews with the same #if DEBUG compiler directives that were the default when SwiftUI was brand new (back then, it was because the compiler wasn’t quite so good at optimizing them out of release builds). Alternatively, you could surround them with #if !TESTING. Either way, it’s important to make sure you have at least one application level test (like an XCUITest) that ensures you can’t use these compiler directives to exclude any production code without your test build failing.

  For example:

  #if DEBUG
  struct RestartOverlay_Previews: PreviewProvider {
      static var previews: some View {
          Group {
              RestartOverlay(gameEnd: .draw, restart: {})
                  .border(Color.orange, width: 2)
              RestartOverlay(gameEnd: .winner(.o), restart: {})
                  .border(Color.orange, width: 2)
              RestartOverlay(gameEnd: .winner(.x), restart: {})
                  .border(Color.orange, width: 2)
          }
      }
  }
  #endif
  

  Thanks for reading, I hope this was helpful and informative.

• Tip: How to avoid unexpected behavior when capturing Optionals

  • Tip
  • Swift
  • Laungage Features

  Tip: How to avoid unexpected behavior when capturing Optionals

  Swift's Optional type is one of the defining features of the language. Given the amount of language features and syntactic sugar that are built around Optional, it is easy to forget that there even is such a type.
  
  Normally, it's a good thing for a language feature to get out of your way. But when it comes to closure capture lists, it's important to remember that an optional is a value type regardless of what the wrapped type is.

  Consider the following example code:

  class ExampleViewController: UIViewController {
      weak var delegate: ExampleViewControllerDelegate?
  }
  

  It is easy to look at the above code and think of delegate as being an ExampleViewControllerDelegate which may or may not be present. But that thinking will lead you astray if you try to need to use an optional in a closure capture list. Expanding on the previous example (assuming it was executed in a Playground):

  class ExampleViewControllerDelegate {
      var delegateMethodCalled = false
      
      func delegateMethod() {
          delegateMethodCalled = true
      }
  }
  
  class ExampleViewController : UIViewController {
      weak var delegate: ExampleViewControllerDelegate?
      
      override func viewDidLoad() {
          viewDidLoad()
          URLSession.shared.dataTask(with: exampleURL) { [delegate] _, _, _ in
              delegate?.delegateMethod()
          }.resume()
      }
  }
  
  let vc = ExampleViewController()
  _ = vc.view
  let delegate = ExampleViewControllerDelegate()
  vc.delegate = delegate
  
  print(delegate.delegateMethodCalled)
  

  What do we suppose will happen when the code above executes? Surely the delegate will be set before the URLSession callback is called. So intuitively, we'd expect it to print true. But that's because we're thinking about delegate as a reference type when it's actually a value type.

  When the closure is created, delegate is nil so we actually capture the enum case Optional<ExampleViewControllerDelegate>.none. Since enums are value types, this will not get updated when the view controller's delegate gets set.

  The simplest way to avoid bugs like that would be to use an actual reference type in your capture lists if you're expecting the closure to have the latest value when it is called. In the case of your example, that would be:

       override func viewDidLoad() {
          viewDidLoad()
          URLSession.shared.dataTask(with: exampleURL) { [weak self] _, _, _ in
              self?.delegate?.delegateMethod()
          }.resume()
      }
  

• Tip: How To weakly reference self in protocol extensions that are not class-bound

  • Tip
  • Swift

  Tip: How To weakly reference self in protocol extensions that are not class-bound

  As any iOS developer can tell you, it's often important to use weak in closures to break refernce cycles and avoid memory leaks. Unfortunately, using weak is not always directly possible in protocol extensions that are not class-bound. Suppose you have a protocol for an API client to fetch some information:

  protocol APIClient {
      func fetchData() async throws -> Data
  }
  

  Unfortunately, not all of your code is ready to rely on async/await exclusively for concurrency so you may want to also expose a Combine compatible interface:

  protocol APIClient {
      func fetchData() async throws -> Data
      func fetchDataPublisher() -> Future<Data, Error>
  }
  

  At a glance, it's obvious these two protocol requirements are redundant and conforming types shouldn't have to provide two implementations to solve the same problem. We can solve this by providing a default implementation of the Combine interface:

  extension APIClient {
      func fetchDataPublisher() -> Future<Data, Error> {
          return Future { promise in
              Task {
                  do {
                      let data = try await fetchData()
                      promise(.success(data))
                  } catch {
                      promise(.failure(error))
                  }
              }
          }
      }
  }
  

  Unfortunately, the above may cause unexpected behavior. Even if implementations of APIClient choose to implement fetchData in a way that does not strongly reference self, the Combine compatible implementation will still retain self for the lifetime of the API call.

  Unfortunately, it's not possible to simply add [weak self] into the closure because we cannot guarantee that self is a reference type that can be referenced weakly. Instead we get a build error suggesting we limit the protocol to a class:

  'weak' must not be applied to non-class-bound 'Self'; consider adding a protocol conformance that has a class bound
  

  While this may be a perfectly good general solution, it's not a good solution here. There's no fundamental difference in the logic we want to use for reference types vs value types. So we need a workaround to weakly reference classes that won't cause errors value types.

  Fortunately, the solution is quite simple:

  struct WeakBox<T> {
      var object: T? {
          get { storage as? T }
          set { storage = newValue as AnyObject }
      }
      weak private var storage: AnyObject?
      
      init(_ stored: T) {
          self.object = stored
      }
  }
  

  WeakBox casts the stored value to AnyObject so we can always use reference semantics, even if the provided object is actually a value type. (We can unconditionally cast as AnyObject because of the some Objective C interoperability requirements.)
  
  Fortunately, the casting a value type as AnyObject does not cause it to be deallocated, as proved by the following pair of unit tests.

  final class WeakCaptureTests: XCTestCase {
      func test_doesNotRetainClass() throws {
          class Example {}
          let subject = WeakBox(Example())
          XCTAssertNil(subject.object)
      }
      
      func test_doesRetainStructs() throws {
          let subject = WeakBox(42)
          XCTAssertEqual(subject.object, 42)
      }
  }
  

  WeakBox allows us to appropriately leave the decision of whether or not to retain self up to implementations of APIClient rather than our default implementation without duplicating the implementation or restricting it to AnyObject:

  struct APIClientDeallocated: Error {}
  extension APIClient {
      func fetchDataPublisher() -> Future<Data, Error> {
          let weakReference = WeakBox(self)
          return Future {  promise in
              Task {
                  do {
                      guard let data = try await weakReference.object?.fetchData() else {
                          throw APIClientDeallocated()
                      }
                      promise(.success(data))
                  } catch {
                      promise(.failure(error))
                  }
              }
          }
      }
  }
  

  Hopefully this has been interesting and useful. Please feel free to reach out on LinkedIn if you have any questions or comments.