{"id":47157,"date":"2025-03-21T16:17:58","date_gmt":"2025-03-21T20:17:58","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=47157"},"modified":"2025-07-14T13:46:01","modified_gmt":"2025-07-14T17:46:01","slug":"swift-testing-proposal-exit-tests","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2025\/03\/21\/swift-testing-proposal-exit-tests\/","title":{"rendered":"Swift Testing Proposal: Exit Tests"},"content":{"rendered":"

ST-0008<\/a>:<\/p>\n

\n

One of the first enhancement requests we received for Swift Testing was the ability to test for precondition failures and other critical failures that terminate the current process when they occur.<\/p>\n

[…]<\/p>\n

This proposal introduces new overloads of the #expect()<\/code> and #require()<\/code>\nmacros that take, as an argument, a closure to be executed in a child process.\nWhen called, these macros spawn a new process using the relevant\nplatform-specific interface (posix_spawn()<\/code>, CreateProcessW()<\/code>, etc.), call\nthe closure from within that process, and suspend the caller until that process\nterminates. The exit status of the process is then compared against a known\nvalue passed to the macro, allowing the test to pass or fail as appropriate.<\/p>\n<\/blockquote>\n\n

I had heard talk about changing the behavior of preconditions and assertions during tests so that they would signal back to the testing system instead of actually terminating the process. This is a much more ambitious solution and should be more widely useful. For example, I’ve written tests to reproduce crashes that are triggered by a bug, but I can’t leave these enabled with XCTest because they’ll crash the whole testing system.<\/p>\n\n

\n

Exit tests cannot capture any state originating in the parent process or from the enclosing lexical context.<\/p>\n<\/blockquote>\n\n

This is an unsurprising limitation. I’m guessing that it won’t be much of a problem, but I’m not sure without trying it.<\/p>\n\n

\n

It is often interesting to examine what is written to the standard output and\nstandard error streams by code running in an exit test. Callers can request that\neither or both stream be captured and included in the result of the call to\n#expect(exitsWith:)<\/code> or #require(exitsWith:)<\/code>.<\/p>\n

[…]<\/p>\n

The technical constraints preventing recursive exit test invocation can be resolved if there is a need to do so. However, we don't anticipate that this constraint will be a serious issue for developers.<\/p><\/blockquote>\n\n

Previously:<\/p>\n