-
Notifications
You must be signed in to change notification settings - Fork 64
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
Introduce a new SPM-based test harness #307
base: master
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
This file was deleted.
This file was deleted.
This file was deleted.
This file was deleted.
This file was deleted.
This file was deleted.
This file was deleted.
This file was deleted.
This file was deleted.
This file was deleted.
This file was deleted.
This file was deleted.
This file was deleted.
This file was deleted.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why was this removed?
We should keep it around until:
swift testing
is capable of testing 100% of the things that we might care to test, both now and in the futureThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a bit awkward to have both the old and new integration test suite in the same PR, so my intention was to keep this as a draft until all current tests are migrated over (verified by running the tests and counting the assertions, or whatever). The reason is this:
swift-integration-tests
crateSwiftRustIntegrationTestRunner
(Result.swift, etc)If you favor a more incremental approach, I would propose the following:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not quite following why we'd need to duplicate anything vs. restructuring things such that we can move Rust+Swift code over from the old suite to the new suite, one batch at time.
i.e.,
Old Swift + Old Rust (starts with everything) -> New Swift + New Rust (starts with nothing)
Maybe that's what your incremental approach proposal is saying. I'm not quite sure if you're suggesting that there are downsides to the incremental approach.
Regardless, I'm cool with whichever option you prefer.
I'm just happy to see this work progressing and won't bother trying to weigh the pros and cons, so anything that best helps you land it is more than fine by me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's probably a bit slower, but it's also cleaner. Once #310 and #312 land, I will rebase and push a version that does that (and then mark the PR as not a draft).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've replied to #310 and #312 with recommendations for how to land them.
Hoping to unblock this
Introduce a new SPM-based test harness
PR so that we can merge it and have a foundation that we can start to build upon (by gradually porting tests over).