Tagged with swift

• An Introduction to Swift Testing

  Swift Testing is the new framework for unit testing in Swift. It is shipped as the default in Xcode 16 (now in beta), and it looks great.

  Watch the session video from WWDC 2024 for the official intro from Apple.

  Swift Testing is an open source framework hosted on GitHub. You can read much more about it in the main project, and also in the Vision Document.

  The @Test Attribute

  There are four main building blocks in Swift Testing, and the first is the @Test attribute. In XCTest you needed a test prefix on your method name to tell the framework that this method is a test. The @Test attribute does that now, so your test function can have any name.

  A test can also now be global. In XCTest, tests had to belong to a subclass of XCTestCase. (Talking of which, we'll get to test suites soon.)

  import Testing
  
  @Test func myGlobalFunction() { // function name doesn't start with `test`
      #expect(true) // we'll get to this next
  }
  

  Expectations

  The second building block is Expectations. These are equivalent to assertions in XCTest, but while XCTest has lots of different assertions (XCTAssert, XCTAssertTrue, XCTAssertEqual, XCTAssertNotNil etc.), but Swift Testing has just two: #expect and #require.

  The #expect macro lets you specify any condition, using the standard Swift language features. If the condition evaluates to true, the test passes.

  The #require macro also validates a condition, but in this case, if the condition evaluates as false, the test will terminate immediately. #require also throws an exception, so you need to call it with try.

  One tool of XCTest that I use a lot is XCTUnwrap, to safely unwrap an optional, and fail the test if the optional can't be unwrapped. You can use #require the same way:

  let unwrappedValue = try #require(myOptionalValue)
  

  If the test fails, then not only will it fail, it will also generate an error message using the evaluated expression, to help you see why it failed. This is a huge difference from having to generate failure messages manually in XCTest.

  Traits

  The third building block of Swift Testing is Traits. Traits let you add details to a test, for example a display name, a bug ticket reference, or a condition under which the test should run (e.g. only in a certain language, or only when a certain feature flag is enabled).

  This example shows enabling a test only when a feature is enabled. (It's taken directly from the Swift Testing README.)

  @Test(.enabled(if: AppFeatures.isCommentingEnabled))
  func videoCommenting() async throws {
      let video = try #require(await videoLibrary.video(named: "A Beach"))
      #expect(video.comments.contains("So picturesque!"))
  }
  

  Tags

  You can also use Traits to organise tests into tags, and you can group tests by tag rather than suite or file in the Xcode sidebar. I love this idea for small projects that have a limited number of people working on them. I know it’ll be misused in bigger teams, with lots of different tags being semantically the same.

  Parameterised Tests

  It can be common to run one test multiple times, changing the parameters to test different conditions. Traits let you simplify that logic, by defining your arguments outside of the test. You can then see the different test runs in the sidebar in Xcode, and even re-run specific arguments, while only having one test defined.

  Here's an example, again taken from the Swift Testing README:

  @Test("Continents mentioned in videos", arguments: [
      "A Beach",
      "By the Lake",
      "Camping in the Woods"
  ])
  func mentionedContinents(videoName: String) async throws {
      let videoLibrary = try await VideoLibrary()
      let video = try #require(await videoLibrary.video(named: videoName))
      #expect(video.mentionedContinents.count <= 3)
  }
  

  This runs the test against three different videoName values: "A Beach", "By the Lake" and "Camping in the Woods". You'll see each of these in the sidebar as different tests, but you only need to write one @Test function.

  Test Suites

  Test Suites still exist, and they’re the fourth building block of Swift Testing. Instead of a subclass of XCTestCase, you can keep it really simple and embed your tests in a struct. That alone creates a Suite, implicitly.

  struct MyTests {
      @Test func myTest() {
          #expect(true)
      }
  }
  

  MyTests in the example above is a Test Suite. This is inferred from the presence of a @Test.

  You can also use the @Suite annotation. One reason why you might do that explicitly is to apply Traits that should be inherited by all tests. For example, if you apply a Tag to a Suite, that Tag applies to all tests in the Suite.

  Suites can be a struct, actor or class, but struct is encouraged. This means you get the benefit of value semantics; each test will get its own instance of the Suite. That means you don't risk sharing data between tests and corrupting the tests.

  One reason you may use choose to use a class or actor, however, is if you need a deinit method. In XCTest, you had setUp and tearDown, and multiple examples of each, depending on whether you wanted it to be run on a class or instance level, or if it should be async. There's only one init and deinit in Swift Testing, and deinit isn't available in structs.

  Wrap Up

  XCTest isn't going anywhere any time soon. You can take any migration slowly, and use both XCTest and Swift Testing in the same test target. And Apple explicitly mentions that XCTest is still required for performance and UI testing.

  But Swift Testing looks like a great improvement on unit testing, and I'm excited to try it out.
  

  ---

  
  If you liked this article, please consider buying me a coffee to support my writing.

  11 June 2024

  • wwdc24
  • swift
  • tests

• Formatting Years as Strings

  In date formatting, yyyy is not the same as YYYY.

  Apple’s Date Formatting document describes this:

  A common mistake is to use YYYY. yyyy specifies the calendar year whereas YYYY specifies the year (of “Week of Year”), used in the ISO year-week calendar. In most cases, yyyy and YYYY yield the same number, however they may be different. Typically you should use the calendar year.

  You can test Swift’s DateFormatter with 2016-01-01: YYYY will tell you it’s 2015, not 2016, because it’s a Friday, at the end of 2015 by the year-week calendar logic.

  If you’re working with date formatters, it’s a good idea to include 2016-01-01 in your unit tests, just to make sure you format the date as you expect.

  
  

  ---

  
  

  If you liked this article, please consider buying me a coffee to support my writing.

  27 April 2024

  • swift

• Combine's `print` operator

  This is a really useful little operator for debugging Combine code. It logs each event in your stream, and adds your given prefix to it as well. The example in Apple's docs) is a good one:

  let integers = (1...2)
  cancellable = integers.publisher
     .print("Logged a message", to: nil)
     .sink { _ in }
  
  // Prints:
  //  Logged a message: receive subscription: (1...2)
  //  Logged a message: request unlimited
  //  Logged a message: receive value: (1)  
  //  Logged a message: receive value: (2)
  //  Logged a message: receive finished
  

  Or you can really simplify it, because both properties are optional. The String is a prefix for the log statement, which is nice because it makes it easy to search your output and to get context if you have multiple Combine streams. But you don't need it. And the second parameter is an output stream, which is just the console by default.

  Here's how it looks when you just quickly want to throw a print in there:

  let integers = (1...2)
  cancellable = integers.publisher
     .print()
     .sink { _ in }
  
  // Prints:
  //  receive subscription: (1...2)
  //  request unlimited
  //  receive value: (1)
  //  receive value: (2)
  //  receive finished
  

  Aside: I've slightly changed the example from Apple's docs

  Amusingly, the commented output is slightly wrong on the docs. Clearly the range in the example was updated from 1..<2 to 1...2, because the first line of the output is wrong, and it's missing the second receive value line. A good example of what happens when you change the code and forget to update the docs!

  Here's the original. Notice the difference between the ranges in the code and the comment, and the missing second receive value line compared to my output:

  let integers = (1...2)
  cancellable = integers.publisher
     .print("Logged a message", to: nil)
     .sink { _ in }
  
  // Prints:
  //  Logged a message: receive subscription: (1..<2)
  //  Logged a message: request unlimited
  //  Logged a message: receive value: (1)
  //  Logged a message: receive finished
  

  
  

  ---

  
  

  If you liked this article, please consider buying me a coffee to support my writing.

  30 May 2023

  • tip
  • swift
  • combine

• Property Wrappers in Swift

  It's really easy to make a property wrapper in Swift to automatically modify a property.

  Here's an example, with tests to show how it works.

  @NonEmpty Example

  Say I want to ensure an optional String can't be empty - it's either nil, or it's got a value, but that value can't be "" (because then it's got the same meaning as nil, and I don't want to have to check both values when I'm using it). I can create a @NonEmpty property wrapper which makes sure a String matches that requirement.

  Usage in Code

  @NonEmpty var myString = "" // gets changed to `nil`
  @NonEmpty var myString = nil // keeps its value as `nil`
  @NonEmpty var myString = "Killie won the Championship in 2021/22" // 🏆 - keeps its original value
  

  The Code

  @propertyWrapper public struct NonEmpty {
      public var wrappedValue: String? {
          didSet {
              wrappedValue = getNonEmptyStringOrNil(from: wrappedValue)
          }
      }
  
      public init(wrappedValue: String?) {
          self.wrappedValue = getNonEmptyStringOrNil(from: wrappedValue)
      }
  
      private func getNonEmptyStringOrNil(from inputString: String?) -> String? {
          if let inputString = inputString, !inputString.isEmpty {
              return inputString
          } else {
              return nil
          }
      }
  }
  

  The Tests

  class NonEmptyPropertyWrapperTests: XCTestCase {
      func testNonEmpty_givenNilString_returnsNilString() {
          @NonEmpty var testString = nil
          XCTAssertNil(testString)
      }
  
      func testNonEmpty_givenEmptyString_returnsNilString() {
          @NonEmpty var testString = ""
          XCTAssertNil(testString)
      }
  
      func testNonEmpty_givenWhitespaceString_returnsOriginalString() {
          @NonEmpty var testString = " "
          XCTAssertEqual(testString, " ")
      }
  
      func testNonEmpty_givenNonEmptyString_returnsOriginalString() {
          @NonEmpty var testString = "Test"
          XCTAssertEqual(testString, "Test")
      }
  }
  

  Links

  There's usually a Swift By Sundell link for anything Swift-related and this is no different. Here's a great example of how to make a @Capitalized wrapper for a String, a generic @UserDefaultsBacked wrapper, and much more info on how it works:

  • Property wrappers in Swift
    

    ---

    
    If you liked this article, please consider buying me a coffee to support my writing.

  25 May 2022

  • swift

• Preparing for future minimum OS versions

  Let's say you have an app that supports iOS 13 and above. There will be some code that you can't use until iOS 14 is your minimum supported version. For example, using UIActions with UIButton is only available on iOS 14 and up; in iOS 13 you need to use the old target/action approach.

  To handle this, you might have alternative paths in your code. For example:

  if #available(iOS 14.0, *) {
      let button = UIButton(primaryAction: { _ in buttonPressed() })
  } else {
      let button = UIButton(type: .sytem)
      button.addTarget(self, action: #selector(buttonPressed), for: .touchUpInside)
  }
  
  

  When you update to using iOS 14 as your minimum OS version, you can delete the code in the else block, and delete the version check.

  Marking your own code as deprecated

  Writing code for the old and the new API can become complicated. Sometimes, it's just better to only use the old API, until your minimum OS version goes up.

  When you update your minimum version, you often get warnings from Apple's APIs stating that code has been deprecated. You can use the same approach, to remind yourself that you can use the new API now.

  To get a warning when you update the minimum OS version, you can add the @available annotation to your property, method or type:

  @available(iOS, deprecated: 14.0, message: "Replace this method with the new UIAction API.")
  func createAButtonUsingTargetAction() -> UIButton {
      let button = UIButton(type: .sytem)
  	button.addTarget(self, action: #selector(buttonPressed), for: .touchUpInside)
  	return button
  }
  

  This creates a warning when you compile with iOS 14 as your minimum OS version. That means you get a reminder to go back and update the old code, now that you can use the new API instead.

  
  

  ---

  
  

  If you liked this article, please consider buying me a coffee to support my writing.

  16 March 2022

  • swift