Polling expectations (under Experimental spi) #1115
Conversation
younata
requested review from
stmontgomery,
grynspan,
briancroom and
suzannaratcliff
as code owners
grynspan
added
enhancement
| private actor Recorder<R: Sendable> { | ||
| var lastValue: R? | ||
|
|
||
| /// Record a new value to be returned | ||
| func record(value: R) { | ||
| self.lastValue = value | ||
| } | ||
| } |
There was a problem hiding this comment.
Ugh. I really dislike this approach, but I wanted to get this PR up so that others could actually test this proposal out & I couldn't think of a better way to handle this. Hopefully one of the benefits of a non-timed-based approach to polling will be that returning values will be much simpler/not a tacked-on hack.
| await confirmation("Polling failed", expectedCount: 1) { failed in | ||
| var configuration = Configuration() | ||
| configuration.eventHandler = { event, _ in | ||
| if case .issueRecorded = event.kind { | ||
| failed() | ||
| } | ||
| } | ||
| await Test { | ||
| await #expect(until: .passesOnce) { false } | ||
| }.run(configuration: configuration) | ||
| } |
There was a problem hiding this comment.
I'm going to write a test helper to make it much easier to verify that issues were reported, as withKnownIssue is the wrong semantics for what I want. I'm also tempted to make it available under ForToolsIntegrationOnly, but I also think that should be a separate pitch?
I really want something that I can use like:
let issues = await collectIssues {
#expect(Bool(false))
}
| fileprivate func isCloseTo(other: Self, within delta: Self) -> Bool { | ||
| var distance = self - other | ||
| if (distance < Self.zero) { | ||
| distance *= -1 | ||
| } | ||
| return distance <= delta | ||
| } |
There was a problem hiding this comment.
I want this to be in the swift standard library and apply to all numeric types. It would make comparing floating point types so much more doable, but is also useful for integer types when you only care that a value is close to another value.
In my ideal world, this would work like 1.000001 == 1 ± 1e-3 (or 1.00001 == 1 +- 1e-3, to avoid using the hard-to-type ± symbol). But that would involve adding another ternary operator to the language (... not quite. You could do this without adding another ternary operator), which would be much more involved (and far less likely to succeed) than adding a method to a protocol in the standard library.
There was a problem hiding this comment.
swift-numerics has this, more or less, but we can't add it as a dependency of course. :)
Additionally, make PollingBehavior an implementation detail of polling, instead of exposed publicly Removes any timeouts involved for polling, as they become increasingly unreliable as the system runs more and more tests
This implements polling expectations, as described in ST-NNNN.
Motivation:
Being able to monitor changes in the background is something of immense value. Swift Testing already provides an API for this in the
confirmationapi. However, I've found theconfirmationto be hard to work with at times - it requires you to set up a callback for when something changes, which is not always possible or even the right thing to do. Polling provides a very general approach to monitoring all kinds of changes.Modifications:
This adds a new set of macros for handling polling. A new public enum for the 2 separate polling behaviors, and new types to actually implement polling. All under the experimental spi.
Checklist: