New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for function call order expection #297
Comments
Most scenarios that might need something like this are also solved by Swift concurrency, which is why we didn't implement an interface for it. For instance, if you expect functions A, B, and C to execute in that order, async/await means it's usually possible to force that to happen just by writing your calls to them in the right order. Is there a scenario you're thinking of where that isn't possible today? |
Yes. For normal async/await Swift concurrency scenarios, there is no problem. But for C-Style like POSIX lock API, it does not support very well. The Task and await code are just pseudo code to create 2 pthread. The core issue of the above example is to test the lock's behavior where Swift concurrency is not available. However, such scenario should be very rare. Almost only a few low-level libraries that need to deal directly with the C language need such usage. If upstream does not plan to support this feature, I totally understand the concern. |
swift-testing is, of course, a Swift testing library. C code that behaves well when imported into Swift is testable too, but esoteric C behaviour is beyond the library's purview. That's not a no to this feature request though: do you have a real-world example of C code that you need to use from Swift which you cannot turn into async/await code using continuations, tasks, task groups, etc.? Something we could look at doing is using variadic generics and adding an overload of await confirmation("first thing happened", "second thing happened", ..., strictlyOrdered: true) { first, second, ... in
} This would help with the "arrow of death" pattern too. |
The example is the lock API usage in almost every large iOS projects (NSLock, os_unfair_lock and so on). We have a wide usage of them in our ObjectiveC and Swift codebase. And we probably can convert them into Swift Concurrency but it's not on the plan.
The core issue is we'd like to write test case for them easily. The current test implementation is a little tricky and unstable.
+1 for this idea/implementation. Look forward to seeing the landing PR. |
So, for I can certainly understand that there is code out there that cannot use the provided That's not me saying "no, we won't build this feature", to be clear! But if we have a concrete, real-world use case that isn't trivially solved without the API, then that makes this more urgent to implement (vs. being a nice addition to the API, but low-priority.) |
Sorry for the misunderstanding caused here. What we actually want to test here is something lower level than The example is our cross-platform lock/condition implementation and we want to test the
// Thread 1
func thread_1() {
...
lock.wait()
order.3()
...
}
// Thread 2
func thread_2() {
...
lock.wait()
order.4()
...
}
// Thread 3
func thread_3() {
...
order.2()
lock.broadcast()
}
@Test
func orderTest() {
...
order.1()
// Kicks thread 1 and thread 2's work
...
// Kicks thread 3
...
} After |
I would not recommend using It is generally safe to assume that Consider reimplementing your code to use Swift concurrency instead of a condition lock, and you may find that you (again!) don't need a dedicated interface in swift-testing to ensure your code operates correctly. 🙃 |
Got it. But the problem is we are using our own implementation of
Got it. But that's a fairly old code in the codebase we cannot have a rewrite. I guess the best solution is just do not make the new Swift code to have a dependency on it. Anyway thanks for your time on this issue. If upstream has plans to support such API later, we can keep this issue open, otherwise let's just close it. |
We can keep this issue open as there's still value in the proposed API. |
Description
For async call or blocking call, we want to test the executing order. I'd like to propose an API set similar to confirmation
Expected behavior
Actual behavior
No response
Steps to reproduce
No response
swift-testing version/commit hash
No response
Swift & OS version (output of
swift --version && uname -a
)No response
The text was updated successfully, but these errors were encountered: