-
-
Notifications
You must be signed in to change notification settings - Fork 15
Transition to swift-macro-testing for Macro Testing #16
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
Conversation
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.
Awesome, thanks for the PR! Just a few requested changes (mostly to do with the literal parsing tests)
// InlineSnapshotTesting.isRecording = true | ||
// isRecording: true |
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.
Delete these commented lines, or just uncomment them if necessary and allow people to change the boolean instead of commenting/uncommenting (looks like the second line isn't valid)
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 habit I unknowingly picked from them. I am going to opt to setting it to false unless you have a preference. (Just to serve as living documentation that you can re-record all the test this way). Not sure if they usually comment/uncomment for keyboard shortcut ease or since it's a global variable so setting an actual value could be ambiguous if you do it in several places 🤷
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.
Ah yeah makes sense, I think the uncommented boolean toggling way is a bit cleaner but I can see why people would do it the other way too.
@@ -411,8 +422,14 @@ final class MacroToolkitTests: XCTestCase { | |||
/abc/ | |||
""" | |||
|
|||
// TODO: Figure out a more precise way to test regex literal parsing | |||
XCTAssert((try? RegexLiteral(basicLiteral)?.regexValue()) != nil) | |||
assertInlineSnapshot(of: RegexLiteral(basicLiteral), as: .description) { |
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.
You need to have .regexValue()
still, otherwise the test isn't testing anything other than the internal structure of RegexLiteral
(the initialiser doesn't do any parsing)
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.
Got it. It's unfortunate that the regex builder doesn't expose the underlying regex pattern. I will revert it. Mostly wanted to bring attention to it (Short post about it here).
Definitely time and place. Sometimes easy to fall into using dynamite to a catch a fish so to speak. For example if you use as .dump
snapshotting regexValue()
of this you get below. Seems it is really beneficial for text based comparison where you would just normally assert that one piece of data matches before you say fuck it, good enough.
"""
▿ Regex<AnyRegexOutput>
▿ program: Program
- _loweredProgramStorage: Optional<AnyObject>.none
▿ compileOptions: _CompileOptions
- rawValue: 0
▿ tree: DSLTree
▿ root: Node
▿ convertedRegexLiteral: (2 elements)
▿ .0: Node
▿ concatenation: 3 elements
▿ Node
▿ convertedRegexLiteral: (2 elements)
▿ .0: Node
▿ atom: Atom
- char: "a"
▿ .1: ASTNode
▿ ast: 「a」
▿ atom: 「a」
▿ kind: Kind
- char: "a"
▿ location: Location
▿ range: Index(_rawBits: 15)..<Index(_rawBits: 65799)
▿ lowerBound: Index
- _rawBits: 15
▿ upperBound: Index
- _rawBits: 65799
▿ Node
▿ convertedRegexLiteral: (2 elements)
▿ .0: Node
▿ atom: Atom
- char: "b"
▿ .1: ASTNode
▿ ast: 「b」
▿ atom: 「b」
▿ kind: Kind
- char: "b"
▿ location: Location
▿ range: Index(_rawBits: 65799)..<Index(_rawBits: 131335)
▿ lowerBound: Index
- _rawBits: 65799
▿ upperBound: Index
- _rawBits: 131335
▿ Node
▿ convertedRegexLiteral: (2 elements)
▿ .0: Node
▿ atom: Atom
- char: "c"
▿ .1: ASTNode
▿ ast: 「c」
▿ atom: 「c」
▿ kind: Kind
- char: "c"
▿ location: Location
▿ range: Index(_rawBits: 131335)..<Index(_rawBits: 196615)
▿ lowerBound: Index
- _rawBits: 131335
▿ upperBound: Index
- _rawBits: 196615
▿ .1: ASTNode
▿ ast: (「a」,「b」,「c」)
▿ concatenation: (「a」,「b」,「c」)
▿ children: 3 elements
▿ 「a」
▿ atom: 「a」
▿ kind: Kind
- char: "a"
▿ location: Location
▿ range: Index(_rawBits: 15)..<Index(_rawBits: 65799)
▿ lowerBound: Index
- _rawBits: 15
▿ upperBound: Index
- _rawBits: 65799
▿ 「b」
▿ atom: 「b」
▿ kind: Kind
- char: "b"
▿ location: Location
▿ range: Index(_rawBits: 65799)..<Index(_rawBits: 131335)
▿ lowerBound: Index
- _rawBits: 65799
▿ upperBound: Index
- _rawBits: 131335
▿ 「c」
▿ atom: 「c」
▿ kind: Kind
- char: "c"
▿ location: Location
▿ range: Index(_rawBits: 131335)..<Index(_rawBits: 196615)
▿ lowerBound: Index
- _rawBits: 131335
▿ upperBound: Index
- _rawBits: 196615
▿ location: Location
▿ range: Index(_rawBits: 15)..<Index(_rawBits: 196615)
▿ lowerBound: Index
- _rawBits: 15
▿ upperBound: Index
- _rawBits: 196615
"""
Updated. Yeah I wasn't sure about the TODO that was there. Seems like the best way to test that is actual patterns that would fail/pass the literal being passed. It might be possible to rebuild the pattern through reflection and assert on that. But that's usually brittle and the syntax tree is pretty gnarly. |
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.
Awesome thanks, looks good now 👌
This PR replaces
SwiftSyntaxMacrosTestSupport
withswift-macro-testing
. It streamlines the macro testing process by introducing automated fixmes and better diagnostics.Key changes include:
swift-macro-testing
.Additionally, this implementation demonstrates use of inline snapshotting tests, a technique used under the hood by the macro testing framework to verify the correctness of outputs directly within test cases. This approach can improve both the readability and accuracy of the tests.
Resolves #6
Benefits: