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! 📚
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....
What’s the difference? XCTest doesn’t provide a built-in solution for parameterized tests. To achieve this, we create test cases as structs or tuples, defining test inputs and expected results. Then, we write a loop to iterate through these test cases and execute the necessary assertions. Swift Testing simplifies this process by allowing tests to be parameterized directly. Using the @Test macro, you can pass test cases as an argument. What’s the benefit?...
Swift code refactor in action 👨🏻💻 Today, let’s talk about refactoring for clarity, maintainability, and scalability! This time, the scenario is calculating the final price depending on the price and membership status. This initial code has a few code smells: 1️⃣ nested ifs - impacts general readability, making the code hard to understand, 2️⃣ duplicated conditions - “price > 100” which violates the Don’t Repeat Yourself principle, 3️⃣ lack of scalability - not possible to easily add a new discount, it’d require to rework everything....
Today we check the diff in conditional disabling. In XCTest there is XCTSkipIf function that takes Bool argument to decide whether a test should run or not. In Swift Testing there’s “disable” trait accepting Bool argument and behaving like XCTSkipIf from XCTest. XCTSkipIf - are you surprised this kind of function exists? To be honest - I was I can admit I learned about it when preparing this post. This already shows how often I’ll be using the Swift Testing version of it, but never say never!...
This week with Swift Testing starts with checking how test disabling differs from XCTest. In XCTest, Xcode identifies a function as a test only if its name starts with the “test” prefix, so putting e.g. “disabled” instead makes the test inactive. Swift Testing simplifies that approach by introducing the @Test macro with a .disabled trait that you can pass as an argument. What’s the benefit? You no longer need to modify each test name to disable it....