-
Notifications
You must be signed in to change notification settings - Fork 10.3k
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
SR-1417: Add non-optional overloads of XCTAssertEqual and XCTAssertNo… #2551
Conversation
…tEqual Previously, the only version of the functions that accepted values was the one that implicitly wraps them into Optionals. This generated a confusing error message when the assert failed. Having a separate overload that accepts non-optional types ensures that the correct description is printed when the assert fails.
@modocache I think I did what you asked in swiftlang/swift-corelibs-xctest#110 |
expectEqual(0, failingTestRun.unexpectedExceptionCount) | ||
expectEqual(1, failingTestRun.totalFailureCount) | ||
expectFalse(failingTestRun.hasSucceeded) | ||
} |
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 there a way to test that your overloads accomplish the stated goal? In other words, could we check the failure message?
I think this is possible by using XCTestObservationCenter
:
// pseudocode, not sure if this will work
class MyObserver: XCTestObservation {
func testCase(_ testCase: XCTestCase, didFailWithDescription description: String, inFile filePath: String?, atLine lineNumber: UInt) {
expectEqual(description, "XCTAssertEqual failed: (\"1\") is not equal to (\"2\") - ")
}
}
let observer = MyObserver()
XCTestObservationCenter.center().addTestObserver(observer)
let failingTestCase = AssertEqualOptionalTestCase(selector: #selector(AssertEqualOptionalTestCase.test_whenOptionalsAreNotEqual_fails))
execute(failingTestCase.run)
XCTestObservationCenter.center().removeTestObserver(observer)
This is excellent, thanks!! I'd like to see tests that prevent this from regressing in the future. I left a comment to demonstrate one potential way of writing such a test. |
@swift-ci please test |
I'd like to see tests too but I'm afraid that's beyond me for the time being :-/ |
Have you tried my comment above? #2551 (comment) I think that might work... |
The problem is that my Mac seems to be significantly underpowered for Swift development, both in terms of CPU power and of mass storage space (it's a 2012 MacBook Air with 120GB drive). In addition, the XCTest tests seem to be flat out disabled at the moment from the standard suite. Is there a way to quickly build and run just a single test? |
Ah yes, this is true. Removing this line will re-enable the tests. There is, unfortunately, no great way to run only one test at the moment; you'll need to run something like Yeah, it does take a bit of a workhorse computer to contribute to Swift... I can help with the tests if you don't mind; I'll take your commit and put some tests in a separate commit on top of it, then submit a pull request. |
I would gladly appreciate your help :-) |
Within the build directory, you can run |
I'm not seeing any activity here but would love to see this go in. @modocache @nsalmoria any objections if I go ahead and add the tests we are looking for here? |
@briancroom Yes, go for it! Sorry, this was at the back of my mind all week but never found the time. Thanks for pinging! |
@briancroom please go ahead! Thank you! |
Just opened #2788 |
@nsalmoria I think this pull request can be closed in favor of @briancroom's #2788. That pull request includes your commit 👍 |
What's in this pull request?
Resolved bug number: (SR-1417)
Before merging this pull request to apple/swift repository:
Triggering Swift CI
The swift-ci is triggered by writing a comment on this PR addressed to the GitHub user @swift-ci. Different tests will run depending on the specific comment that you use. The currently available comments are:
Smoke Testing
Validation Testing
Note: Only members of the Apple organization can trigger swift-ci.
…tEqual
Previously, the only version of the functions that accepted values was the one that implicitly wraps them into Optionals. This generated a confusing error message when the assert failed. Having a separate overload that accepts non-optional types ensures that the correct description is printed when the assert fails.
Example:
XCTAssertEqual(1, 2, "message")
Previous error:
XCTAssertEqual failed: ("Optional(1)") is not equal to ("Optional(2)") - message
New error:
XCTAssertEqual failed: ("1") is not equal to ("2") - message