What you need to know before migrating to Swift Testing

Community Showcase
, , , ,
1

Hi Everyone.

I have written a post on medium going through some of the gotchas you might face when migrating to Swift Testing from XCTest: What you need to know before migrating to Swift Testing | by Soumya Mahunt | Jul, 2025 | Medium

Do check this out and let me know your thoughts. What other challenges you have faced when migrating to Swift Testing?

7 Likes
2

Thanks for the write-up! If you'd be interested in helping us improve Migrating a test from XCTest | Apple Developer Documentation, we do take PRs. :smiley:

2 Likes
3

Terrific article, thank you @soumyamahunt!

I had two responses to recommendations in your post for your consideration below. (I also added a version of this response to the Medium post directly.)

Re: "Challenge #1: Assertions Don’t Work Outside of a Task Context", you can technically continue using DispatchQueue or concurrency patterns other than Swift concurrency. However, when doing so you must be careful to place the expectations (such as #expect(...)) within the main scope of the @Test function so that they are called from its Task. So you don't necessarily have to refactor or stop using DispatchQueue right away or ever, but expectations need to occur in the right scope. I realize that sometimes it can be difficult to confine expectations to the main test function scope and it's easier to place them in a closure invoked by a dispatch queue, so it's a case-by-case decision.

Re: "Challenge #3: Inheriting Suites Doesn’t Inherit Its Tests", it is true tests from superclasses do not inherit currently. However, Swift Testing encourages an alternative pattern called Parameterized Testing which serves a similar role by allowing a single @Test function to be invoked multiple times with differing inputs. Conceptually, a parameterized test solves a similar need as test inheritance did in XCTest. If you're migrating from this pattern in XCTest, it may be best to use a single suite type and pass a test within that suite a collection of arguments whose elements represent the inputs to the test which were previously specified via different subclasses.

It's great to see these kinds of nuances being explored and discussed, so thank you again for the writeup.

2 Likes
4

Thanks @grynspan, will try to come up with a PR for the documentation update.

5

Thank you @smontgomery, I briefly looked into parameterized testing as a workaround. But since the XCTestCase classes I was converting had around 50-100 test methods I preferred to keep the tests as part of XCTest for now. I would love if Suite inheritance/parameterization at the Suite level is supported as well.

1 Like
6

This comes up fairly frequently and we are interested in solving the problem, but it's not currently technically feasible. See e.g. Paramaterised Suites? - #2 by grynspan . Actually, that's probably not a great example as that thread deals with a different definition of "parameterized suite." :man_facepalming:

Anyway… today, syntax-based macros are not able to give us enough context to correctly expand @Test within a parameterized suite type.

1 Like
7

Understandable, sure. It does require a bit more effort/time to do this conversion.

That being said, when it comes to recommendations given to others (such as in your Medium post), I suggest most users first consider adopting the parameterized test feature in this scenario, since it results in a better experience overall. If you're interested, I'd encourage you to mention parameterized testing in that section of your post, at the very least, to ensure readers are aware of it and understand that it's intended for this purpose.

2 Likes