You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I wanted to give a high-level overview of my plans for the next major versions of Quick. Obviously, this is not set in stone and things will likely change. But I wanted to discuss what I would like to see happen in Quick. I invite you to share your thoughts in the comments of this thread.
Faster Test Discovery
Tests are discovered in a single-threaded manner, one at a time. Then XCTest actually runs them. We currently don't have a way to gather analytics on how fast test discovery is, but I imagine we should be able to speed it up greatly just by parallelizing them. This would require us to get rid of, or at least greatly diminish usage of, the World singleton.
ResultBuilder-based DSL @amomchilov has an interesting proof-of-concept PR demonstrating this. I'd like to see this expanded and eventually be able to move Swift tests to using a ResultBuilder-based DSL. Objective-C tests would not be able to take advantage of this. We'll have to keep the existing infrastructure around for Objective-C compatibility.
Update 2023-04-23: As of this comment, I've determined that while a ResultBuilder-based DSL would be much simpler to implement, there are enough drawbacks (as detailed in the linked comment) that it would be impractical to add a ResultBuilder-based DSL.
Improving the developer experience.
This is quite vague and encompasses quite a number of things. But it includes things like the following:
This will be in Quick 7, for both AsyncSpec and QuickSpec.
Improve the experience of using Quick in CI.
Some common feedback I've personally received about Quick is constructing the test that failed from the test selector name. I'd like to make this much easier to figure out.
Provide data to XCTest to be able to both see which test failed, linked with any test helper methods that were called/used by that test (even things like Behaviors, or SharedExamples, or even simple functions), inline on the Xcode code editor. This is something you can currently do in bog-standard XCTest, so it shouldn't be difficult for Quick (or Nimble) to do the same.
Improving our documentation.
I like our current documentation, it's pretty good. But I think it could be better. There's a lot of "testing theory" that we could better cover in our documentation. There's also a lot of concrete "how to use Quick", especially going beyond simple examples, that we should add.
This, unfortunately, does not include things that Xcode won't let us do (Yet? Please Apple?), such as:
Test gems inline with it blocks.
Running an individual test prior to test discovery.
Again, these are my thoughts. I don't expect all of these to be in Quick 7, but I would like to eventually cover all of these.
Please feel free to share your thoughts on these, or even other ideas you might have.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Hello friends and users of Quick!
I wanted to give a high-level overview of my plans for the next major versions of Quick. Obviously, this is not set in stone and things will likely change. But I wanted to discuss what I would like to see happen in Quick. I invite you to share your thoughts in the comments of this thread.
Faster Test Discovery
Tests are discovered in a single-threaded manner, one at a time. Then XCTest actually runs them. We currently don't have a way to gather analytics on how fast test discovery is, but I imagine we should be able to speed it up greatly just by parallelizing them. This would require us to get rid of, or at least greatly diminish usage of, the
World
singleton.ResultBuilder
-based DSL@amomchilov has an interesting proof-of-concept PR demonstrating this. I'd like to see this expanded and eventually be able to move Swift tests to using aResultBuilder
-based DSL. Objective-C tests would not be able to take advantage of this. We'll have to keep the existing infrastructure around for Objective-C compatibility.ResultBuilder
-based DSL would be much simpler to implement, there are enough drawbacks (as detailed in the linked comment) that it would be impractical to add aResultBuilder
-based DSL.Improving the developer experience.
This is quite vague and encompasses quite a number of things. But it includes things like the following:
AsyncSpec
andQuickSpec
.Some common feedback I've personally received about Quick is constructing the test that failed from the test selector name. I'd like to make this much easier to figure out.
Behavior
s, orSharedExample
s, or even simple functions), inline on the Xcode code editor. This is something you can currently do in bog-standard XCTest, so it shouldn't be difficult for Quick (or Nimble) to do the same.I like our current documentation, it's pretty good. But I think it could be better. There's a lot of "testing theory" that we could better cover in our documentation. There's also a lot of concrete "how to use Quick", especially going beyond simple examples, that we should add.
This, unfortunately, does not include things that Xcode won't let us do (Yet? Please Apple?), such as:
it
blocks.Again, these are my thoughts. I don't expect all of these to be in Quick 7, but I would like to eventually cover all of these.
Please feel free to share your thoughts on these, or even other ideas you might have.
Thanks!
Beta Was this translation helpful? Give feedback.
All reactions