-
Notifications
You must be signed in to change notification settings - Fork 1.4k
Cleanup SPMTestSupport Module #3019
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
Cleanup SPMTestSupport Module #3019
Conversation
Rename TestWorkspaceDelegate to MockWorkspaceDelegate
Remove MockLoadingError type Rename MockDependencyResolver.swift to MockPackageContainer.swift
This comment has been minimized.
This comment has been minimized.
@swift-ci please smoke test |
@@ -61,48 +59,48 @@ public final class TestWorkspace { | |||
self.skipUpdate = skipUpdate | |||
self.enablePubGrub = enablePubGrub | |||
|
|||
try create() | |||
try self.create() |
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.
Are all these self.
additions just stylistic? I think the general Swift approach (and the one used in SwiftPM) is to not specify self.
when it's not needed (such as in an escaping closure).
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.
These were automatically inserted by SwiftFormat, for which @tomerd added the configuration with #3012. I believe we share stylistic preferences, but I'm more than happy to accede to any conventions enforced by a formatter.
That said, I've encountered a few situations in which SwiftFormat makes source-breaking changes to Swift Package Manager. Namely, mistakenly inserting self.
for things like break
labels and local variables whose names shadow an instance method or property. To reproduce this, try running swiftformat
with the current settings on Sources/Workspace/Workspace.swift
.
I'm working to share minimal examples with the maintainer, but this may be cause for reconsidering how automatic formatting is currently set up.
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.
Are all these self. additions just stylistic? I think the general Swift approach (and the one used in SwiftPM) is to not specify self. when it's not needed (such as in an escaping closure).
These were automatically inserted by SwiftFormat, for which @tomerd added the configuration with #3012. I believe we share stylistic preferences, but I'm more than happy to accede to any conventions enforced by a formatter.
In other projects (SwiftNIO, etc) we actually encouraged adding self. to make sure things are very explicit. happy to open up for discussion tho. cc @weissi
That said, I've encountered a few situations in which SwiftFormat makes source-breaking changes to Swift Package Manager. Namely, mistakenly inserting self. for things like break labels and local variables whose names shadow an instance method or property.
interesting. I have not had such trouble with SwiftFormat in other projects, what version are you using @mattt?
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.
@mattt in any case dont let this block progress. you can run the formatter without the self
setting if it breaks things and we can revisit this separately
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.
@tomerd According to swiftformat --version
, I'm using the latest (0.47.2). For now, I'm committing with --no-verify
to skip my pre-commit hook as necessary. So this isn't a blocker.
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.
This is fine, it's just opposite of what I've seen before so I wanted to ask.
public func XCTAssertEqual<T: CustomStringConvertible>( | ||
_ assignment: [(container: T, version: Version)], | ||
_ expected: [T: Version], | ||
file: StaticString = #file, line: UInt = #line |
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.
Since this code is already being moved around now, should this be switched to #fileId
to avoid future warnings about #fileId
vs #filePath
(once they come back)?
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.
In the interest of keeping this focused, let's punt on that. For something like #file
usage, I think we'll want to change everything project-wide at once, rather than adopting piecemeal over time.
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.
Sounds good.
@@ -138,7 +138,7 @@ class PIFBuilderTests: XCTestCase { | |||
v: .v5_2, | |||
packageKind: .remote, | |||
products: [ | |||
.init(name: "BarLib", targets: ["BarLib"]), | |||
.init(name: "BarLib", type: .library(.automatic), targets: ["BarLib"]), |
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.
Was this a needed change? The default type should be automatic. Or is the intent that for the PIF, the type is always spelled out?
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.
This is a consequence of a3a67f9, which removes a helper overload that implies the type
parameter. I found the ambiguity at the call site not to be worth the benefit of the affordance. If it makes sense for this to be the default argument, I think that change should be made in the original declaration.
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.
Thanks for clarifying.
Thanks for all the continuing cleanup, @mattt! I agree about the change from Test to Mock, but just had a couple of questions about the other changes. |
@abertelrud Thanks so much for reviewing this. I just finished responding to all of your feedback. Let me know if there's anything else you'd like to discuss before merging this in. |
Thanks, this looks great. FYI, I also have a separate change to make SPMTestSupport able to be used for libSwiftPMDataModel, but we can merge yours first and I can rebase on that. |
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.
Is this ready to merge?
Actually, based on your previous comment it sounds as if it is, so I'll merge. |
One last incremental PR in service of #2967, this time doing some clean up in the SPMTestSupport module.
In my work to update the semantics of Swift package identity, I've spent a lot of time in
Workspace
-adjacent tests. And one of the things that's been tripping me up is the use ofTest___
as a prefix for supporting types, likeTestTarget
andTestProduct
, which I often conflate with.testTarget
or the like. I think the prefixMock___
provides clearer, more descriptive names for these types.Along the way, I also fixed some unused or misnamed APIs that I encountered. For example, there was an unused
MockDependencyGraph
type in addition to aMockGraph
type that was used, so I renamed the latter to the former (2f283f0).As always, most of these changes are severable from one another and can be picked or dropped a la carte.
Edit: Any incidental formatting or whitespace changes are from SwiftFormat (#3012), which I have set up to run automatically in a
pre-commit
hook (.git/hooks/pre-commit
) for each staged file: