-
Notifications
You must be signed in to change notification settings - Fork 263
[SR-1417] Add non-optional overloads of XCTAssertEqual and XCTAssertN… #110
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
…otEqual 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.
Enhance xctest_checker such that it substitutes the string "[[@line]]" and "[[@line+<offset>]]" with the current line number of the source file when performing checks. This allows us to add and remove arbitary lines in the functional test suite without manually updating line numbers in most cases. Line offsets will still need to be updated when the distance between the CHECK and the test failure changes. To test the offsets out, use them in one of the asynchronous tests.
Awesome, thanks for trying your hand at SR-1417, @nsalmoria! 💯 It looks like Apple XCTest's SDK overlay doesn't have overloads of // Using Apple XCTest (Xcode 7.3.1), this produces the output:
// "XCTAssertEqual failed: ("Optional(1)") is not equal to ("Optional(2)") - "
XCTAssertEqual(1, 2) Could you try adding these overloads, as well as tests for them, to the Apple XCTest SDK overlay in the apple/swift repository? You can add a test to the existing tests here. Sorry for the additional work. The good news is that you can improve this output for all users of XCTest, even users of Apple XCTest on OS X! 😍 |
(Oh, and let me know if you'd rather not deal with building/testing the Swift project. If you'd like, I can take care of adding these overloads to Apple XCTest.) |
[Tests] Automatically substitute [[@line]] numbers
Use the line number offsets introduces in #112 to make the functional test suite assertions less brittle. Now contributors may add and remove arbitary lines in the functional test suite without manually updating line numbers in most cases. Line offsets will still need to be updated when the distance between the CHECK and the test failure changes.
Extract some stuff to separate files
As it happens, I am a user of XCTest on OS X :-) I'll take a stab at it. |
[Tests] Use line number offsets for assertions
Excellent! Please tag @modocache when you send a pull request. :) |
…otEqual 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.
Add an option to specify the install prefix for CoreFoundation depend…
- This is useful in clients which would like to use Swift type inference to define the `allTests` array. If none of the tests in the class throw, Swift will infer the type of that array as `(String, (T) -> () -> ())` which is not convertible to the type expected by the `testCase` method. - Resolves: https://bugs.swift.org/browse/SR-1589
[SR-1589] Add non-throwing testCase() wrapper function.
This includes updating the documentation to indicate that this is the preferred way of declaring `allTests` for users of the library.
Take advantage of type inference when specifying `allTests` variables.
swiftlang/swift#2609 introduced a change to the default behavior of the Swift driver, which now uses the gold linker unless specified otherwise. This caused a linker error in swift-corelibs-xctest's test suite, which this commit fixes.
[Tests] Set LD_LIBRARY_PATH when running tests
This is triggered by `--list-tests` or `-l`.
- This allows XCTest to find Foundation adjacent to itself, and fixes runtime linker problems when using Gold, which automatically uses DT_RUNPATH instead of DT_RPATH and so no longer inherits the search path into the Swift runtime libraries location used at build time on the client (which `swiftc` currently automatically injects). - Fixes SR-1631.
[build] Add an rpath of $ORIGIN.
[SR-1541] Listing test methods
Remove deprecated build script flags.
…ft-corelibs-xctest into SowmyaVikram-NSBundleChanges # Conflicts: # Sources/XCTest/XCTestMain.swift
Separate public-facing and library-private source files
This is blocked by swiftlang/swift#2788. @mike-ferris-apple, you're probably busy with WWDC, but could you take a look at that pull request? Once swiftlang/swift#2788 is merged we can ask @nsalmoria to rebase these changes, then I'll review and merge them. |
@nsalmoria Sorry for the delay! Now that swiftlang/swift#2788 is merged, can you rebase these changes? The conflict is probably due to #122, which moved these files around. Sorry! Let me know if you're not sure how to rebase or would like some help. |
…otEqual 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.
…otEqual 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 have rebased? Not sure if I was supposed to do things differently to avoid pulling in all the history from master :-/ |
@modocache I created a new pull request #123 from a new branch to attempt fixing this mess. Closing this one. |
…otEqual
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", file: "test.swift")
Previous error:
XCTAssertEqual failed: ("Optional(1)") is not equal to ("Optional(2)") - message
New error:
XCTAssertEqual failed: ("1") is not equal to ("2") - message