Welcome to my blog about mobile applications development (mainly for Apple platforms).
➡️ Expect to read here about automated tests (unit, snapshot, UI), FRP, SwiftUI and many other topics that will improve your day to day coding. 🧑💻
➡️ I’m here not only to share, but also to learn. If you have any suggestion how I can improve my writting, feel free to reach me! 🤙
➡️ My name is Maciej and I’m going to be your guide through the world of mobile applications development. 🚀
📚 Enjoy the reading! 📚
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 >. ...
Paradigms Imperative In the imperative approach, we have a sequence of instructions that describe step by step how the program’s state is modified. Let’s look on the example ⤵️ var value = 0 func increment() { value += 1 // Mutating the state } print(value) // 0 increment() print(value) // 1 In the code we have a mutable variable value and a function increment that mutates the state (value). We first print the initial value, then increment it, and finally print the updated value. ...
What’s the difference? In XCTest we relied on the old fashioned simple comments to add more context to our test case e.g link to the bug description. With Swift Testing, we now have a special bug trait that can be passed to the @Test macro. The bug trait takes a URL String as argument and optionally a title for the bug allowing us to add short description of it. The key advantage over regular comment is that the bug title is visible in the test results. Better yet, tapping on it takes you directly to the related webpage with the bug report. ...