Hello there 👋🏻

Intro If you’re able to solve this, it means you understand TaskLocal really well. Riddle Look at the attached code snippet and guess: What will be printed at each step? Is the order of prints always the same? class Riddler { @TaskLocal static var message = "Hello" static func riddleMe() { Self.$message .withValue("Bye", operation: { print("Print 1: \(Self.message)") // ??? Task { print("Print 2: \(Self.message)") // ??? } Task.detached { print("Print 3: \(Self.message)") // ??? } }) print("Print 4: \(Self.message)") // ??? } } Riddler.riddleMe() Hint Do you want to learn more about TaskLocal and Test Scoping in Swift 6.1 first? - Check out my blog post on “Concurrency-Safe Testing in Swift 6.1 with TaskLocal and Test Scoping” HERE. ...

Today’s example shows a static property providing the current date. Perfect mechanism when we don’t want to inject it everywhere where it’s used. How to test it? Check it out ⤵️ Initial setup let currentDateFormatter: DateFormatter = { let formatter = DateFormatter() formatter.dateStyle = .short formatter.timeStyle = .none return formatter }() var currentDateFormatted: String { currentDateFormatter.string(from: DateEnvironment.currentDate()) } enum DateEnvironment { static var currentDate: () -> Date = Date.init } extension Date { // 16.04.2025 static let sixteenthOfApril = Date(timeIntervalSince1970: 1744840515) } Old way - XCTest Override the static property in tests. Works, but not concurrency-safe (Ok, for XCTest because test ran serially). class CurrentDateFormatterTests: XCTestCase { func test_dateFormatting() { // ✅ DateEnvironment.currentDate = { .sixteenthOfApril } XCTAssertEqual(currentDateFormatted, "16.04.2025") } } Swift Testing before Swift 6.1 enum DateEnvironment { @TaskLocal static var currentDate: () -> Date = Date.init } struct CurrentDateFormatterTests { @Test func dateFormatting() { // ✅ DateEnvironment.$currentDate .withValue({ .sixteenthOfApril }) { #expect(currentDateFormatted == "16.04.2025") } } } Why @TaskLocal? ...

Mind your argument names in Swift Testing’s parametrised tests! As a follow up to my recent post on refactoring to use Swift Testing’s parametrised tests, I’m diving into the crucial - yet often overlooked topic of how to name your parametrised test inputs. Option 1: First Named Tuples Only the first tuple is named, all others rely on positional matching to (a, b, result). ✅ Minimal boilerplate for small input sets ❌ Readability drops after adding more cases ❌ Easy to mix up arguments position ❌ Hard to scan or extend func add(_ a: Int, _ b: Int) -> Int { a + b } ... @Test(arguments: [ (a: 1, b: 2, result: 3), (10, 15, 25), (1, -5, -4), (-1, -5, -6), (0, 0, 0), (1000, 1000, 2000), (10000, 50000, 60000), (-10, -3, -13) ]) func add_returnsCorrectSum(a: Int, b: Int, result: Int) { #expect(add(a, b) == result) } Option 2: Named Tuples Every tuple entry explicitly names all its fields (a: …, b: …, result: …) for all cases. ...

Intro Have you already started using Swift Testing instead of XCTest? I’m curious to see how you can refactor the test function (add_returnsCorrectSum) from the code snippet to use all powers of the Swift Testing framework. Could you explain what benefits does your refactored version has compared to my original code snippet? My approach In both approaches the test gives the same result. The point is the refactored version uses a Swift Testing parametrised test, and this makes a real difference. ...

Swift code refactor in action 👨🏻‍💻 Take a close look at the validate function. There’s a sneaky problem hidden in this code snippet. What will the function call return when passed nil? What problem is hidden here? First, the guard statement is redundant here. We can simplify the function to ⤵️ func validate(password: String?) -> Bool { password?.count ?? 0 > 8 } There’s no need to wrap password?.count ?? 0 in parentheses since the ?? operator already has higher precedence than >. ...