Parent Suite object not initialized from Child Suite

Development Swift Testing
1

I'm porting over some reusable test infrastructure from our current Quick ecosystem. Specifically I am trying to recreate the "QuickConfiguration" construct that supports global set up (e.g. configuring Mockinjay to stub all network calls).

My approach has run into an unexpected roadblock: when running tests in a child suite, the parent suite initializers are not invoked.

I'm assuming this is by design and for good reason, but ... why?

Or is this must a missing feature that's on the backlog somewhere?

Any suggestions as to what to use instead? I hate the idea of having to add this line of code to every child sutie type declaration:

let autoConfiguration = GlobaSuiteAutoConfiguration()
2

The body of a member test function testFunction() is, effectively:

func f() async throws {
  var instance = ThisType()
  try await instance.testFunction()
}

Instances of containing types are not, as a rule, initialized every time an instance of a contained type is.

As well, from a more technical direction, it's not guaranteed that Swift Testing is even capable of initializing an instance of a containing type. The following is valid, for example:

extension Never { // cannot be initialized!
  struct NeverTests {
    @Test func foo() { ... }
  }
}
1 Like
3

Ah! That it very helpful, thanks.

Upon further reading, it appears that TestScoping is the mechanism I'm looking for.

Am I really the first person in the world that's trying to port Quick & Nimble specs over to the Suite ecosystem? I thought this would be a solved problem by now.

4

I wouldn't know the answer to that. @younata could probably talk about it.

5

... to whom many of us are incredibly grateful

1 Like
6

I doubt you're the first, but this s the first post I've ran across for this (though, that's not saying much).

I've not tried porting existing Quick tests to Swift Testing, but I'm very interested in doing what I can (both as Quick's maintainer & as a member of the testing workgroup) to make porting back and forth as easy as possible. You should not be tied to a testing framework purely due to inertia.

2 Likes
7

Sadly, what we're doing here is more of a rewrite than a port. And certainly no kind of interop between legacy specs and Swift Testing suites. At this point I'm just researching various mechanisms for replacing constructs we've been using in Quick (like QuickConfiguration)