Skip to content

Needed: variant of assertMacroExpansion() that does not use XCTest #2400

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.

Sign up for GitHub

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

Jump to bottom
Closed
grynspan opened this issue Dec 11, 2023 · 2 comments
Closed

Needed: variant of assertMacroExpansion() that does not use XCTest #2400

grynspan opened this issue Dec 11, 2023 · 2 comments
Assignees
@grynspan
Labels
enhancement New feature or request

Comments

@grynspan
Copy link
Contributor

grynspan commented Dec 11, 2023 •
edited
Loading

Description

Test targets that use swift-testing instead of XCTest need some way to work with this function; let's add a throwing equivalent that can be used without any dependency on a specific testing library.
@grynspan grynspan added the enhancement New feature or request label Dec 11, 2023
@grynspan grynspan changed the title Needed: variants of assertMacroExpansion() and assertDiagnostic() that do not use XCTest Needed: variant of assertMacroExpansion() that does not use XCTest Dec 11, 2023
@ahoppen
Copy link
Member

ahoppen commented Dec 11, 2023

Tracked in Apple’s issue tracker as rdar://119519713

@grynspan grynspan self-assigned this Dec 11, 2023
grynspan added a commit to swiftlang/swift-package-manager that referenced this issue Dec 11, 2023
@grynspan
Add the ability to specify testing libraries when initing a package.
50ba727 
This PR adds `-enable-experimental-swift-testing` (and `-disable-xctest` and their inverses) to `swift package init`. These options behave, broadly, the same as they do for `swift test`. They determine which testing library a new package will use and adjust the generated template to match.

It is important to note that any combination of the two libraries is supported: a developer may wish to use only one or the other, or both, or may wish to opt out of a test target entirely. All four combinations are supported, however for simplicity's sake if both libraries are enabled, we only generate example code for swift-testing.

Note that right now, correct macro target support is impeded by swiftlang/swift-syntax#2400. I don't think that issue blocks a change here (since it's in an experimental feature anyway!) but it does mean that `swift package init --type macro --enable-experimental-swift-testing` produces some dead tests. Once that issue is resolved, we can revise the template to produce meaningful tests instead.

Resolves rdar://99279056.
@grynspan grynspan mentioned this issue Dec 11, 2023
Merged
grynspan added a commit to swiftlang/swift-package-manager that referenced this issue Dec 12, 2023
@grynspan
Allow specifying testing libraries for swift package init (#7186)
81526cf 
This PR adds `-enable-experimental-swift-testing` (and `-disable-xctest`
and their inverses) to `swift package init`. These options behave,
broadly, the same as they do for `swift test`. They determine which
testing library a new package will use and adjust the generated template
to match.

It is important to note that any combination of the two libraries is
supported: a developer may wish to use only one or the other, or both,
or may wish to opt out of a test target entirely. All four combinations
are supported, however for simplicity's sake if both libraries are
enabled, we only generate example code for swift-testing.

Note that right now, correct macro target support is impeded by
swiftlang/swift-syntax#2400. I don't think that
issue blocks a change here (since it's in an experimental feature
anyway!) but it does mean that `swift package init --type macro
--enable-experimental-swift-testing` produces some dead tests. Once that
issue is resolved, we can revise the template to produce meaningful
tests instead.

Resolves rdar://99279056.
grynspan added a commit that referenced this issue Dec 13, 2023
@grynspan
Modify assertMacroExpansion() so that it only conditionally calls `…
7361b0d 
…XCTFail()`.

This PR changes the signature of `assertMacroExpansion()` such that an alternative failure handler can be passed for use when e.g. swift-testing is being used.

Right now, the function calls `XCTAssertEqual()`, `XCTFail()`, etc. on the assumption that the caller is using XCTest. This assumption does not always hold and the dependency on XCTest may prevent a developer from writing effective tests leveraging `assertMacroExpansion()` while also using swift-testing or other testing libraries.

It is not possible for swift-syntax to include swift-testing as a dependency at this time, so the function cannot be amended to directly call the equivalent of `XCTFail()` from that library. Nor can the function check if the current process is running an XCTest-based test because XCTest does not expose API to determine if a test is running.

Until such time as swift-syntax can directly call into swift-testing, developers can do so when calling `assertMacroExpansion()` like so:

```swift
assertMacroExpansion(
  "@foo bar",
  "expanded_foo bar",
  macros: ...,
  ...
) { message, fileID, filePath, line, column in
  Issue.record(Comment(rawValue: message), fileID: fileID, filePath: String(describing: filePath), Int(line), Int(column))
}
```

An improved interface is a future direction.

Resolves #2400.
@grynspan grynspan mentioned this issue Dec 13, 2023
Closed
@ahoppen
Copy link
Member

ahoppen commented Jun 4, 2024

Implemented in #2647

@ahoppen ahoppen closed this as completed Jun 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@grynspan grynspan

Labels
enhancement New feature or request
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Modify assertMacroExpansion() so that it only conditionally calls XCTFail(). swiftlang/swift-syntax
2 participants
@ahoppen @grynspan