You’ve built Pocket Budget over fourteen lessons. Now picture changing CategoryBudget next month to support rollover between months. How do you know the over-limit rule still works? You could tap through the app every time, or you could have the computer check it in a fraction of a second, on every change, forever. Then, once it works, you need real people using it on real phones before you trust it with an App Store launch.
Swift Testing is Apple’s testing framework, built into Xcode 16 and later. When you create a project, pick Swift Testing as its testing system and Xcode adds a test target; for an existing project, choose File › New › Target › Unit Testing Bundle and pick Swift Testing. Test the budget logic from the error-handling lesson:
\nimport Testing\n@testable import PocketBudget\n\nstruct CategoryBudgetTests {\n @Test func recordingAnExpenseIncreasesSpent() throws {\n var food = CategoryBudget(limit: 300)\n try food.record(title: \"Groceries\", amount: 64.2)\n #expect(food.spent == 64.2)\n #expect(food.limit - food.spent == 235.8)\n }\n\n @Test(\"Going over the limit throws and leaves the budget unchanged\")\n func overLimitThrows() throws {\n var food = CategoryBudget(limit: 50)\n try food.record(title: \"Lunch\", amount: 12)\n\n #expect(throws: BudgetError.overLimit(by: 7)) {\n try food.record(title: \"Dinner\", amount: 45)\n }\n #expect(food.spent == 12)\n }\n}@testable import gives the tests access to your app’s internal types. A test is any function marked @Test; the optional string is a readable name for the test navigator. Grouping tests in a struct makes it a suite, and each test gets a fresh instance, so tests can’t leak state into each other.
#expect takes an ordinary Swift expression. When it fails, the report includes the actual values, for example Expectation failed: (food.spent → 12) == 57, which usually tells you what went wrong before you open the debugger. #expect(throws:) passes only if the closure throws that exact error. That’s why BudgetError conforms to Equatable back in the error-handling lesson. Run everything with Cmd-U, or click the diamond next to a single test.
@Test func parsesValidAmount() throws {\n let amount = try #require(parseAmount(\"12.50\"))\n #expect(amount == 12.5)\n}\n\n@Test(arguments: [\"\", \"abc\", \"0\", \"-3\"])\nfunc rejectsInvalidAmounts(text: String) {\n #expect(parseAmount(text) == nil)\n}#require is #expect with a stop button: if the condition fails, the test ends right there. Given an optional, it unwraps it, so the rest of the test uses a real Decimal. Use it for preconditions; use #expect for the actual claims, so one run reports every broken claim, not just the first.
@Test(arguments:) runs the same test once per input and reports each case separately. Four bad inputs, one function, and the failure tells you exactly which input broke.
Start where bugs would hurt users and where tests are cheap: pure logic with no UI. In Pocket Budget that’s budget arithmetic, amount parsing, currency conversion and LoadState transitions. Those tests run in milliseconds and never flake. For code that needs SwiftData, create the in-memory container from the previous lesson inside the test, and mark the test @MainActor when it touches the main context. Leave pixel-level UI checks for later; previews catch most layout problems faster.
TestFlight is how you get a build onto other people’s iPhones before release. You need a paid Apple Developer Program membership and an app record in App Store Connect with the same bundle identifier as your project. Then:
\nTesters install the free TestFlight app, accept the invite and install your beta. They can send feedback with screenshots straight from the app, and you’ll find their reports, plus crash logs, in App Store Connect. Each build stays testable for 90 days.
\n\nThat’s the whole loop a professional iOS developer runs every week: model the data with types, build the screens in SwiftUI, fetch and store data safely under Swift 6’s concurrency checks, prove the logic with tests and put builds in testers’ hands. From here, good next steps are adding charts of spending by category with Swift Charts, syncing with iCloud through SwiftData, and preparing your App Store listing. You have the foundations for all of them.
\n","toc":[{"id":"sec-1","text":"Swift Testing in five minutes","level":2},{"id":"sec-2","text":"#require and parameterized tests","level":2},{"id":"sec-3","text":"What to test first","level":2},{"id":"sec-4","text":"Shipping a beta with TestFlight","level":2}],"takeaways":["Swift Testing tests are plain functions marked@Test; #expect checks a condition and reports the actual values when it fails.","#require stops a test early when a precondition fails, and also unwraps optionals so the rest of the test works with real values.","#expect(throws:) checks that code throws a specific error, and @Test(arguments:) runs one test for many inputs.","Test pure logic first, such as budgets, parsing and formatting, because it’s fast, stable and holds the rules users care about most.","TestFlight distributes builds to up to 100 internal testers without review, and up to 10,000 external testers after Beta App Review."],"further":[{"title":"Swift Testing","url":"https://developer.apple.com/documentation/testing"},{"title":"TestFlight","url":"https://developer.apple.com/testflight/"},{"title":"Distributing your app for beta testing and releases","url":"https://developer.apple.com/documentation/xcode/distributing-your-app-for-beta-testing-and-releases"}],"quiz":[{"q":"A test needs a parsed amount before it can check anything else, and parseAmount returns Decimal?. Which line fits best?
let amount = parseAmount("12.50")!","why":"A force unwrap crashes the whole test process on nil instead of failing one test with a clear message."},{"text":"let amount = try #require(parseAmount("12.50"))","why":"Correct. It unwraps the value, and if it’s nil the test stops there and is reported as failed."},{"text":"#expect(parseAmount("12.50") != nil), then use the optional.","why":"The test would carry on after a failure and every later line would have to deal with the optional."}],"answer":1},{"q":"#expect(food.spent == 57) fails. What does Swift Testing report?
#expect is recorded as an issue, so the test fails even though it keeps running."},{"text":"The expression with its actual value, such as (food.spent → 12) == 57.","why":"Correct. Seeing the real value usually tells you the bug without a debugger."}],"answer":2},{"q":"Who can install a TestFlight build without it going through Beta App Review?
","options":[{"text":"Internal testers, who are members of your App Store Connect team.","why":"Correct. Internal testing exists for fast iteration within the team."},{"text":"Anyone who opens your public link.","why":"Public links are for external testers, whose builds need Beta App Review first."},{"text":"External testers you invite by email.","why":"External testers, however they’re invited, need a build approved by Beta App Review."}],"answer":0}],"exercise":{"kind":"fill","language":"swift","template":"import Testing\n@testable import PocketBudget\n\nstruct ParsingTests {\n @{{0}} func parsesValidAmount() throws {\n let amount = try {{1}}(parseAmount(\"12.50\"))\n {{2}}(amount == 12.5)\n }\n\n @Test({{3}}: [\"\", \"abc\", \"0\", \"-3\"])\n func rejectsInvalidAmounts(text: String) {\n #expect(parseAmount(text) == nil)\n }\n}","blanks":[{"answers":["Test"]},{"answers":["#require"]},{"answers":["#expect"]},{"answers":["arguments"]}],"title":"Test the amount parser","prompt":"Write Swift Testing tests for parseAmount(_:), which returns a positive Decimal or nil. The first test must unwrap the parsed value and stop if it’s nil, then check it equals 12.5. The second test must run once for each invalid input.
nil; it’s used with try.","The other macro records a failure but lets the test continue. For the last blank, look at the parameter the second test receives."],"explanation":"@Test marks a test function. try #require(parseAmount("12.50")) unwraps the optional, and if parsing returned nil the test stops with a clear failure instead of crashing. #expect(amount == 12.5) then checks the result and, on failure, reports the actual value. @Test(arguments:) runs rejectsInvalidAmounts once per string, and each input shows up as its own test case, so a failure names the exact input that broke.
@Test func parsesValidAmount() throws {\n let amount = try #require(parseAmount(\"12.50\"))\n #expect(amount == 12.5)\n}